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