Re: PMD discussion
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
>