Re: WISardry
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?