Re: Deconstructing OAM&P
Rich,
You are correct. A full duplex Ethernet link is equivalent to the "Path" of a
SONET/SDH system. I believe that the new term that is being used in the OIF is
"Trail".
The "Line" definition within SONET/SDH are equivalent to the WAN service link. This
would apply to situations where 10GbE would be put on active DWDM systems or commercial
SONET/SDH services. The active "Line" information processing would be done on the
active DWDM or the SONET/SDH systems, not the 10GbE port or switch. The "Section"
function of SONET/SDH deals with physical fiber connections between DWDM or SONET/SDH
Line Terminating Equipment or regenerators. Again, this would not be part of the 10GbE
port or switch processing.
Within the SONET/SDH path OAM functionality are several items that would be useful.
There is a path origination identification that is equivalent to the port MAC address
of an Ethernet port. This allows service providers to identify the customer link
without looking at any of the data. It will also allow MAC to MAC link identification
without impacting any of the active traffic. There is a bit interleave parity function
that can be used to detect bit errors that also does not impact active traffic. There
is a status indicator that can send some status and link received error performance
information back to the far end port, again without impacting the active traffic.
There are other items that might also be used. I will be going over these at the Kent
meeting.
Thank you,
Roy Bynum
MCI WorldCom
Rich Taborek wrote:
> Roy,
>
> What exactly are the definitions for segment, line, and path in in SONET/SDH and
> what are their equivalents, if applicable, in Ethernet?
>
> My take is that 10 GbE will specify only full-duplex "links". If an Ethernet link
> is the same as a path, then I agree that it is proper to take a look at the
> Maintenance portion of OAM&P for possible incorporation into the objectives for 10
> GbE.
>
> However, you mentioned concentrating on the Operation and Administration components
> of OAM&P for 10 GbE and according to Hon Wah Chin, it seems that any such
> requirements are well above Ethernet and not applicable to HSSG objectives.
>
> Best regards,
> Rich
>
> --
>
> Roy Bynum wrote:
>
> > Hon,
> >
> > As you have discerned, there is a major portion of the OAM&P processing that is
> > in SONET/SDH network elements that would not be necessary in 10GbE. There are
> > three levels of OAM&P in SONET/SDH; segment, line, and path. I am proposing on
> > concentrating on the path level OAM for 10GbE. The rest of it can be left to
> > dedicated transmission systems. I will be presenting something at Kent that
> > deals with this.
> >
> > Thank you,
> > Roy Bynum
> > MCI WorldCom
> >
> > Hon Wah Chin wrote:
> >
> > > I would find a presention on SONET at a plenary useful.
> > >
> > > With what I already know, and making inferences from the
> > > words in the acronym, I have been supposing that 802.3 need
> > > mostly worry about a subset of SONET OAM&P, even if the distances
> > > are expanded.
> > >
> > > O - Operation - I could certainly use an exposition on what this covers
> > > A - Administration - Sounds like stuff that's being done at Layer 3.
> > > M - Maintenance - This certainly requires more 802.3 discussion.
> > > P - Provisioning - Most "provisioning" in the Ethernet world is actually
> > > each at Layer 3 routers, 802.1D Layer switch parameters or otherwise
> > > plug and play. The MAC layer (802.3) is much less involved.
> > >
> > > In SONET, with the powerful TDM multiplexing structure, the provisioning
> > > of the channels from OC-48 down to DS1 is an issue. As I understand it,
> > > there is complexity associated with making sure that the sub streams
> > > go to the right place. This whole area of the trace bytes would probably
> > > be less significant in an environment where every packet has an address
> > > and the provisioning is handled at Layer 2 or Layer 3.
> > >
> > > To me MAINTENANCE is the big issue. SONET OAM&P dedicates resources
> > > to the measurement/inference of the BER on various links. This allows
> > > fault isolation to particular wide area spans. In the case of in line
> > > amplifiers and regenerators, it is of great use to know which of the
> > > concatenated spans need attention.
> > >
> > > I previously commented that 802.3 has defined layer management. This
> > > has many of the required properties of helping to identify the
> > > particular failing span. It is not quite sufficient because it
> > > doesn't deal with the signalling characteristics of 1000Base (and 10
> > > Gb/s).
> > >
> > > If an 802.3 line regenerator (minimally a pair of repeaters for full
> > > duplex operation) is defined to count code violations (and perhaps
> > > bad packets - runts and giants might be enough without actually doing
> > > FCS on all packets), that can serve as a measure of line quality
> > > sufficient to identify the span that needs attention. The next
> > > question is how to pass the information to some switch or management
> > > station. Defining the regenerator as a simple 2 port switch and
> > > using an already defined management protocol would be a straightforward
> > > way of doing that. The task of defining this class of regenerator
> > > device would include addressing concerns about the costs of this approach.
> > >
> > > Obviously, I've oversimplified SONET OAM&P, and am looking forward
> > > to understanding the additional benefits of using that approach for
> > > extending packet data networks.
> > >
> > > -hwc
> > >
> > > Below, I append a list of parameters I extracted from 802.3z that
> > > might be included in those monitored by an 802.3 line regenerator.
> > >
> > > ============================================
> > >
> > > Gigabit Ethernet Performance Monitors
> > >
> > > A new transport function for extending the reach of Ethernet links
> > > might require additional management and monitoring functions. This
> > > transport function would combine aspects of the PMD (physical media
> > > dependent), PHY, MAU (Media Access Unit), Repeater, DTE-MAC. One
> > > possibility is to choose counters from the various sections and
> > > describe the set as GigEthernet Transport Performance Monitors.
> > >
> > > Here are some variables and the IEEE802.3z section describing it.
> > >
> > > MAC
> > > 1. 30.3.1.1.2 - aFramesTransmittedOK
> > > 2. 30.3.1.1.5 - aFramesReceivedOK
> > > 3. 30.3.1.1.6 - aFramesCheckSequenceErrors
> > > 4. 30.3.1.1.8 - aOctetsTransmittedOK
> > > 5. 30.3.1.1.14 - aOctetsReceivedOK
> > > 6. 30.3.1.1.25 - aFrameTooLongErrs
> > >
> > > PHY
> > > 7. 30.3.2.1.5 - aSymbolErrorDuringCarrier
> > > 8. 30.3.2.1.7 - aPhyAdminState
> > > MAC Control
> > > 9. 30.3.3.3 - aMACControlFramesTransmitted
> > > 10. 30.3.3.3 - aMACControlFramesReceived
> > > 11. 30.3.4.1 - aPAUSELinkDelayAllowance
> > > 12. 30.3.4.2 - aPAUSEMACCtrlFramesTransmitted
> > > 13. 30.3.4.3 - aPAUSEMACCtrlFramesReceived
> > > Repeater
> > > 14. 30.4.1.1.1 - aRepeaterID
> > > 15. 30.4.1.1.2 - aRepeaterType
> > > 16. 30.4.1.1.5 - aRepeaterHealthState
> > > 17. 30.4.1.1.6 - aRepeaterHealthText
> > > 18. 30.4.1.1.7 - aRepeaterHealthData
> > > Repeater Ports
> > > 19. 30.4.3.1.2 - aPortAdminState
> > > 20. 30.4.3.1.4 - aReadableFrames
> > > 21. 30.4.3.1.5 - aReadableOctets
> > > 22. 30.4.3.1.6 - aFrameCheckSequenceErrors
> > > 23. 30.4.3.1.8 - aFramesTooLong
> > > 24. 30.4.3.1.9 - aShortEvents
> > > 25. 30.4.3.1.10 - aRunts
> > > 26. 30.4.3.1.13 - aVeryLongEvents
> > > 27. 30.4.3.1.14 - aDataRateMismatches
> > > 28. 30.4.3.1.17 - aSymbolErrorDuringPacket
> > > 29. 30.4.3.1.20 - aBursts
> > > MAU
> > > 30. 30.5.1.1.2 - aMAUType
> > > 31. 30.5.1.1.4 - aMediaAvailable
> > > 32. 30.5.1.1.4 - aLoseMediaCounter
> > > 33. 30.5.1.1.7 - aMAUAdminState
> > > 34. 30.5.1.1.10 - aFalseCarriers
> > >
> > > ----
> > >
> > > Most of these are applicable to 100BaseFX for transporting
> > > 100Mb/s Ethernet
> > >
> > > - The various "AdminState"s would be combined into one
> > > overall enabled/disabled state for the channel.
> > > - The MAC counters can be replaced by the Port counters.
> > >
> > > Looking at these counters gives a picture of how well the link
> > > is doing.
> > >
> > > Classical repeaters are supposed to look for code violations and then
> > > jam all succeeding symbols in a packet once a code violation is
> > > detected in a packet. A more complete IEEE802.3 regenerator function
> > > might include transmitting idles on loss of signal. This would allow
> > > checking on the channel status before plugging in the terminals.
> > >
> > > This transport function might become a new aMAUType (which is
> > > an enumerated list in the standard). The aMediaAvailable
> > > and aLoseMediaCounter give an indication of whether the channel
> > > is up and whether the terminal equipment is up.
> > >
> > > -----------------
> > >
> > > It also assumes a fully operational Layer 2/3 entity to
> > > report status (ie via SNMP). Having these extra layers might be
> > > unreasonably expensive.
> > >
> > > but still expensive, thought logic cost continues to
> > > drop. It is possible to pass queries and counts via variation of MAC
> > > control packets, such as those defined for 802.3x or 802.3ad. The
> > > task would be to define how response packets are interpolated into
> > > the data stream.
>
> ----------------------------------------------------------
>
> Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
> Tel: 408-370-9233 Cell: 408-832-3957 Fax: 408-374-3645
> Email: rtaborek@xxxxxxxxxxxxx