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

Re: [HSSG] Topics for Consideration



Jugnu and all:
The actual scope of the SG is a little hard to determine from the range of discussion on this reflector, but if there is interest in borrowing SONET or SONET like features, folks should look at our brethern in the RPR (resilient packet ring) group which has special expertise in this area.
 
Bruce
 
-----Original Message----- 
From: OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx] 
Sent: Tue 8/8/2006 1:29 PM 
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx 
Cc: 
Subject: Re: [HSSG] Topics for Consideration



	Marcus, 

	 

	Thanks for clarifying.  I certainly don’t mean to imply that this would require a SONET/SDH or OTN infrastructure.  As for packets over OTN, I’m not sure I consider this a pure packet network.  After all, isn’t OTN really just the next evolution of concatenated SONET/SDH frame structure?  This touches on an interesting point – no matter how much people pooh-pooh the use of SONET, ultimately we still need many of its features (fault management, etc.).  

	 

	I also don’t see why the same approach couldn’t be used for intra-office links as well as metro or backbone – i.e., just use existing PMDs/port types.  

	 

	Best wishes, 

	Jugnu 

	 

	
  _____  


	From: Marcus Duelk [mailto:duelk@xxxxxxxxxx] 
	Sent: Tuesday, August 08, 2006 12:44 PM
	To: OJHA,JUGNU
	Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
	Subject: Re: [HSSG] Topics for Consideration

	 

	
	Hi Jugnu,
	
	I think it is important to mention that the idea is to use "VCAT-like" features
	for certain types of networks, particularly when you go into the Metro space
	or beyond (backbone). Many people may associate VCAT or OTN being
	equivalent to an overlay network where you do Packet over SONET or Ethernet
	over SONET. It should be clear that VCAT or OTN can be implemented in a
	pure packet network and may give clear benefits. How this could look like in terms
	of physical ports or PMDs is exactly what you just mentioned in the last paragraph,
	i.e. VCAT (or whatever you wanna call it) will allow you to potentially reuse 
	existing 1G/10G PMDs to create a higher-speed *parallel* Ethernet PMD. You
	wouldn't need to specify what the actual line/service rate is, similar to today's provisioning
	of a Virtual Concatenated Group (VCG) where you just specify the number N of
	STS-1's that belong to your VCG. 
	
	Marcus
	
	
	OJHA,JUGNU wrote: 

	Marcus, 

	 

	Thank you for elaborating – this is indeed what I meant.  As for the increased complexity increasing the cost, I find this a bit of a red herring.  It basically implies some extra design time for the IC that would do the physical-layer aggregation.  As you mention, much of this work will have to be done anyway, to allow for member failure, deskew (synchronization), etc.  Making things flexible would add some extra work.  However, I’m not convinced it would make all that much difference relative to the NRE and overall design costs associated with the IC development.  Any difference would, of course, be amortized over the number of ICs shipped.  We have to keep in mind that for a high-volume product, the optics cost outweighs the IC cost.  If the product is not high volume, then both optics and IC costs per unit will be high in any case, particularly when you amortize development costs.  

	 

	Mike, as for what PMDs this would work over, the answer is – any.  They could be wavelengths, different fibers, or some mix of these.  Also, there’s no need for the various PMDs to be bundled into a single package (although that is certainly one implementation option).  

	 

	The bottom line is, the PMDs could stay the same as the ones we use now.  The difference would lie behind those PMDs, in the IC world.  

	 

	I hope this answers the questions.  

	 

	Best wishes, 

	Jugnu 

	 

	
  _____  


	From: Marcus Duelk [mailto:duelk@xxxxxxxxxx] 
	Sent: Monday, August 07, 2006 7:32 PM
	To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
	Subject: Re: [HSSG] Topics for Consideration

	 

	
	Mike,
	
	good questions. I think that there is a general dilemma of making the
	choice between a simple lower-cost and a more flexible, complex and 
	higher-cost solution. Probably one solution is more justified in certain
	networks (e.g. LAN/SAN) while the other is more suitable for other
	networks (e.g. MAN/WAN).
	
	I think Jugnu's idea was to eventually decouple the service rate from
	the physical line rate by using physical layer aggregation similar to VCAT.
	If you work with parallel PHYs over a WDM MAN/WAN you probably
	have to define VCAT features anyway (e.g. differential delay compensation,
	protection against loss of members, etc.). In that scenario, you wouldn't 
	necessarily have to define what the final service rate is, similar to a virtual
	concatenated group which consists of N bandwidth 'units' (e.g. STS-1's).
	Today's VCAT scales up to 256 members for one group. If you define
	something like that for Ethernet and allow your 'bandwidth units' to be 1GbE
	or 10GbE then that would scale to 256 Gb/s or 2.56 Tb/s max. service rate.
	
	These things are done nowadays for overlay networks (over TDM,
	or OTN), but in principle you could also use other metrics.
	
	Marcus
	
	
	
	Mike Bennett wrote: 

	Jugnu,
	
	OJHA,JUGNU wrote: 

	Mike, 

	 

	It seems more reasonable to me to consider finally decoupling the physical pipe size from the rigid hierarchy used in the past.  Why not simply define a scalable interface that allows inverse multiplexing (physical layer aggregation – not the type of aggregation you have described, which sounds like the current LAG) of an arbitrary (within some bounds, obviously) number of physical channels (10G) into a single logical link?  The SONET/SDH and Digital Wrapper/OTN world already has mechanisms to do this (VCAT, LCAS), and dynamically to boot.  

	 

	This would provide a much more flexible, scalable solution to customers.  

	On the surface, it seems to me that with flexibility comes complexity which leads to higher cost.  It's also not clear to me how the physical layer aggregation you propose translates to a port on a switch.  Would I have to buy an N x 10G transceiver?  Would it be a WDM-like transceiver?  Would this work with a single fiber-pair or multi-strand?  What would the relative incremental cost be (in percentages, non monetary units) to scale up?   Also, are you proposing that this would scale beyond 100G?  If so, how far?  You mention boundaries - I'm curious what you think the upper bound would be.  I hope you're planning to present something at the interim  as it would help me understand what you're really proposing and how that compares to other ideas.
	
	Regards,
	
	Mike
	
	
	
	

	In particular, it would allow them to grow capacity on any given link as needed, instead of having to install 10x10G channels up front.  Further, when they hit 100G, they wouldn’t be stuck until some other solution is defined – they could continue to grow.  

	 

	Respectfully, 

	Jugnu Ojha 

	Avago Technologies 

	 

	
  _____  


	From: Mike Bennett [mailto:mjbennett@xxxxxxx] 
	Sent: Wednesday, August 02, 2006 12:21 PM
	To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
	Subject: Re: [HSSG] Topics for Consideration

	 

	John, et al.,
	
	>
	> 
	>     Tradition of 10x leap in speed 
	
	I think the speed increase has to be 10x.  The standards development process will take at least 3.5 to 4 years to complete.  Anything less than 100G will force people who are currently aggregating 10G links to continue to use aggregation, only using fewer higher-speed, and more expensive links.   End users prefer using a single link over aggregating physical-layer links into a logical link because of the complications that come with aggregation.  The data in the CFI presentation was just a sample of cases in which network operators we're aggregating 10G links to accommodate the demand on their networks.  There will be many more by 2011 (when I expect there would be 'real' products on the market).
	
	>    Multiple Reach Targets 
	 
	>  It was also presented that the focus of this effort wasn’t for a desktop application, and >that  the cost model needs to be considered.
	
	I believe we need to adjust the cost model in such a way that it is aligned with the ecosystem.  It is unreasonable, in my opinion, to expect a 10x/3x model to apply to systems designed for wide-area/metro-area networks.  I also think it's short-sighted to ignore the rest of the ecosystem and develop Ethernet only in the part of the ecosystem where the original cost model applies.
	
	Regards,
	
	Mike 

	-- 
	Michael J. Bennett
	Sr. Network Engineer
	LBLnet Services Group
	Lawrence Berkeley Laboratory
	Tel. 510.486.7913

	
	
	
	
	

	-- 
	Michael J. Bennett
	Sr. Network Engineer
	LBLnet Services Group
	Lawrence Berkeley Laboratory
	Tel. 510.486.7913
	  

	
	
	
	

	-- 
	___________________________
	Marcus Duelk
	Bell Labs / Lucent Technologies
	Data Optical Networks Research
	 
	Crawford Hill HOH R-237
	791 Holmdel-Keyport Road
	Holmdel, NJ 07733, USA
	fon +1 (732) 888-7086
	fax +1 (732) 888-7074

	
	
	

	-- 
	___________________________
	Marcus Duelk
	Bell Labs / Lucent Technologies
	Data Optical Networks Research
	 
	Crawford Hill HOH R-237
	791 Holmdel-Keyport Road
	Holmdel, NJ 07733, USA
	fon +1 (732) 888-7086
	fax +1 (732) 888-7074