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