Re: Deconstructing OAM&P
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