Re: WISardry
[Date: 06/07/2000 From Seto]
Tom,
Thank you very much for your comment.
I, too, am afraid of fierce reactions from both WAN and LAN camps.
However, I believe LAN PHY's auto and/or manual speed configuration
capability to WAN PHY speed is beneficial to both parties.
The best thing is that single LAN PHY, capable of open loop control, can
access LAN and WAN seamlessly. LAN vendors can build WAN-capable switch/
router without using WIS chip, without buying expensive (?) SONET frame
analyzers. WAN vendors can sell more SONET DWDM transponders, because more
10GbE router/switches will be WAN capable. Teleco users can buy necessary
router/switch at less.
I'd appreciate more people's opinion on this.
Seto
p.s.
I promise that I will never propose Next Page in 10GbE A/N.
> Rich, Praveen, Seto-san, Ishida-san,
>
> Regarding the WIS issue: if either one of the two conditions below are met:
> a) manual configuration of any 10G Ethernet interface with regards
> to
> whether it is talking to a 'WIS-enabled' PHY at the far end,
> OR
> b) some means of autoconfiguration, such as via the LSS, to perform
> this function automatically,
>
> then I could see how placing the WIS at the far end could theoretically be
> made to work. (How system vendors might react to this is not something I
> plan to speculate on.)
>
> I do have two comments, however:
> - manual configuration is error-prone, especially as I don't see any
> way of telling whether the wrong port has been configured
> until I see packet loss at high rates in the ELTE
> - I can't see a whole lot of conceptual difference between LSS-based
> autoconfig and traditional autonegotiation with parallel
> detection (but hey, I'm not complaining!).
>
> Rich, I've appended a few comments on your previous post below. Nothing
> of great significance.
>
> Best regards,
>
> - Tom
>
> Comments:
>
> > - 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 9.87 Gb/s was computed as the goodput at the MAC
> service interface (1518/1538 * 10). It's 9.92 if you include
> the preamble as part of the "carried data", i.e., the goodput
> at the PHY service interface. In any case, it doesn't matter,
> both figures are larger than 9.58.
>
> > - 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.
>
> Re comment: only an indirect assertion that performing the
> conversion at Layer 2 or higher, in some piece of SONET
> equipment, is undesirable. I think I was agreeing with the
> intent of your slide, actually.
>
> 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.
>
> Having a WAN-PHY with WIS that cannot interoperate with the
> LAN-PHY without WIS does convert the configuration issue into
> a provisioning issue. The matter of which is preferable should in
> my view be left to the system implementer. It appears that this
> is in fact possible.
>
>
> Rich Taborek wrote:
> --------------------------------------------------------------------------
--
> --------------------------------------------------------
> 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?
>