| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I apologize for being unclear regarding
that part. It certainly makes a lot of people’s (typically their
competitors) lives much harder when one company develops these non-standard
features. This is usually done for good competitive reasons and if they win
customers by including such features, more power to them (I am an unabashed
capitalist!). In the particular case of LAN-PHY, both standard and proprietary
tweaks thereof, the market has spoken and there are a lot of (enterprise)
customers who want carriers to transport these signals. Many carriers want to compete
to satisfy the market’s demands for this service and buy equipment that
can do it. Many equipment vendors want to compete for that business and sell it
to them. Now the ITU doesn’t know what to do about that. In my opinion, the
ITU should stop telling the market what they should want (many defunct
companies have found this to be an unhealthy approach) and should enable the
industry to deliver fully-transparent LAN-PHY across the transport network in a
standard, compatible and interoperable way. As the ITU has repeatedly ignored users’
demands in this regards, my personal belief is that the IEEE should indeed develop
one more 10 GbE PHY (10GBASE-F?), namely one including a new sublayer (TIS?) equivalent
to WIS but which wraps the LAN-PHY signal in a G.709 OTU2 running at 11.1 Gb/s.
I’m sure I’ll get some hate mail for suggesting that one J. Drew _____________________________ Drew Perkins Chief Technology Officer Infinera Corporation 1322 Bordeaux Drive Sunnyvale, CA 94089 Phone: 408-572-5308 Cell:
408-666-1686 Fax:
408-904-4644 Email: dperkins@xxxxxxxxxxxx WWW : http://www.infinera.com _____________________________ From: Geoff Thompson
[mailto:gthompso@xxxxxxxxxx] Drew- Guys, From: Trowbridge,
Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
Sent: Saturday, September 02, 2006
6:57 PM To: Trowbridge, Stephen J (Steve) Cc:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx Subject: 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 |