Re: WISardry
Rich,
I am still confused. How can a WIS be at the remote end and not at the local end? A link that has WIS at one end and not the other
should not work at all.
Thank you,
Roy Bynum
----- Original Message -----
From: "Rich Taborek" <rtaborek@xxxxxxxxxxxxx>
To: "HSSG" <stds-802-3-hssg@xxxxxxxx>
Sent: Monday, June 05, 2000 3:16 AM
Subject: Re: WISardry
>
> Roy,
>
> It means a WIS located at the remote end of the link, where two ends of an
> Ethernet link are designated at "local" and "remote".
>
> Best Regards,
> Rich
>
> --
>
> Roy Bynum wrote:
> >
> > Rich,
> >
> > Can you explain what you mean by "far end WIS"?
> >
> > Thank you,
> > Roy Bynum
> >
> > ----- Original Message -----
> > From: "Rich Taborek" <rtaborek@xxxxxxxxxxxxx>
> > To: "HSSG" <stds-802-3-hssg@xxxxxxxx>
> > Sent: Saturday, June 03, 2000 5:59 AM
> > Subject: Re: WISardry
> >
> > >
> > > Tom,
> > >
> > > Sorry of the delayed response. My responses are interspersed below:
> > >
> > > Tom Alexander wrote:
> > > >
> > > > Rich,
> > > >
> > > > 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
> > > > somehow.
> > >
> > > Of course. I indicated in my reply to Mr. Dave Martin and in my revised slides
> > > contained in the rate control and WIS are enabled whenever a 10 GbE LAN PHY link
> > > is operated in "WAN" mode.
> > >
> > > BTW, where does the LAN 9.87 Gbps data rate come from. My calculations show 9.92
> > > Gbps for a maximum size Ethernet frame and a minimum IPG.
> > >
> > > > - 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.
> > >
> > > WAN mode would be configured by SMT in the same manner as other options such as
> > > flow control, etc.
> > >
> > > The primary reason for the committees rejection of Auto-Negotiation at 10 Gbps
> > > is that the preferred mode of link management is to configure a link and have
> > > the link come up in the same mode after a power event or other disturbance.
> > > There is no apparent benefit in having a 10 GbE backbone negotiate down to 1
> > > Gbps on its own accord like a modem.
> > >
> > > LSS can easily accommodate WAN mode negotiation. I don't believe that we have
> > > any speeds to negotiate.
> > >
> > > > - 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).
> > >
> > > The WIS, regardless of its location at one end of the link or another as
> > > illustrated in slide 9, it a L1 bridge. It's L1 because once the MAC passes the
> > > PHY rate controlled data, the information never goes above L1. It's a bridge
> > > because the Ethernet packet stream is converted to/from a SONET frame stream.
> > >
> > > I don't understand your comment about "queuing or packet drops". Regardless of
> > > the WIS's location, and assuming that the MAC's rate control works, no queuing
> > > is required and no packets are ever dropped. Please explain.
> > >
> > > > - manual configuration of speeds at every MAC interface,
> > > > before it can be used, is highly undesirable.
> > >
> > > The root objective is to connect an Ethernet LAN link to SONET. Three methods of
> > > achieving this objective have been proposed:
> > >
> > > 1) WAN PHY w/WIS for WAN, LAN PHY for LAN;
> > > 2) LAN PHY w/WIS for WAN, LAN PHY for LAN;
> > > 3) UniPHY capable of WAN or LAN operation;
> > >
> > > Given that we have no Auto-Negotiation, 2 & 3 must be manually configured on
> > > each end. 1 required two separate PHYs. I'd rather implement a management bit
> > > rather than a specialized PHY.
> > >
> > > > 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.
> > >
> > > This is incorrect. Whenever rate control is active, and assuming that the rate
> > > is the WIS maximum data rate (9.29 Gbps), the LAN PHY to LAN PHY data rate
> > > becomes 9.29 Gbps. Note that the line rate varies according to PMD type and will
> > > be 10.3125 Gbps for Serial and 12.5 Gbps aggregate for WDM.
> > >
> > > > 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.
> > >
> > > Note that since 64B/66B is the proposed WIS packet delineation scheme that the
> > > WIS can only accept a maximum rate of 9.29 Gbps. The 66B rate is 9.58 Gbps.
> > > There is no packet drop. Clock tolerance is likely to be an issue since multiple
> > > clock domains may exist in the LAN PHY/WIS due to the MAC, 64B/66B, PMA (Mux
> > > clock). The WIS can compensate via fine adjustment of minimum IPG present in the
> > > packet stream from the rate controlled MAC.
> > >
> > > > 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.
> > >
> > > Rate control is a MAC function. Therefore, it is PHY independent. This is what
> > > layering is all about.
> > >
> > > As I pointed out to Mr. Dave Martin in a prior note: Regardless of the location
> > > of the WIS in the link, the WIS must still construct SONET compatible frames
> > > with an SPE filled with 66B words at a rate not exceeding 9.58464 Gbps with no
> > > real guidance from the MAC. Note also that WIS framing is independent of the
> > > rate control methodology (i.e. open loop, busy idle, etc.). The current proposal
> > > forces the WIS to strip out IPG inserted by the MACs rate control prior to 66B
> > > encoding of the Tx side and vice-versa on the Rx side.
> > >
> > > > 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".)
> > >
> > > The means is SMT (management) as discussed above. I assume the all 10 GbE links
> > > are configured or provisioned, in much the same manner that critical links such
> > > as SONET and mainframe channels are. No modem-like or 10/1000/1000 links are
> > > likely to be found between large switch/routers and SONET equipment.
> > >
> > > > 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.
> > >
> > > Performed by MAC rate control as described above. Pause frames are likely to be
> > > used upstream of the rate controlling MAC.
> > >
> > > > 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.
> > >
> > > Please point out my errors in this response. I might have to go back to the
> > > drawing board on our WIS design if anything I've described above is fatally
> > > flawed.
> > > >
> > > > 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.
> > >
> > > I don't see a difference in advantage which is affected by the placement of the
> > > WIS on the left or right side of the PHY in slide 9. Placing the WIS on the left
> > > requires that the PHY be a WAN PHY. I find the latter to be a non cost effective
> > > tradeoff. Please point out the error in this statement. Note that this implies
> > > that the same advantage applies regardless of whether SONET compatibility is
> > > achieved with a LAN PHY or WAN PHY. The required common denominator and reason
> > > for the advantage is the WIS.
> > >
> > > I suggest that we get on with the specification of the WIS independent of the
> > > WAN PHY. I'd be honored to endorse the PCS and WIS portions of Mr. Paul
> > > Bottorff's proposal if it were decoupled from the WAN PHY.
> > >
> > > > Regards,
> > > >
> > > > - 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:
> > > >
> > > > Stuart,
> > > >
> > > > 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,
> > > > Rich
> > > >
> > > > --
> > > > Stuart Robinson wrote:
> > > > >
> > > > > Hi Rich,
> > > > >
> > > > > I think that the confusion comes from the discussion of the standard
> > > > versus
> > > > > one possible implementation. It seems like you are trying to have
> > > > one
> > > > > implementation as the standard.
> > > > >
> > > > > If I follow your arguement, then Serial 1550nm optics may meet the
> > > > distance
> > > > > 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
> > > > (stack
> > > > > diagram on Pg 4 of
> > > > >
> > > > http://grouper.ieee.org/groups/802/3/ae/public/may00/bottorff_1_0500.pd
> > > > f).
> > > > >
> > > > > One may argue that this meets the objectives but it is not
> > > > necessarily
> > > > > optimized for applications that run over SONET infrastructure or
> > > > "Optical
> > > > > 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
> > > > achieve
> > > > > 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