Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] Question regarding OAM in 802.3ah D1.3




Shahram

The two different standards for Ethernet over SONET will handle the OAM 
frames differently.  I was involved with the development of the X.86 
standard and got to work with several of the early implementations.  I also 
had a lot of opportunity to work with the early adapter implementations of 
G.gfp even though I was less involved with the development of that 
standard.  I got to see some distinct differences between the ways that the 
two standards function.

I believe that G.gfp would terminate the OAM because it does not maintain 
the 802.3 link but establishes its own.  Depending on the implementation, 
G.gfp tends to terminate MAC control frames.  It also has its own OAM 
embedded in the mapping that is used for GFP.  There are two types of G.gfp 
link mapping, one that uses HEC frames to replace the Preamble/IPG and 
another that uses extended addressing frames (a somewhat similar 
functionality to that found in RPR) that also replaces the 
Preamble/IPG.  G.gfp tends to operate more at what would be equivalent to 
the RS layer defined by 802.3.  Depending on the implementation, G.gfp is 
not transparent to the link between end systems, but looks like an extended 
switch matrix across the transmission system.  A separate link at each end 
of the transmission service would establish its own link to the G.gfp 
service.  Since the links are established to the service, each end of the 
service can operate as a different link type and speed, depending on the 
type of rate management that has been implemented in the G.gfp implementation.

On the other hand, with X.86, Ethernet over LAPS, the OAM frames are 
transparent and pass through without hindrance the same way that all other 
MAC control frames do.  This is the reason that 802.3x (active flow 
control) works with and is part of X.86.  While X.86 does replace the 
Preamble/IPG with another, it does not include any OAM in the preamble and 
the end to end link would be dependant on the OAM frames generated under 
802.3ah.  The portion of the link that is based on the transmission 
convergence of X.86 is transparent to the end systems except for the rate 
adaptation which uses 802.3x MAC control frames.  In this context X.86 
tends to operate more at what would be equivalent to the PCS layer in 
802.3.  Correctly implemented, a separate link at each end of the service 
is not apparent at each switch/end system of the service. An interesting 
note however; the encoding at each end can be different making it possible 
for the two ends to operate at different signalling speeds, controlled by 
the transmission speed limitation established by the flow control at each 
end.  When this happens, each end operates as if the remote end is the same 
type of link and speed that is the local end with the exception of the 
remote fault functionality of 802.3ae.  This would require that the OAM 
functionality be implemented on all of the existing full duplex link types 
and speeds in the 802.3 standard.

Thank you,
Roy Bynum


At 11:12 AM 2/10/2003 -0800, Shahram Davari wrote:
>Hi,
>
>802.3ah section 57 says that the OAM defined is for single link (or 
>emulated link), and should not be forwarded by bridges/switches.
>
>My question is, in case of Ethernet over SONET transport (GFP + Virtual 
>concatenation), should the OAMPDU be terminated at the EOS device or it 
>should be transparently transported?
>
>Consider this example:
>
>
>OLT1 -------------- ONU 1------------------ ONU 2 ------------ OLT 2
>           Ethernet               SONET                  Ethernet
>
>
>Assume OLT1 and OLT2 are the customer equipments and ONU1 and ONU2 are 
>provider
>transport equipments that transport Ethernet over SONET (but don't do any 
>switching/bridging).
>
>In this case should ONU1 terminate OAMPDUs from OLT1 or it should sent 
>them transparently to OLT2?
>In other words is OLT1--ONU1 considered a single link? what about ONU1 to 
>ONU2, is this also a link?
>
>Thanks in advance,
>Shahram Davari
>Senior Product Research Engineer
>R&D Research Ottawa
>PMC-Sierra, Inc.
>Phone: (613) 271-4018
>Fax:   (613) 271-6468
>