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