Re: Deconstructing OAM&P
Roy Bynum wrote:
> 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.
This sounds appropriate. Is a fair comparison that a "Line" is equivalent to a SONET/SDH
transport which could encapsulate the payload of 10 Gbps Ethernet packets? Is the equipment
that commonly converts from one to the other commonly referred to as a bridge or router? If
it is, then this discussion is not relevant to the objectives of the HSSG. The HSSG is
focused on developing 10 Gbps Ethernet optical links to meet distance requirements of up to
40 km.
> 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.
In native Ethernet, there is no need to burden the Physical layer with overhead
specifically allocated to configuration or link maintenance and its corresponding
management. In general, packet-based LANs and SAN, including Ethernet, meet configuration,
link maintenance and general management requirements by architecting measurement facilities
at the Physical layer and Transport facilities at the MAC layer and above. The reasoning
being that since optical links typically operate at link BER rates much lower than 10^-12,
and that configuration and other management requests are very infrequent. Therefore, a more
efficient use of link bandwidth is to send management packets on an as-needed rather than
synchronous basis. This to me "impacts the active traffic" much less than does a
synchronous management transport alternative.
Please also note the protocol danger of reporting management (e.g. error) information using
the same link which recognized the error, and of using the same and loop/ring protocol to
do so. Much confusion can result, akin to playing the game of "telephone", with a group of
folks arranged in a circle whispering in each others ear. The original transmitter of the
message will typically and eventually receive a corrupted copy of the original message.
This problem is solved by employing switched architectures and higher level-based protocol
transports.
> 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
--
Best Regards,
Rich
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx