Re: [HSSG] Reach Objectives
Steve-
There is something that you are talking about here that I don't
understand.
At 11:40 AM 9/2/2006 , Trowbridge, Stephen J (Steve) wrote:
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 a problem.
Preambles are not payload
Interpacket gaps are not payload.
Why are we failing to communicate?
Best regards,
Geoff
* with encryption algorithms that, for example, encrypt or even count the
"bits" (they aren't really bits) between packets.
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
disaster.
Regards,
Steve