Re: [HSSG] Reach Objectives
I fully agree with you. This should never have been a
problem because bit transparency of the full physical layer is considerably
more than what should be needed for transport of something called Ethernet. What
should be important is transparency of the packet payload, characteristic
information, traffic units, or whatever you want to call the stuff that is
carried over an Ethernet network.
But what we learn from experience is that there isn't a lot
of way to avoid that someone uses something in a way that was never
We have discovered at least one router vendor who carries
proprietary stuff (I assume OAM) in the preamble and insists that the preamble
be carried transparently so as to not break this proprietary use. I understand
that there exists a mapping of 10 Gigabit fibre channel into Ethernet that
encodes something in the IPG.
I agree that this should never have happened, but we now
see a lot of market pressure, resulting in some network operators and
equipment vendors caving into the pressure to offer carriage of a 10G
Ethernet signal in a fully bit transparent manner - every one of
the 10.3125 Gbit/s being carried intact including the 64B/66B
In reaction to a proposal
that we now need to change the OTN bitrates in ITU-T to carry the full 10G
BASE-R signal with 64B/66B coding over an ODU2-like structure with a higher
bitrate, one of the participants quipped that it sounded like someone wants us
to change the standard so that we can carry something that isn't Ethernet over
something that isn't OTN.
What I am arguing for is
that, for the next higher rate, we avoid defining different interfaces with
slight difference in data carrying capacity. Doing this leaves open a crack
that might be used improperly (or at least WHEN it is used
improperly, it breaks something or introduces some unexpected constraint in
There is something that you are talking about here
that I don't understand.
At 11:40 AM 9/2/2006 , Trowbridge, Stephen J
David, One of the "mistakes of 10G" was
having effectively defined MACs of two slightly different rates - one for
LAN PHY and the other for WAN PHY.
While one might assume that one
would select the correct interface for the correct purpose, experience has
shown that this is not the case. We have way too many examples of cases
where someone builds something around a 10G LAN PHY and then expects it to
be transported with absolute bit transparency across a wide-area network
(e.g., a secure government application where they insist that the service
provider not touch the payload).
Here is the part I don't
understand. We (Ethernet) provide a packet service, not a SONET service. We
should be able, even with speed changes, to be able to provide absolute bit
transparency of the data portion of frames for anything going across a network
(as long as the preamble, SA, DA and type are not encoded) and absolute bit
transparency of the entire data frame if it is going across a point-to-point
connection ( i.e. bit-for-bit replication of IPGs and preambles are not
guaranteed, everything else should be).
If the customer wants to do
encryption across multiple Ethernet packets*, then what they want is not
Ethernet. If all they want is integrity of the payload then there shouldn't be
Preambles are not payload
Interpacket gaps are not
Why are we failing to communicate?
* with encryption algorithms that, for example,
encrypt or even count the "bits" (they aren't really bits) between
While some vendors have provided proprietary
solutions (e.g., an OTU2 like frame structure at a higher clock rate), there
is no standard way to do this. There are a comple of different proprietary
mappings that do not interwork with each other. None of them work in other
than a point-to-point configuration. Since the operate at a higher bitrate,
they don't have the spectral characteristics of G.959.1 interfaces. They
don't have the clock accuracy required in G.709 or follow the jitter/wander
characteristics of G.8251. And they can't be multiplexed up to standard OTU3
40 Gbit/s interfaces.
I think that it is extremely important to avoid
this debacle at the next rate. We can certainly use a variety of different
physical interfaces, but to have a variety of slightly different payload
bitrates is a