Re: Point-to-Point Links
Rich,
The choice to incorporate the "WIS" in the 10Gigabit Ethernet is more a one
of timing than of lack of necessity. If the issues of large metro "service
provider" networks trying to be dependant on Gigabit Ethernet had been part
of the development of GbE, then I think that the "WIS" might have also been
part of that standard as well. The inclusion of "SONET Lite" overhead as
part of the WAN PHY is one of economics. The need in the industry for an
"Ethernet" standard that can support service providers' requirements beyond
the restricted "Metro" services is becoming very evident. The market for a
standard "Ethernet" with wide area supportability is just too great to
ignore. If the P802z task force had been aware of that market, I don't
think that they would have ignored it either.
Have a good and safe New Year.
Roy
At 09:37 PM 12/26/00 -0800, Rich Taborek wrote:
>Tom,
>
>Please see my comments below:
>
>Tom Alexander wrote:
> >
> > Rich,
> >
> > A minor point of clarification with respect to the Section, Line, Path
> business
> > in the WIS.
> >
> > You are quite correct that there is no technical objective or
> requirement for
> > distinguishing between Section, Line and Path in the WIS spec, nor does
> this
> > distinction allow the WIS to implement any kind of topology or
> hierarchy that
> > a LAN-PHY could not (i.e., anything other than dedicated point-to-point
> links
> > connecting two WIS entities). The distinction is made from a purely
> editorial
> > perspective - following the general SONET notational conventions and
> > terminology makes the text far simpler and clearer, because the WIS clause
> > is almost wholly written with direct references to SONET standards.
>
>With the exception of any text derived from a SONET standard making an
>Ethernet standard "far simpler and clearer", I agree with your point :-)
>
> > With respect to the actual SONET overhead bytes: with the exception of the
> > parity check fields, all of the overhead bytes defined for the WIS
> perform unique
> > and necessary functions. This is unlike the traditional SONET overhead
> > structure, where functions are duplicated at different levels of the
> Section/Line/Path
> > hierarchy. (As a result, there are only five non-constant fields, apart
> from the
> > parity stuff, in the WIS Section+Line+Path overhead: H1/H2, K2, J1 and G1.)
> > The parity-related fields (B1, B2 + M1, B3) have been duplicated for
> exactly
> > the reason you mention: to support management of the WIS in a manner
> > minimally consistent with standard SONET practices and management
> > platforms.
>
>I agree the SONET overhead bytes defined for the WIS perform "unique"
>functions but strongly disagree that they perform "necessary" functions.
>If these functions were indeed necessary for Ethernet, they would have
>been supported by a prior Ethernet PHYs or the 10G LAN PHY. It is only
>by choice that these SONET specific management functions are crawling up
>the Ethernet protocol stack all the way us to the WIS. I don't have a
>major problem with the WAN PHY, but lets tell it like it is.
>
> > Regarding .3x flow control over a SONET cloud: I completely agree with you
> > that Ethernet flow control was never intended to support SONET/SDH WAN
> > links. However, I cannot find anything in the draft that could be
> interpreted as
> > either giving someone license to run Ethernet flow control over a SONET
> > long-haul network, or precluding it. I suppose somebody might figure
> out how
> > to make XON/XOFF flow control work over 6000 km of fiber, but I don't see
> > why we should concern ourselves with this one way or the other.
>
>It sounds like Ben Brown will be submitting a comment to this effect and
>I'll submit a back-up comment. 802.3x flow control was designed for
>relatively short Ethernet links. In fact, it was initially designed for
>Fast Ethernet links. The maximum 1GE link distance is 5km. Even this is
>long for 802.3x flow control. 10GE 40km links are quite a stretch.
>802.3x over a SONET cloud...
>
> > Best regards,
> >
> > - Tom
> >
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > Sent: Saturday, December 23, 2000 10:41 PM
> > Cc: 802.3ae
> > Subject: Point-to-Point Links
> >
> > Ben, Brad,
> >
> > We're about 5 or 6 tangents off the old main thread by now, so I started
> > a new one. I'd like to take this opportunity to clear something up about
> > 802.3 point-to-point links, including those being specified in IEEE
> > P802.3ae. At least I'd like to see some discussion on this topic :-)
> > Section, Line and Path are not relevant for any P802.3ae links, whether
> > they be LAN or WAN links. There is quite a bit of "bleeding" of
> > management information for SONET Section, Line and Path into the WIS. I
> > assume that the reasoning for this is to support the management of this
> > SONET/SDH specific information in a "standard" manner.
> >
> > What I don't see in the current draft is any description of or any
> > requirement for the distinction of Section, Line, or Path. The link
> > between two P802.3ae PMDs, whether they be two LAN or WAN PMDs is simply
> > a point-to-point link. Section, Line and Path are only relevant in
> > SONET/SDH equipment to which a WAN PHY may be attached. In the case that
> > the SONET/SDH equipment and its associated Sections and Lines and Paths
> > bisect two WAN PHYs, we have two point-to-point links and a SONET/SDH
> > cloud in between. I don't believe that 802.3x flow was designed for the
> > latter configuration.
> >
> > I agree with Brad's wording: "Flow control is also only for
> > point-to-point links". I don't believe that either 802.3 flow control or
> > point-to-point links are applicable to or representative of "WAN links".
> > Note that "WAN link" is usually typically synonymous with SONET/SDH WAN
> > links rather than IEEE 802.2 WAN links, whether based on LAN or WAN PHY
> > links.
> >
> > We certainly have a terminology problem. WAN flow control is an issue
> > which is beyond the scope of 802.3 and simple 802.3x point-to-point flow
> > control.
> >
> > Happy Holidays,
> > Rich
> >
> > --
> >
> > Ben Brown wrote:
> > >
> > > Brad,
> > >
> > > I just wanted to pick up on something you wrote:
> > >
> > > "Booth, Bradley" wrote:
> > > >
> > > > Flow control is also only for point-to-point links.
> > > >
> > >
> > > I hope you aren't implying that a WAN link with multiple
> > > lines & sections (do I have the nomenclature correct?) is
> > > not a point-to-point link. From an ethernet MAC perspective,
> > > these are just as point-to-point as a 3 meter jumper.
> > >
> > > I can't even begin to imagine the amount of buffering
> > > required to run .3x flow control over such a link. I would
> > > be interested in a short note from someone with experience
> > > regarding what kind of potential latencies such a link
> > > might have.
> > >
> > > Thanks,
> > > Ben
> > >
> > > "Booth, Bradley" wrote:
> > > >
> > > > Time to hit the RESET button on this one. :-)
> > > >
> > > > First, you are correct in the assumption that a 40km link buffer
> requirement
> > > > (1MB, not Mbit) will greatly exceed the internal latency.
> > > >
> > > > Not everyone in the world will design equipment to work up to
> 40km. Some
> > > > will create equipment that works up to 65m, and to optimize that
> equipment,
> > > > they're not going to want to have 1MB of buffering just for flow
> control
> > > > (that would be overkill). In these short distance applications,
> knowing the
> > > > maximum latency in the link partner device and in the local device will
> > > > permit designers to optimize their flow control buffering.
> > > >
> > > > Flow control is also only for point-to-point links.
> > > >
> > > > Happy holidays,
> > > > Brad
> > > >
> > > > -----Original Message-----
> > > > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > > Sent: Friday, December 22, 2000 10:31 AM
> > > > To: Manish D. Agrawal; Boaz Shahar; Manish D.
> Agrawal;
> > > > THALER,PAT (A-Roseville,ex1); HSSG
> > > > Subject: RE: delay constraints from XGMII to
> XAUI
> > > >
> > > > Manish,
> > > >
> > > > One of the issue of the delay is that there are other
> > > > distances
> > > > involved. The 850nm 65m PHY will not have the same
> > > > transmission media
> > > > latency as the 1500nm 40km PHY. Add latency due to
> long
> > > > haul optical
> > > > services for the WAN PHY and you have got even more
> issues
> > > > with flow
> > > > control response latency. These are going to be
> issues of
> > > > discussion as we
> > > > go forward.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > At 11:32 AM 12/22/00 +0530, Manish D. Agrawal wrote:
> > > > >Hello Boaz,
> > > > >
> > > > >As you said "The only MAC requirement I can think
> of for
> > > > bounding the
> > > > >lower layer delay is for buffer sizing for 802.3x
> flow
> > > > control. That has
> > > > >been the factor for keeping the delay tables in
> various
> > > > clauses. "
> > > > >
> > > > >But, since the delay for the flow control seems to be
> > > > greater than 1 Mbit,
> > > > >why there are delay constraints of 256/212/272 bits in
> > > > various clauses,
> > > > >which are negligible as compared to the delay of 40KM
> > > > fiber?
> > > > >
> > > > >Correct me if I am wrong.
> > > > >
> > > > >Best Regards,
> > > > >Manish
> > >
> > > -----------------------------------------
> > > Benjamin Brown
> > > AMCC
> > > 2 Commerce Park West
> > > Suite 104
> > > Bedford NH 03110
> > > 603-641-9837 - Work
> > > 603-491-0296 - Cell
> > > 603-626-7455 - Fax
> > > 603-798-4115 - Home Office
> > > bbrown@xxxxxxxx
> > > -----------------------------------------
> >
> > -------------------------------------------------------
> > Richard Taborek Sr. Phone: 408-845-6102
> > Chief Technology Officer Cell: 408-832-3957
> > nSerial Corporation Fax: 408-845-6114
> > 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> > Santa Clara, CA 95054 http://www.nSerial.com
>
>--
>
>Happy Holidays,
>Rich
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com