Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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