Re: Simplex links
Bill,
Something in your note caught my eye. Not that it was the first time that I
heard it, but my sense is that many HSSG members are very serious about
developing Ethernet PHY version for WAN applications. Setting aside for the
moment the issue of whether SONET is directly supported in one or more Ethernet
WAN PHYs, you mentioned "separate independent unidirectional" links. For the
sake of simplicity, lets call a link of this type a "simplex" link to contrast
it to a (full-)duplex link or half-duplex operation over a duplex link. I
believe that this breaks several rules in Ethernet. For example,
Auto-Negotiation doesn't quite work the same way. It seems to me that proponent
of Ethernet simplex links should generate and present to the group the
reasoning for simplex links, and what needs to be changed in Ethernet to support
simplex links.
Are there any volunteers for this activity? I'm too busy and not interested
enough in this specific issue to give this issue its just due.
Based on Jonathan's response to my question about adding Auto-Negotiation as an
HSSG objective and getting the response that Auto-Negotiation is an integral
part of Ethernet and therefore does not require a distinct objective, if nothing
is done, my assumption is that Ethernet and HSSG objectives DO NOT support
simplex links.
Best Regards,
Rich
--
"Bill St. Arnaud" wrote:
> 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@xxxxxxxxxx
> +1 613 785-0426
>
> > -----Original Message-----
> > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Hon Wah
> > Chin
> > Sent: September 1, 1999 7:05 PM
> > To: 'stds-802-3-hssg@xxxxxxxx'
> > 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.
-------------------------------------------------------------
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