Re: [EFM] Re: OAM Transport Proposal
Dan,
This is all the more reason for not calling the 8-byte OAM link message
sent during IPG in the absence of Ethernet packets a "frame". These OAM
messages never get to the MAC, so they cannot be mistaken for Ethernet
frames or packets. The OAM link messages have the same format as the OAM
preamble sent along with an Ethernet packet for reasons of architectural
simplicity. What we need is a new name for these messages so they are
not mistaken for frames or packets.
Best Regards,
Rich
--
"Romascanu, Dan (Dan)" wrote:
>
> > 4) Null/dummy frames break MIBs? I don't think its that bad.
> > Certainly
> > the MIB would have to be enhanced with a counter for the
> > number of such
> > frames, but the changes are minimal.
> >
> >
> > - Matt
>
> It's a little bit more complicated, I am afraid. If the required change would be adding one or even more objects, this would be certainly palatable. This is not considered as 'breaking' current standards. However, changing the threshold of what is considered a minimal length frame is a change in semantics that would make the existing implementations of the Ethernet and RMON MINS counters inaccurate for EFM. It is not only that the new type of frames are ignored, but also existing counters become inaccurate. We also need to take into account that most implementations do this counters in silicon. EFM will require replacing the current installed base of management silicon and monitoring devices and applications, and will not be capable of coming and saying 'you can use the current deployed base of applications and monitoring problems'.
>
> This relates to the later question (#6 in your list) as a strong argument to make the null/dummy frames be 'true' Ethernet frames of minimal size'.
>
> Regards,
>
> Dan