Re: [EFM] RE: Pause frame usage in transport networks
Ben,
Unlike some of the other Ethernet over SONET "mapping" standards, X.86 was
specifically written to support 802.3 Ethernet over leased line service
facilities. X.86 was not written with any specific buffer
requirements. Implementations on the receive side would not require any
more than would be necessary to provide for the "mapping" of the
transmission payload. There is no need for "buffers" in the transmit side
because the transmission transfer rate is lower than the 802.3 link
rate. The only need for "delay" information would be for the link from the
customer to the transmission node specific to the 802.3 standard interface
that would be needed in order to properly specify the operand in "Pause"
frames sent to the customer's equipment by the transmission node over the
access link.
At present, for standard leased line facilities, with full transparent
support of all data link protocols, there are no "buffers" anywhere in the
transmission network. The transmission network is stabilized at the bit
level by the synchronization of the transmit clocks in the network elements.
The "transmission delay" that you refer to would be seen from one of the
customer's equipment to the other of the customer's equipment at the link,
not at the transmission node itself. If there are any buffers needed, they
would be in the customer equipment, not in the transmission equipment.
Only with a "packet" service that multiplexes and intermingles many
customers' traffic are such buffers needed. In that case, the OAM as well
as any "Pause" frames that are issue in the network or links would be for
the service providers use, not the customers. In the case of "packet"
services, the bandwidth of the facility does not belong to the customer,
but to the service provider.
What too many are doing is confusing the service model requirements of
"packet" and "leased line" in trying to do a "leased line" with "packet"
technology. In most cases it will not work. Where it does work, it is so
much more expensive to do a leased line service with "packet" technology
that the service becomes uneconomical. This is specifically what happened
to one of the major service providers in the industry, and they have
withdrawn the use of "packet" technology for use with their leased line
services and gone back to fixed, pre-provisioned facilities. All the
marketing "hype" and alteration of the "terminology" used could not change
the economic reality.
Thank you,
Roy Bynum
At 11:38 AM 3/4/2003 -0500, Ben Brown wrote:
>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@xxxxxxxx
>-----------------------------------------