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

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




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


--