Re: PMD discussion (WIS related)
Tom,
I agree with most of what you're saying. But I do have some
questions/clarifications.
The validity of your arguments depends on the nature of the "flow control
mechanism". For example, if the flow control mechanism is "PHY driven"
(like busy idle) then your arguments are right on target: I don't believe
Rich's scheme will work within the current context of 802.3ae.(Rebuttals,
Rich?) But if the flow control is "MAC driven" (like open loop) then, in
theory I don't see any issues with Rich's figure. Here's the reasoning:
The MAC layer is the same for both the LAN PHY & the WAN PHY. If open loop
flow control is adopted for standardization, then the MAC layer by itself
must be capable of being configured to handle data payloads both
at 9.57Gbps & 9.29Gbps (pre 64b66b) for the LAN & WAN respectively. In
this context all it takes for Rich's depiction to work is for the MAC on
the LAN side to be configured to handle payloads at 9.29 Gbps instead of
9.57 Gbps .If it can be configured to do this for the WAN PHY, it could be
configured to do this for the LAN PHY as well. Of course the user would
have to be aware that there is a LANPHY+ WIS on the other end. Note that
"64b66b encoded data + IPG" rate is still 10Gbps. In this scenario, the
rate matching does occur in an Ethernet switch/IP router (with all the
bells & whistles you mention) and the far end bridge requires no buffering.
More comments/questions below:
> - manual configuration of speeds at every MAC interface,
> before it can be used, is highly undesirable.
Since the MAC by definition needs to be able to handle both native ethernet
& SONET rates, doesn't it have to be configured before it is used in any
case?. (Iam assuming that the rate matching mechanism is "open loop")
>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".)
If you answered "yes" to my above question, then the MAC does not need to
do any inspection. The equipment user (being aware that there is a LAN PHY
+ WIS) on the other side would configure the MAC to operate at a data rate
of 9.29Gbps. (Even in the WAN PHY case the MAC needs to be configured by
the user to operate at a data rate of 9.29 Gbps)
You raise valid concerns regarding the possibility of reverting back to EOS
type bridging solutions. The problem with EOS has been that it creates
merge points outside the IP topology and that it requires buffering at the
SONET end. In Rich's depiction there is no chance of either of this to
happen because:
* It does not require buffering at the far end
* This is just a dumb 1:1 (1 input 1 output) bridge. (does not merge
multiple inputs to a single output)
Do you see any other concerns (as far as reverting back to EOS type
solutions is concerned) ?
In summary, I don't see why parking the WIS on the far end will not work.
That being said, Iam not sure either, about whether there are enough
benefits in allowing this to be a part of the standard (it sure does cause
some confusion).
-Praveen
At 08:24 PM 06/01/2000 -0700, you 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.
> - 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.
>
>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
> >