Boiling it down to the essential M
Just as a discussion point for evaluating the complexity of getting
maintenance information into and out of an Ethernet/802.3/IP
infrastructure, here is a strawman.
Use SNMP with some new MIBs, reporting performance as previously
suggested. Likely objections to this approach would be on the basis
of the implementation expense of the IP/UDP/SNMP stack, and the
management issues of assigning IP addresses to isolated and remote
equipment.
The cost of digital logic and the memory required to buffer
packets and store code is dropping very fast. The management and
assignment of IP addresses for switching and routing devices is not
an issue because managing those devices already requires IP address
assignment, and that infrastructure works. The remaining problem is
to communicate with regenerators, which might be required for long
haul links,
Since we're talking about two port devices with point-to-point
links, some simplifications can be used.
1. Special MAC address or MAC control frame encapsulation
instead of IP over Ethernet encapsulation.
2. No real need for an actual unique IP address. Some
dummy would do. (say -1 for the destination address)
3. For the purpose of looking further down the regen chain,
subtract 1 from the destination address for each expected hop.
Each regen can increment and foward, processing the frame itself
when it gets to -1 or zero.
4. For directing the response, use the "source IP address" which is
the number of hops away. It doesn't change during forwarding
and is inverted and used to generated the response "dest IP addr".
5. Non cooperating stations at the end of the chain cause timeouts.
6. Cooperating ending stations can respond with some error code saying that
the end of the regen chain has been reached.
7. 802.3 could define the MIBs and MAC addressing/type code for this
type of function, leaving the other IP/SNMP formats, addressing and
forwarding functions to another group.
8. Quick notification to upper layers of a span failure can be achieved
by assigning some IDLE_2 code which is used by regens seeing
a loss of signal or which see IDLE_2 codes come in. Layer 3
can redirect traffic while the MAC maintenance layer can probe
the chain for fault isolation.
Advantages:
1. SNMP/IP is already defined.
2. No IP address configuration.
3. No explicit topology discovery required.
4. Backward compatibility with older equipment
5. Everything works even without this
6. Minimum effort at 802.3 - Variables and MIB; Address and Type Code;
extra IDLE_2 code for span failure notification.
This kind of approach depends on store and forward. Standard
regeneration forwards bits without parsing the packet, so this either
causes delays or has to modify/invalidate packets on the fly as they
pass through. However, this amount of store and forward is
comparable to that required by proposed FEC schemes.
There might still be an issue about making sure there's enough
bandwidth to interpolate the response into the traffic stream. I
thought about using PAUSE frames, but if the endstations at the two
ends are using the also, there would be interference. We can, of
course, use the previously discussed HOLD mechanisms and restrict the
stations at the end of regenerator chains to only 95.8% of the link's
available throughput, always leaving some bandwidth for this
kind of response traffic.
I present this gedanken to show the possibility of retrieving THE key piece
of Maintenance information -- WHICH span has a problem. SONET carries
other additional information, and I look forward to understanding
their applicability to the transport of Ethernet packets at 10 Gb/s.