Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] Reach Objectives

I have no difficulty that we may need WAN and LAN to meet different reach requirements. All I am saying is that this time we should keep the data rate the same so that we can carry the LAN via the WAN simply: no flow control or rate limiting, no information to be discareded from the preamble or IPG, etc.
In the transport world if we have the same payload that needs to be carried over different technologies in different "envelope" sizes, we tend to match this up using fixed stuff bytes that can be discarded with no loss of information. We don't try to squeeze a couple percent more information over one interface than the other and then find we can fit the payload over the next segment of a connection.
So if there is some fundamental reason that the envelope size for WAN and LAN needs to be different, lets at least pick a common, standard size for the letter that goes into the envelope so that we don't have any rate or information issues going from one to the other. It is all well and good to say (quoting Geoff)
"Preambles are not payload
Interpacket gaps are not payload."

but it is clear that some customers don't like it if you have to fiddle with their preambles or interframe gaps to go between LAN and WAN.

From: Frank Chang [mailto:ychang@xxxxxxxxxxx]
Sent: Sunday, September 03, 2006 1:13 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach Objectives

I like your thought to piggyback on the mature 10GbE technology, and agree Nx10G is more practical over other alternatives in the foreseeable future. But its NOT going to be a good idea to support all the existing 10G PHYs. If dig out the threads, there are alot comments (actually from potential HSSG users) requesting to minimize the number of PHYs to be defined. This is a hard lesson learned from 10GbE which historically defined too many PHY/PMDs.
10GbE has a good story for LAN-PHY and WAN-PHY versions, there exist "volume" shipments both for LAN parts, and sonet parts. So one suggestion to better leverage existing 10 GbE technology, may be beneficial to defining two reaches only: one LAN reach and one WAN reach. For example, 10G-LR (10km or 2km) can be selected to cover all the short reaches (in terms of CWDM at 1310nm window), while ER or ZR (pick one) to cover the rest longer metro reaches (in terms of WDM at 1550nm). This is equivalent to the LX4 story for 10G, while the breakpoint is how Nx10G systems could be produced more economical than N individual lanes when taking advantage of higher speed MACs or APL.    
Finally I'd like to mention we have an open-ended project defined by CFI, which was understandable based on the consideration of soliciting more supports. Now with the study group formed, its really the high time for study group to narrow down the scope. Besides I donot think more PARs is better. The important thing is (and more meaningful) to define even one that is able to get market acceptance in much reasonable timeframe.    
-----Original Message-----
From: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx]
Sent: Saturday, September 02, 2006 9:47 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach Objectives



Rather than arguing about a horse that left he barn years ago, I believe the more interesting debate is to what degree a higher speed Ethernet should be able to leverage existing 10 GbE technology. My belief is that it should to the highest degree possible and for the longest period of time that it remains the most economical solution. To be specific, I believe that an Nx10G technology will be the best solution for some number of years. Not to say that an Nx20G, Nx40G or even Nx100G will not become practical and more economical in the future. At the point it provides compelling economically to implement we should revise the standard to support that. If you agree with this, then I further submit, again, that we should support all the existing 10G PHYs, including LAN-PHY and WAN-PHY versions. This will allow us to leverage the work that’s already gone into making these transportable across the WAN without making the problem for WAN vendors any worse than it is today. Given that essentially everyone is already providing solutions to the rate mismatch problem, it is unnecessary to fix what’s already been fixed.





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





From: Trowbridge, Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent: Saturday, September 02, 2006 8:30 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: 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 intended.


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 coding!


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 the network).







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


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,


* 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.