Re: Deconstructing OAM&P
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.
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
> 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.
> 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.
> 1. 188.8.131.52.2 - aFramesTransmittedOK
> 2. 184.108.40.206.5 - aFramesReceivedOK
> 3. 220.127.116.11.6 - aFramesCheckSequenceErrors
> 4. 18.104.22.168.8 - aOctetsTransmittedOK
> 5. 22.214.171.124.14 - aOctetsReceivedOK
> 6. 126.96.36.199.25 - aFrameTooLongErrs
> 7. 188.8.131.52.5 - aSymbolErrorDuringCarrier
> 8. 184.108.40.206.7 - aPhyAdminState
> MAC Control
> 9. 220.127.116.11 - aMACControlFramesTransmitted
> 10. 18.104.22.168 - aMACControlFramesReceived
> 11. 22.214.171.124 - aPAUSELinkDelayAllowance
> 12. 126.96.36.199 - aPAUSEMACCtrlFramesTransmitted
> 13. 188.8.131.52 - aPAUSEMACCtrlFramesReceived
> 14. 184.108.40.206.1 - aRepeaterID
> 15. 220.127.116.11.2 - aRepeaterType
> 16. 18.104.22.168.5 - aRepeaterHealthState
> 17. 22.214.171.124.6 - aRepeaterHealthText
> 18. 126.96.36.199.7 - aRepeaterHealthData
> Repeater Ports
> 19. 188.8.131.52.2 - aPortAdminState
> 20. 184.108.40.206.4 - aReadableFrames
> 21. 220.127.116.11.5 - aReadableOctets
> 22. 18.104.22.168.6 - aFrameCheckSequenceErrors
> 23. 22.214.171.124.8 - aFramesTooLong
> 24. 126.96.36.199.9 - aShortEvents
> 25. 188.8.131.52.10 - aRunts
> 26. 184.108.40.206.13 - aVeryLongEvents
> 27. 220.127.116.11.14 - aDataRateMismatches
> 28. 18.104.22.168.17 - aSymbolErrorDuringPacket
> 29. 22.214.171.124.20 - aBursts
> 30. 126.96.36.199.2 - aMAUType
> 31. 188.8.131.52.4 - aMediaAvailable
> 32. 184.108.40.206.4 - aLoseMediaCounter
> 33. 220.127.116.11.7 - aMAUAdminState
> 34. 18.104.22.168.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.