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