Re: (corrected) Re: [EFM] RE: OAM Transport Proposal
Roy,
Please see my in-line comments below:
Best Regards,
Rich
--
Roy Bynum wrote:
>
> Rich,
>
> The limitation of 125us for alarm indication signal generation is the
> reason that I believed that a compromise that included the alarm bits in
> the Ethernet Preamble for Packet service subscription networks was
> reasonable. The unwillingness to compromise by others on the rest of the
> "OAMiP" proposal, I found unreasonable.
Ethernet is a Packet Network. OAMinP is more responsive than SONET as it
does not have to wait 125us to indicate an alarm. Frankly I don't
understand the nature of what you find to be unreasonable. Please
explain.
> I believe that it is you and others that are attempting to confuse people
> by saying that OAMiP and SONET handle OAM information the same. It only
> takes a look at the "stack" of 10GbE WIS tell that they are not the
> same. The SONET OAM overhead bytes do not contain any customer data. In
> 802.3ae, the overhead bytes are not encoded with the 64b/66b encoding, the
> customer data is. OAMiP is very different than any data transmission
> services protocol that exists today.
I have no conspiracy going. SONET OAM handles faults and alarms at Layer
1. So does OAMinP. That's the plain and simple similarity. I don't know
where you are going with any of your encoding arguments. SONET OAM
information is in overhead bytes. OAMinP OAM information is either in
the Preamble of an Ethernet Packet or an 8-byte message during IPG if no
Packets are flowing. I agree that OAMinP is different. OAM does not
exist for Ethernet. The OAM Baseline proposal is put forth to meet the
EFM OAM objective.
> This is not always bad.
>
> The service providers have been asking for a protocol that makes it
> possible to manage packet services end to end. Frame Relay comes close by
> providing a separate facility into the customer's router through a separate
> PVC. The end link PVC does not provide end to end management that can be
> transported as part of the customer managed data service. OAMiF does, and
> OAMiP might be able to, provide that end to end packet service management
> functionality.
Sorry. I have to tell you that you're out of IEEE 802.3ah scope unless
you mean DTE-to-DTE as being end-to-end. The OAM Baseline proposal
addresses Ethernet OAM for DTE-to-DTE. Anything beyond DTE-to-DTE is out
of scope.
> From the data transmission services standards viewpoint, SONET overhead
> bytes and customer payload are considered separate facilities. I am not
> sure, perhaps I can provide an analogy:
>
> Think of Ethernet frames as individual people that are passengers on major
> highway. SONET is like a major highway system that is built for each
> customer to provide their own cars or buses to carry passengers. Each car
> or bus is a separate payload on the SONET system. The cars, which contain
> passengers, belong to individuals, the customers. SONET is just the
> highway. Over that highway, someone may also run a bus service that also
> carries passengers, which pay on a per passenger basis for getting a ride
> on the highway. The individually owned cars and trucks are using what
> would be equivalent to a leased circuit Private Line service. The
> passengers on the bus service are using what would be equivalent to a
> Packet service. The bus belongs to the service provider as well as the
> seats on the bus. The bus, which provides the bulk transport of passengers
> in a common space, is also a customer on the SONET highway.
When I go to work, I like to get in my car, get on the road and get
there at my leisure. Sometimes I have a damn 6:30 am meeting (I hate it
when that happens). Most times I like to get there around 9:00 am. In
any case the transport is there for my convenience, not the convenience
of the transport itself.
The one thing I'd hate to do is step out of my house, wait, and then try
to jump in some generic car periodically flying by. That would hurt. I
would also be hurt trying to jump out of that moving vehicle which is
intent only on maintaining its periodicity.
I expect to pay a fee for this service. I'd hate to pay more for having
to wait and jumping into and out of moving vehicles.
> Perhaps by this analogy, you can see that packet services are also a
> customer payload on a SONET system, not the SONET system itself. Packet
> services use the same facilities as leased circuit Private Line
> customers. Packet services provide a common bandwidth within a provisioned
> payload of the SONET system for many different customers. Leased circuit
> Private Line services provide an exclusive use bandwidth within a
> provisioned payload of a SONET system for an single customer.
>
> Thank you,
> Roy Bynum
>
> At 11:03 PM 4/30/2002 -0700, Rich Taborek wrote:
>
> >Roy,
> >
> >The OAM Baseline proposal Preamble transport component supports fault
> >and alarm indications with functional equivalence but less delay than
> >SONET's 125 usec transport latency. I guess that may be what you're
> >referring to when you say "absolutely nothing in common with SONET or
> >SDH". We'll likely not specify ptotection mechanisms for EFM as they are
> >not required. However, nothing would preclude the specification of
> >protection mechanisms based on Etherent OAM faults and alarms at the
> >same layer, layer 1, as SONET/SDH.
> >
> >I implore you to stop confusing the audience with arguments that OAM
> >information in SONET is somehow handled differently than it would be for
> >Ethernet. The bottom line is that OAM information for SONET is located
> >in OVERHEAD bytes in a SONET frame which also contains customer data.
> >The OAM Baseline proposal conveys equivalent OAM information either as
> >part of the Preamble of an Ethernet packet or simply in the IPG, without
> >any OVERHEAD which affects customer bandwidth. Maybe it's the lack of
> >OVERHEAD that distinguishes Ethernet OAM from that of SONET.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >Roy Bynum wrote:
> > >
> > > Hiroshi,
> > >
> > > In response to your comment"
> > > "The third, and PHY fault indication / protection by MAC control layer is
> > > something like SONET protection handled by IP packets which engineers never
> > > have used."
> > >
> > > The use of Preamble for transport of any information has absolutely nothing
> > > in common with SONET or SDH. IP packet do not use any form of the
> > > protection handling that is used in SONET or SDH. IP protection is at
> > > layer 3. OAMiP is at layer 2 within the SONET transport service, within
> > > the encoded customer bandwidth. SONET/SDH protection is at layer 1,
> > > underneath any encoding that is in the customer bandwidth payload.
> > >
> > > It may be a matter of confusion to enterprise data people, but the encoding
> > > of the data stream in the payload is considered a layer 2 function to data
> > > transmission services. As far as service standards for service providers
> > > are concerned, the encoding data stream is not a physical layer
> > > function. It is a data link layer function. That is the reason that SONET
> > > facilities are based on the use of OAM that is in a separately encoded
> > > facility from the encoded customer data. OAMiP is part of the encoded
> > > customer data. It is part payload only and has no relationship to any form
> > > of operations, administration, maintenance, or protection functionality of
> > > SONET.
> > >
> > > Please do not continue to make references to any similarities between SONET
> > > and OAMiP.
> > >
> > > Thank you,
> > > Roy Bynum
> > > Thank you,
> > > Roy Bynum
> > >
> > > At 10:08 AM 4/23/2002 -0700, Hiroshi Suzuki wrote:
> > >
> > > >At 09:51 AM 4/23/2002 -0500, Roy Bynum wrote:
> > > >
> > > >>Brad,
> > > >>
> > > >>If I understand you correctly, given that there will always be additional
> > > >>latency translating the MDIO/MDC frames into preamble information, and
> > > >>then send the preamble, even without a standard frame, it will not
> > > >>provide any advantage in greater responsiveness than OAMiF. If that is
> > > >>the case, then there is no advantage to OAMiP under any
> > > >>circumstances. If that is the case, why include it even as optional?
> > > >>
> > > >>Thank you,
> > > >>Roy Bynum
> > > >
> > > >
> > > >First, Preamble handler is located in RS layer ( RS layer is strictly a
> > > >part of PHY )
> > > >which has the high-speed control interface ( common to MAC and above ).
> > > >So the speed is not the issue. Refer the preamble proposals presented in
> > > >last several meetings.
> > > >
> > > >The second, the OAMiF will be mostly like implemented by SW/FW
> > > >( that's the main reason why people want to use it ? )
> > > >the resulting latency would be unpredictable,
> > > >while OAMiP detect indication will be handle by HW with predictable
> > latency.
> > > >
> > > >The third, and PHY fault indication / protection by MAC control layer is
> > > >something like SONET protection handled by IP packets
> > > >which engineers never have used.
> > > >
> > > >Hiroshi
> > > >
> > > >
> > > >>At 06:59 AM 4/23/2002 -0700, Booth, Bradley wrote:
> > > >>
> > > >>>Matt,
> > > >>>
> > > >>>A management frame I described is that defined in Clause 22 as a
> > MDIO/MDC
> > > >>>communication. If the preamble is filtered by the PHY, then there
> > has to be
> > > >>>some way to pass this preamble OAM information to the management
> > entity. In
> > > >>>802.3, this is done via MDIO/MDC (or management frames). A
> > management frame
> > > >>>takes over 25 us to be passed across the MDIO/MDC interface. Unless the
> > > >>>intention is to have the PHY handle all OAM in preamble without
> > management
> > > >>>entity intervention, then the response to the OAM in preamble will be
> > > >>>hampered by the MDIO/MDC interface.
> > > >>>
> > > >>>Cheers,
> > > >>>Brad
> > > >>>
> > > >>>______________________
> > > >>>Sent from my Blackberry...