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

Re: [HSSG] MAC Data Rate of Operation Objective



Jugnu,

 

The receive function in a short reach interface would only need buffers sized for the worst case lane to lane skew that this kind of link could generate.  The larger buffers needed for de-skewing lanes sent individually through a WAN could be part of a separate specification and hence have no impact on short reach interfaces.

 

What may be advantageous, however, is to consider the possibility of designing the mechanism by which the lane to lane skew is measured to be capable of operation with skew values appropriate to the WAN as well as short reach links if this can be done without making it overly complex.

 

Regards,

Pete Anslow

 

Nortel Networks UK Limited, London Rd, Harlow, Essex CM17 9NA, UK

External +44 1279 402540 Fax +44 1279 405670  ESN 742 2540

 

Email: pja@xxxxxxxxxx

 


From: OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
Sent: 16 August 2006 23:32
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] MAC Data Rate of Operation Objective

 

Steve,

 

Now I understand what you meant.  I thought you meant multi-hop from a Layer 2 point of view – i.e., switched along the way.  It’s clear you meant multi-hop from a Layer 1 perspective, but pt-pt at Layer 2.  This sounds more practical.  However, I’m still a bit concerned about the impact on buffer size.  

 

Thanks,

Jugnu

 


From: Trowbridge, Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent: Monday, August 14, 2006 8:54 PM
To: OJHA,JUGNU
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: RE: [HSSG] MAC Data Rate of Operation Objective

 

Jugnu,

Transport networks have done multi-hop with virtual concatenation for years - it is really just a matter of having a sufficient multiframe counter and sufficient buffer to perform the realignment.

 

Instead of considering a monolithic Ethernet network, imagine a multi-layer network where a lane gets carried, for example, as a 10G WAN PHY from the East to the West coast of the USA over a SONET or OTN network. At the Ethernet layer, this seems like point to point. Yet this connection might traverse many SONET or OTN network elements before being reaggregated with the other lanes of the connection.

 

Regarding concatenation of non-homogeneous lanes, even ITU-T didn't try to tackle that one. Virtual concatenation is defined for signals from VT1.5 (1.5 Mbit/s) to OPU3 (40 Gbit/s). But every member of a particular virtually concatenated group must be of the same rate.

 

The frame format is defined to allow virtual concatenation groups of as many as 256 members, although as a practical matter, groups don't get anywhere near that large. For manageability, etc., it makes more sense to concatenate 4xVC4 rather than 256xVC12.

Regards,

Steve

 


From: OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
Sent: Monday, August 14, 2006 6:07 PM
To: Trowbridge, Stephen J (Steve)
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: RE: [HSSG] MAC Data Rate of Operation Objective

Steve,

 

Many of your questions are answered in messages just exchanged between Geoff Thompson and me.  To address some of the others: 

 

A multi-hop solution without realignment/reassembly sounds difficult, if not impossible:

 

1) How would intermediate nodes read the destination MAC address?  

2) The inter-channel skew would be effectively unbounded.  

 

The question of what channel rates higher than 10G to use is related to the question of mixing and matching lanes of differing speeds.  For starters, I think we should apply some judgment on the latter issue – i.e., would anyone really want to mix 10G and 1G lanes to build a really fat pipe?  If we’re talking about a pipe of 20-100 G or more, do additional 1G increments really add any value?  Regarding lane speeds higher than 10G, the question becomes, “Can we define aggregation of lanes whose speeds are as yet unknown, or do we have to make a decision today on speeds (and hence, technologies) that don’t exist yet?”  Do we use 25G, 33.3G, 40G, 50G?  This future-gazing is a tricky business.  

 

Best wishes,

Jugnu

 

 


From: Trowbridge, Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent: Monday, August 14, 2006 3:23 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] MAC Data Rate of Operation Objective

 

John,

In some respects, I think that (A) and (B) in your description might be good candidates to tackle in separate projects (PARs).

 

Let me comment on proposal (B) first:

I would characterize this as a study of "Multiple Lane Approaches". Here, there are a number of questions to be answered:

1) Is the number of "lanes" fixed or variable?

2) Can the interface operate at reduced bandwidth in the presence of failure of individual lanes?

3) What is the network architecture governing the multi-lane interconnection? Are multiple lanes carried over a single span only, or can the lanes be carried independently across a network and only reaggregated at the endpoints? (attractive feature here: not necessary to build the new interface on every network element along a path between ultra-high rate endpoints to provide an ultra-high rate service. Network elements transporting individual lanes can be blissfully unaware that that lane is part of a larger aggregate). This network architecture has an impact on the differential delay that may need to be accommodated across the lanes when they are re-aggregated.

4) Are the individual lanes carried over existing or new physical interfaces?

5) Can we learn from or reuse the capabilities from ITU-T Virtual Concatenation and LCAS to provide this kind of physical layer aggregation?

 

Back to proposal (A), I think that even those of us who think that (B) is an important problem to solve do not believe that 10G is the highest rate we will ever have for serial transport. So the way I would like to see (A) approached is to study what the next potential serial interface rate above 10G should be and what its characteristics are. Here, we could study 100G, 40G or other rates that provide a suitable evolution and are supported by the technology.

 

40G has some attractive characteristics since it could reuse components from transport interfaces at the same rate (SONET OC-768, SDH STM-256, or OTN OTU-3). Note that in one sense, we already have WAN PHY type interfaces at 40G if you consider Ethernet frames mapped via GFP-F into SONET OC-768c, SDH VC4-256c, or OTN OPU3.

 

Of course even 40G is not the highest rate interface that we will ever build, so even if 40G is considered to be an evolutionary step along the path of increasing bandwidth, it is worth studying what the next serial rate should be above 40G.

Regards,

Steve

 

 


From: John DAmbrosia [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2006 3:20 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: [HSSG] MAC Data Rate of Operation Objective

All,

 

In regards to proposed MAC data rates, I have seen two basic proposals

 

Proposal A) 100 Gb/s

Proposal B) Scalable Solution

 

Proposal A supports the traditional 10x increase in speed. 

 

Proposal B, as presently discussed, is unbounded.  (The following are only my observations of statements made on the reflector by others)  The lowest limit proposed was a 4x10 approach for 40 Gb/s.  No upper limits have been proposed.  It has been suggested that this approach should use existing PMDs, but there have been also been comments regarding use of 10G, 25G, and 40G lambdas, but that carriers would want to leverage their existing DWDM layer, which mean baudrate in the 9.95-12.5 Gig.  Consuming wavelengths has been brought up as a possible concern.  It was also suggested that the greatest bandwidth demands are on VSR links < 50m and that the longer reach (>10km) may be able to live with 4x10G.  (Data in support of these observations that could be used to guide the creation of objectives would be welcome.)

 

An objective for Proposal A could be similar to what was done for 10 GbE– Support a speed of 100.000 Gb/s at the MAC/PLS service interface.

 

For Proposal B, given its current unbounded nature and multiple discussion points, I am not sure what would be proposed.  I am looking to the advocates of this proposal to provide some verbiage to the reflector for discussion.  Using the objective above as a basis: Support a speed greater than 10.000 Gb/s at the MAC/PLS service interface, would create too broad an objective.

 

Also for both proposals what are people’s thoughts on an objective that would specify an optional Media Independent Interface (MII)?

 

John