Re: [EFM] Re: OAM transport... OAM in Frames
Tom-
Denny chose the slow protocol type for a very good reason. The Slow
Protocol is intended for low bandwidth items that don't have real time
response requirements and can be handled in software. Management is a
perfect example of this.
MAC Control Frames are intended for real-time control that requires
interpretation in hardware, hence the text (emphasis added):
==========================================================
31.1 Overview
This clause specifies an optional MAC Control Sublayer (MAC
Control)for use with the CSMA/CD MAC.
MAC Control provides for real-time control and manipulation of MAC
sublayer operation.This clause specifies a generalized architecture and
protocol for MAC Control.Specific implementations of control
functions
using this protocol are specified in the normative annexes to this
clause.The MAC Control protocol is specified such that it can support new
functions to be implemented and added to this standard in the
future.
Non-realtime,or quasistatic control (e.g.,con .guration of MAC
operational parameters)is provided by Layer Management.
==========================================================
Link aggregation confronted exactly the same problem that you are
addressing and created the Slow Control Protocol to solve it.
Further, Management is traditionally in Ethernet (and I believe
elsewhere) not something that is intended to be done in real-time wrt
packets. I have seen no indication that in-band response times will not
meet the response time requirements for OAM.
OAM is not expected to generated nor interpreted in hardware.
Additionally, were OAM to be done in some way other than in frames then
it would not be compatible with the existing Ethernet PHYs. We confronted
this problem when we first tackled Full-Duplex. The leading proposals on
the table (US 6,029,202 and US 5,825,755) used extra idle codes. We
decided not to do that and to use in-band frames so that full-duplex
could work with 10BASE-T and 10BASE-F.
I submit that we want the same broad applicability here.
Geoff
At 10:25 PM 2/5/02 -0800, Tom Mathey wrote:
In response to [EFM] Re: OAM
transport... OAM in Frames, Tue, 5 Feb 2002 15:29:05 -0800, from Denton
Gentry <denny@xxxxxxxxxxxxxxxxxx>
I took a quick look at Clause 31 and its annexes.
Clause 31.4.1.3 specifies hex 88-08 as the type field for MAC Control
frames. The gentry_1_0102.pdf presentation uses the slow protocol
type (a different value).
Solution: still use hex 88-08, but specify OAM transmit rate
to be 5 frames per second.
Clause 31 is very generic in its description of MAC Control frames. My
quick reading says no change to Clause 31 is required.
Annex 31A is designed to be changed with each new addition of a MAC
Control opcode assignment. Therefore change as needed by adding
opcodes in the Annex 31A table(s).
Annex 31A is designed to work with a new annex for each new opcode.
Therefore add a new Annex 31C.
A new Annex 31C defines each parameter, its size, etc. Tables,
style of approach, TLV, etc. can be liberally plagerized from existing
Clause 43. State diagrams, text, etc. can be liberally plagerized
from existing Annex 31B. The proposed OAM in frames follows the
requirements of Clause 31.
There is no interaction between existing PAUSE frames and proposed OAM
frames. Some work will be needed to fix priority between existing
PAUSE frames and new OAM frames if both signal transmit at the same exact
instance. No work is needed if the 5 frames per second timer
expires and the queue above the MAC is paused. Text in Annex
31A allows the transmit of control frames when the queue above the MAC is
paused.
annex 43B: No change here if we stay with existing MAC Control type
88-08.
SUMMARY
OAM in frames looks like a very doable task.
Tom Mathey
--