Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks...

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 1 Oct 2007 14:44:05 +0200

Hi Greg,

________________________________

	From: Greg Bernstein [mailto:[email-masked]] 
	Sent: venerdì 28 settembre 2007 21.47
	To: Giovanni Martinelli (giomarti)
	Cc: ccamp; [email-masked]
	Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...

	Hi Giovanni, thanks for the close read.  Looks like you caught some problems with the text.  See below for comments.
	
	Giovanni Martinelli (giomarti) wrote: 

		Hi Greg,
		 
		Sorry for the delay in replying. I'm working on this topic since a while so yes, it's interesting. Before going on specific issue I would have some question/clarification regarding the draft itself. 

		* Within Abstract and the following.
		You don't talk about Optical Cross Connects (OXC) is something missing or understated somewhere?

	-->Whoops.  We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases.  Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me.  Any suggestions are appreciated, but we are including both ROADM and OXCs. 

My doubt was coming from the ROADM definition in section 2 and picture used later on the draft. At  least in my understanding the OXC is a general case for ROADM (sort of multi-degree ROADM) but ok, it's a matter of terminology.

		 
		* Section 3.1 where you state: 
		"A fixed mapping between the 
		GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
		Does it implies a sort of network level label space? How relate with usual local label significance?

	--> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format.  In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case.
	
	This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters. 

Ok. Local significance  but global semantic (as pointed out by Adrian in a previous mail). 

		 
		* Section 3.4 Wavelength Converters 
		"Current or envisioned contexts for wavelength converters are : ..."
		Could we think to a description/model for wavelength converter that is technology agnostic? Simply something like: full conversion capability, partial conversion capability with some constrains, and may be others.

	--> The difference, between the all optical techniques and the OEO based techniques makes that difficult.

		 
		* Section 3.4. the following: 
		"4. Wavelength converters that are O-E-O based will have a restriction 
		based on the modulation format and transmission speed" 
		Not clear to me the type of restriction here when OEO happens... probably I'm missing what you mean here.

	--> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical. 

ok more clear now, although it would be nice having a general model as you marked  with TBD. 

		 
		* Section 4.1 when you talk about Lightpath temporal characteristics:
		"Lightpath connection duration has typically been thought of as 
		approximately three time frames: " 
		and the following you define: dynamics, pseudo-static, static.
		Why there's a need of this classification? When you us Short/long is compared to what?

	--> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases).  In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections.  In the RWA literature there is a similar differentiation.  Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it. 

ok, clear. I still have doubt about quantifiers but fine for the moment.
 
Thanks,
Giovanni

		 
		minor typo on your mail below: point (c) rfc4328 (not 4238) right?

	--> Yes.  The G.709 signaling extensions RFC.

		Thanks,
		Giovanni

________________________________

			From: Greg Bernstein [mailto:[email-masked]] 
			Sent: giovedì 27 settembre 2007 1.42
			To: ccamp; [email-masked]
			Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

			Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up. 
			
			(a) The draft brings up models for the following WDM network elements:

			1.	WDM links 
			2.	Optical transmitters
				
			3.	Wavelength Converters and OEO regenerators 
			4.	ROADMs, FOADMs, optical splitters and combiners. 

			    For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).
			
			(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:

			1.	A single PCE computing both the path and wavelength 
			2.	Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 
			3.	A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) 

			    Do we really need all three models?
			
			(c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?
			
			I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.
			
			Regards
			
			Greg B.
			
			-- 
			===================================================
			Dr Greg Bernstein, Grotto Networking (510) 573-2237

	-- 
	===================================================
	Dr Greg Bernstein, Grotto Networking (510) 573-2237

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 1 Oct 2007 17:16:08 +0200

Hi Igor hi Greg,

                      I think this is a very interesting discussion.  

IMHO the point Igor raised is on the boundary between network planning and circuit provisioning I mean the decision to have a node with/without conversion capability is a planning decision, likely dependent by a given traffic forecast and a physical topology.  Moreover the same consideration applies for 3R capabilities I mean is possible that an LSP needs 3R due to optical impairments.

A possible solution to say that loopback are not allowed and thus if an LSP for some reason needs a loopback the PCE must return an error.  This information can be used to improve the wavelength conversion/3R capability of the network e.g. planning the deployment of more wavelength converter.  The other solution is to allow loopback.  

Best Regards

Diego

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: venerdì 28 settembre 2007 23.44
To: Igor Bryskin
Cc: ccamp; [email-masked]
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...

Very good catch Igor. See in line.

Igor Bryskin wrote: 

--snip-- 

2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits?  

IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP.

--> I thought you were worried about accidental loops.  I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level. 
In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case.  I'll be sure to add it as an important difference in the next revision. Thanks!

Cheers, 

Igor

--snip--

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 02 Oct 2007 09:25:11 +0200

Hi Greg,

please see below

best regards,

martin

Greg Bernstein a écrit :
> Hi Igor, see comments below.
> 
> Igor Bryskin wrote:
>>
>> Greg,
>>
>>  
>>
>> I believe the draft is very useful.
>>
> --> Thanks!
>>
>>  
>>
>> I have a couple of questions comments:
>>
>>  
>>
>> 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network 
>>
>>    Optimization
>>
>>  
>>
>> How the problem of grooming of higher layer network traffic over 
>> optical trails is any different from the problem of traffic grooming 
>> in TDM (e.g. VC12 over VC4)? I mean this is a general problem of 
>> inter-layer relationship. I suggest moving all higher layer network 
>> considerations out of scope of the draft and focusing on specifics of 
>> the OCh layer.
>>
> --> Some of my co-authors agree with you on moving this section out.  
> The reason that I put it in was that the optical "Traffic Grooming" 
> problem has received a fair amount of attention in the research and 
> general technical literature and is also a driver for the use of ROADMs 
> (optical bypass).  I guess in general we've got the following 
> inter-related problems: (a) virtual network topology design, (b) lower 
> layer connection routing, (c) higher layer flow routing. In our case (b) 
> is the RWA problem, which is fairly difficult in its own right. I guess 
> I should look closely at the MLN/MRN work and see if a specific example 
> that includes RWA is mentioned.  If so then I'd feel fine removing this 
> section from the document.

Optical considerations are not explicitly covered in MRN/MLN documents
anymore, but we still talk a lot about virtual topologies in
multi-layer/region contexts.
Optical considerations were covered at the very beginning of these 
documents, at the time they were called HPN (Hybrid Photonic Networks).
http://www.tools.ietf.org/html/draft-vigoureux-ccamp-gmpls-architecture-hpn-00