Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] Re: OAM transport... OAM in Frames


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.


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 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.

OAM in frames looks like a very doable task.

Tom Mathey