Re: PMD discussion
Your note deserves a thorough answer. I regret that I won't have the time until
this weekend to address it thoroughly due to other pressing matters. I have
already touched on many of your issues in a note bearing the subject:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02485.html, to this
reflector. Please see that note in the interim. I believe that you'll find many
of the answers you're looking for there.
Tom Alexander wrote:
> After spending some time thinking about your proposal to
> achieve Ethernet-to-SONET mapping by parking the WIS on
> the backside of a LAN-PHY within a Layer 1 LAN/WAN bridge,
> I regret to say that I cannot see how this would possibly
> work in the context of the current 802.3ae objectives.
> I refer you specifically to Slide 9 of the presentation
> you made at the May meeting, which shows a "WDM LAN->WAN
> via Layer 1 Bridge". Before discussing the diagram shown
> in the slide, I take the following statements as given:
> - the LAN maximum sustained data rate is 9.87 Gb/s,
> while the maximum payload rate of an STS-192c is
> 9.58 Gb/s. Thus packets will be dropped if packets
> from a LAN PHY link are directly mapped into an
> OC-192c payload without slowing down the LAN PHY link
> - the 802.3ae objectives do not provide for any form of
> autonegotiation over the link. The proposed LSS does
> not include speed negotiations, nor is it likely to
> be able to do so with current coding schemes.
> - it is highly desirable to perform the transformation
> from native Ethernet to Ethernet-over-native-SONET
> without queueing or packet drops (i.e., in an L1 bridge,
> as you have shown in your slide).
> - manual configuration of speeds at every MAC interface,
> before it can be used, is highly undesirable.
> Consider the layer model on the left side of your slide 9.
> This is a LAN PHY. If this LAN PHY is connected to another
> LAN PHY, then it will transfer data at a maximum sustained
> rate of 9.87 Gb/s. In your diagram, it is indeed connected
> to another LAN PHY (in the Bridge); thus data will be sent
> across the link between the two LAN PHYs at 9.87 Gb/s max.
> However, this data is now being driven into a WIS. The WIS
> is an STS-192c framer, and can only accept a maximum rate of
> 9.58 Gb/s. In addition, the ITU-T PHY on the right side of
> the diagram is an OC-192 PHY, which constrains the WIS data
> rate. Hence packet drop must occur. The packet drop occurs
> at the interface between the center LAN PHY and the WIS.
> Clearly, in order for packet drop to not occur, the MAC on
> the left side must self-pace down to a data rate of 9.58
> Gb/s. However, this is a LAN PHY (no WIS) and so when it is
> attached to another LAN PHY it MUST transfer data at 9.87
> Gb/s. Thus either the MAC must somehow 'know' that the far
> side possesses a WIS, or the far side must flow control the
> LAN PHY.
> Case 1: the MAC 'knows' there is a WIS on the far side. I
> see no means of doing this within the scope of the objectives.
> If the MAC inspects the local PHY, it sees a LAN PHY, and
> naturally assumes a data rate of 9.87 Gb/s. Even if the MAC
> were somehow able to interrogate the remote end, it would
> still see another LAN PHY, and continue to send at 9.87 Gb/s.
> Note that the WIS is outside the boundary of the PHY in the
> figure. ("MAC" here implies "MAC + host CPU".)
> Case 2. The far side flow controls the link down to 9.58 Gb/s.
> However, the only defined means of implementing flow control
> is via PAUSE frames. PAUSE frames require that the Bridge
> entity implement (a) a MAC and (b) a good deal of buffering.
> Neither of these is consistent with the objective of
> realizing a pure Layer 1 bridging function.
> I therefore conclude that one cannot simply place a WIS
> behind a LAN-PHY; if one does so, we automatically revert
> to the (unsatisfactory) methods of handling Ethernet over
> SONET that are currently used, which is what the WAN-PHY
> was supposed to address in the first place.
> A further point: the significant advantage of the existing
> WAN-PHY proposal that includes a WIS is that the rate
> matching between LAN and WAN PHY rates will take place
> in a Layer 2 or Layer 3 device prior to encountering the
> installed Layer 1 SONET infrastructure. This rate matching
> involves buffering, queueing, packet drops, flow control,
> statistics maintenance, quality of service, and management
> access. The equipment used in the SONET infrastructure
> today contains none of these capabilities, and neither do
> the NMS platforms (in fact, configuration and management
> of such capabilities may even be impossible due to the
> administrative boundaries involved). Ethernet switches and
> routers do, however, already contain all of the necessary
> functions and have already incurred the management overhead.
> - Tom
> P.S. You have stated that you know how to accomplish MAC/PHY
> rate control in order to implement this function. Could you
> elucidate, please?
> Rich Taborek wrote:
> I never said that that locating the WIS at the end of a LAN PHY was
> the ONLY way to connect 10 GbE to SONET. In fact, I used the word
> ALTERNATIVE in my illustration. I believe its very important to point
> out all the alternatives in a standards process, it helps us meet the
> PAR's 5 criteria.
> I'm just pointing out that the WAN PHY is not the ONLY way to provide
> SONET compatibility. Alternatively, SONET compatibility can be achieved
> with the simple and inexpensive LAN PHY and a WIS element used whenever
> it is needed. It's the WIS that provides Ethernet-to-SONET layer 1
> bridging, not the WAN PHY. I'm all for standardizing the WIS and
> leaving implementations, including the WAN PHY, out of the picture.
> That said. I'll turn your argument right around on you. It makes more
> sense that way:
> Currently, ALL Ethernet links that go into the WAN, or SONET do not
> employ a WAN PHY. Ethernet links to SONET are generally SONET,
> typically carrying Packet-Over-SONET traffic. These links are typically
> much more expensive that their Ethernet counterparts. This leads to a
> strong desire to cost reduce the links.
> The WAN PHY proposal supports 10 GbE LAN connectivity to SONET, but by
> Requiring SONET-like (sorry, but a WAN PHY bears little if any
> resemblance to Ethernet). Doesn't the WAN PHY sound like a specific
> implementation to solve a simple problem.
> BTW, I'm having a difficult time with your argument with respect to
> the 1550 nm PMD. I view 1550 nm in much the same way as the WAN PHY,
> a non optimal solution for SONET compatibility.
> Let's also not confuse the issue. The WAN PHY is not intended for use
> over the SONET infrastructure. That's SONET's domain.
> I heartily agree with your last statement: "There may be options to
> where the WIS could be placed. However, the standard should not be
> such that it dictates where."
> Are we perhaps in agreement?
> Best Regards,
> Stuart Robinson wrote:
> > Hi Rich,
> > I think that the confusion comes from the discussion of the standard
> > one possible implementation. It seems like you are trying to have
> > implementation as the standard.
> > If I follow your arguement, then Serial 1550nm optics may meet the
> > objectives in the same way your LAN PHY + WIS may meet the WAN PHY
> > objectives. However, these are not necessarily optimized for their
> > respective applications.
> > Your LAN PHY + WIS (with the WIS being in the transport equipment) is
> > putting a long interface (ie SERIAL LAN PHY) between the PCS and WIS
> > diagram on Pg 4 of
> > One may argue that this meets the objectives but it is not
> > optimized for applications that run over SONET infrastructure or
> > Network" equipment (which are actually based on SONET).
> > There may be options to where the WIS could be placed. However, the
> > standard should not be such that it dictates where. Vendors may
> > Howard's Nirvana - LAN PHY, WIS, and SERDES in one device (p16 of
> > frazier_1_0300.pdf link enclosed below).
> > Regards,
> > Stuart
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