Re: Simplex links
I believe Bill's assement is correct, at least on the WAN side, but may be
not at 10G. Traffic load on network is inherently non-balanced. While
bandwidth is cheap in a LAN environment, it does cost more in a WAN setup.
As such I believe there is need for asymetrical design. I am not sure if it
should be addressed here at HSSG. I believe it should be a separate effort.
regards,
Henry Ngai
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, September 02, 1999 9:35 AM
Subject: 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
>
>
>