RE: Boiling it down to the essential M
For my ideal 10GbE network I think IP address from the standard Private IP
address block would be the most effective. Using IP addresses allows us to
communicate topology information at the IP layer so that we can use
technologies like MPLS for traffic engineering and fast restoral at layer 3.
Regenerators should also IP addressable and Tx/Rx channel treated as
separate independent unidirectional paths again for MPLS management
purposes.
I firmly believe that all signalling, OAMP information must be transmitted
at the IP layer - ie we need something like SNMPv2 with extended MIBS. I
promise you there will is no guarantee that there will be a return path for
every transmit path.
Already many ISP establish unidirectional links by satellite but more likely
ISPS will start to pull out regenerators on the return path because I won't
need them for high traffic asymmetry
Bill
Bill St. Arnaud
Senior Director Network Projects
CANARIE
bill.st.arnaud@canarie.ca
+1 613 785-0426
> -----Original Message-----
> From: owner-stds-802-3-hssg@majordomo.ieee.org
> [mailto:owner-stds-802-3-hssg@majordomo.ieee.org]On Behalf Of Hon Wah
> Chin
> Sent: September 1, 1999 7:05 PM
> To: 'stds-802-3-hssg@ieee.org'
> Subject: 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.