RE: Leveraging OC-192c
I disagree with your assumption about flow control being an implementation
issue because we are not dealing with an exposed interface. The direct link
of MAC/PLS data rate to the PHY data rate is pervasive in the standard. If
we choose to allow these two rates to differ, we must have a clear
specification of how that works within the standard. If the rate
compensation is not on an exposed interface an implementer does have the
flexability you write of, but 802.3 cannot push the problem off as
implementers choice.
In the standard the PHY doesn't clock information from the upper protocol
layers, MAC transmits a serial data stream through MAC/PLS service
interface primitives (it can use PHY signals to determine when to start
transmitting), which (in later generations) is converted to a parallel
nibble or byte stream by the reconcilliation sublayer which in turn is
signalled to a data rate locked PHY across a media independent interface.
While most of the interfaces between these architectural components are not
exposed, being rigorous about their definition has in my opinion been one of
the important ingredients to ethernet's success.
Bob Grow
-----Original Message-----
From: Hon Wah Chin [mailto:HWChin@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, July 26, 1999 10:51 AM
To: 'stds-802-3-hssg@xxxxxxxx'
Subject: Leveraging OC-192c
The discussion about a MAC/PLS pacing mechanism would be more
important if the interface were typically exposed. If it is
not exposed (and that's my guess), how it works is an internal
implementation issue. The PHY would clock information from the upper
protocol layers however it needs to.
This would simplify the discussion and eliminate the question of
how 802.3x interacts. Use of the 802.3x mechanism in this pacing
AND allowing flow control from the other end of the link probably
conflicts with the assumption in 802.3x that flow control packets
are not forwarded. As observed previously (Mick Seaman?), generating
such packets at the MAC/PLS interface AND forwarding such packets (without
extra internal state) received from the link can cause confusion.
The "bit time" used in the various calculations (IFG, 802.3x pause..)
can be defined at 10G or some other standard rate, probably with less
controversy.
Still, the question of a THROUGHPUT RATE TARGET interacts with
the signaling rate and packet formating to be used on the link.
Leveraging the OC-192 equipment still requires defining the packet
formating, and without flexibility in the signalling rate we have to
work on tradeoffs in the framing/formating vs throughput.
It seems to me that the leverage from the OC-192 deployment is mostly in the
regenerators. Current SONET ADMs would do not transport OC-192c trib
traffic,
The current LINE side is about 10Gb/s so there's no multiplexing or
add/drop.
The OC-192 components are ahead in volume right now, but the prospects
for 10Gb/s Ethernets would provide enough volume on their own to justify
tweaks to the component specifications, assuming no attempt is made
to push the performance 25%. The other advantage of the defined OC-192
structure is the overhead already reserved for link performance monitoring.
This saves definition work if this style of OAM&P is desired for extending
the reach of 10 Gb/s Ethernet using the deployed SONET OC-192 regenerators.
Overall, if you believe in significant 10Gb/s Ethernet volumes, leveraging
the deployed OC-192 regenerators is useful but not compelling. On a
buildout
of new links, new regnerators that clock at a slightly different clock
rate can be installed as well as old design regenerators that do exactly
what SONET OC-192 defines. Within the 40km target, regeneration would
not typically be used at all. Maybe making the physical layer
work with EDFAs will be more important than with OC-192 regenerators.