Re: (corrected) Re: [EFM] RE: OAM Transport Proposal
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...