Subject: Some key issues with Wavelength Switched Optical Networks...

From: Greg Bernstein <[email-masked]>
Date: Wed, 26 Sep 2007 16:41:32 -0700

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

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 28 Sep 2007 00:36:52 +0200

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?

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

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

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

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

minor typo on your mail below: point (c) rfc4328 (not 4238) right?
 
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. 

	1.	WDM links 
	2.	Optical transmitters

	    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) 

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

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 28 Sep 2007 12:10:49 -0700

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.
>
>  
>
> 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? 
>
>  
>
> Cheers,
>
> Igor
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Greg Bernstein [mailto:[email-masked]]
> *Sent:* Wednesday, September 26, 2007 7:42 PM
> *To:* ccamp; [email-masked]
> *Subject:* [Pce] Some key issues with Wavelength Switched Optical 
> Networks...
>
>  
>
> classic ITU-T "fabric" model (M.3100) which has been the mainstay of 
> any connection oriented switch (TDM, ATM, MPLS).
>
>    3. A PCE computes the path and wavelength assignment is
>       accomplished in a distributed fashion via signaling (e.g., using
>       label set objects)
>
> (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?
>

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 28 Sep 2007 12:46:32 -0700

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.
>  
>  
-->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.
> 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.
> 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.
> 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.
> Why there's a need of this classification? When you us Short/long is 
--> 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.
> minor typo on your mail below: point (c) rfc4328 (not 4238) right?
--> Yes.  The G.709 signaling extensions RFC.
>     *Sent:* giovedì 27 settembre 2007 1.42
>     Hi folks, I haven't seen too many comments on our draft "Framework
>     for GMPLS and PCE Control of Wavelength Switched Optical Networks"
>     (
>     So I figured I'd point out some potentially controversial issues
>     that the draft brings up.
>
>         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:
>
>        2. Two distinct PCEs, where one computes the path, and a
>           different PCE computes the wavelength assignment
>           accomplished in a distributed fashion via signaling (e.g.,
>           using label set objects)
>
>     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.
>
>     --

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 28 Sep 2007 14:43:37 -0700

Very good catch Igor. See in line.

Igor Bryskin wrote:
> --snip--
> 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!
> Igor
--snip--

---

From: "Bardalai, Snigdho" <[email-masked]>
Date: Fri, 28 Sep 2007 17:33:11 -0500

Yes, this is an interesting problem within the WSON domain and one way to solve the RSVP-TE problem is by modeling the node with the loop-back as a pass-thru node with some sort of indication within the signaling message identifying which pieces of hardware to use as part of the loop-back.
 
Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Greg Bernstein
Sent: Friday, September 28, 2007 4:44 PM
To: Igor Bryskin
Cc: ccamp; [email-masked]
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...

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

--