Re: [EFM] RE: Pause frame usage in transport networks
Roy,
I have to ask this question. Was anything written into the X.86
standard to educate the "ONU" designer regarding the maximum
latency through a worst case potential system? How much buffering
would such a designer know to put on the receive side so that
the round trip latency didn't overflow that buffer if that
latency isn't known or designed for? I'm guessing that, since
X.86 is intended to cross the WAN, the latency can become
extremely large, resulting in comparably large buffers. Perhaps
it was this buffering that is driving other standards to not
support this kind of 802.3x transparent approach.
Regards,
Ben
Roy Bynum wrote:
>
> Shahram,
>
> Based on previous messages, I understand what you are trying to do. This
> is a problem that we dealt in writing the original Ethernet over SONET
> standard, X.86. The other EOS standards written since X.86 have not paid
> attention to this detail.
>
> The specific reason that X.86 was written to be a non-802.1 bridge, without
> a MAC Control layer on receive side was to allow MAC control frames to span
> the entire customer link, end to end, including the transmission facility
> portion of that link. This allows all MAC Control frames, including
> "Pause" as well as the 802.3ah OAM frames to function end to end over the
> link.
>
> When implementing a service using systems based on transmission service
> technology standard that does not specifically protect the integrity of the
> MAC Control frames as well as the MAC frames then you can not count on them
> functioning beyond the first link. In fact, you should take it for granted
> that the "Pause" frames as well as the OAM frame will be dropped at the
> first interface on the service provider network that the customer
> establishes a link to. There is no alternative to this other than using
> the correct transmission technology that does specifically provide for the
> integrity of all frames.
>
> Thank you,
> Roy Bynum
>
> At 11:52 AM 3/3/2003 -0800, Shahram Davari wrote:
>
> >Hi all,
> >
> >Based on 802.3 standard, the PAUSE frames may have an individual or
> >multicast MAC address (including broadcast).
> >It seems to me if the ONU1 sends PAUSE frames with Dest MAC address of
> >ONU2, then the OLT1 would
> >relay that to ONU2 (no matter if OLT1 behaves as a transparent box or as a
> >bridge), while if the ONU1
> >sends a PAUSE frame with Dest MAC address of OLT1 or a multicast MAC
> >address then the PAUSE frames
> >would be terminated at OLT1 if OLT1 behaves like a bridge.
> >
> >ONU1---------OLT1/GFP-------GFP/OLT2------ONU2
> > Eth EOS Eth
> >
> >
> >In other words for end-to-end OAM, if we know that OLT1 does not terminate
> >any OAM frames, then ONU1 may use either
> >Dest MAC address of ONU2 or a multicast address, but if we know that OLT1
> >terminates MAC, then ONU1 should use Dest MAC address of ONU2. To be is
> >safe side it seems that for end-to-end OAM, it is best if ONU1 always sets
> >the Dest MAC address to that of ONU2.
> >
> >Correct?
> >
> >
> >Yours,
> >-Shahram
--
-----------------------------------------
Benjamin Brown
AMCC
200 Minuteman Rd
3rd Floor
Andover, MA 01810
978-247-8022 - Work
603-491-0296 - Cell
978-247-0024 - Fax
603-798-4115 - Home Office/Fax
bbrown@amcc.com
-----------------------------------------