Re: WISardry
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
> > >
>
> --
>
> Best Regards,
> 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