Subject: On Labels for Wavelength Switched Optical Networks...

From: Greg Bernstein <[email-masked]>
Date: Fri, 14 Dec 2007 08:16:53 -0800

Hi folks, at the Vancouver meeting the lambda label format of Otani, et. 
al. draft-otani-ccamp-gmpls-lambda-labels-01.txt 
<http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt> 
[Otani] was presented for a second time and a few new issues seemed to 
arise. I'm writing this note to see if we can resolve these on the list 
so this work can move forward, since the label format is valuable, in 
general, to the control of wavelength switched optical networks (WSON).

First, a general 32 bit lambda label has been defined in RFC3471.  This 
previous label does not directly relate to either the wavelength or 
frequency of the light used in a lambda LSP in a standardized way (folks 
can use the 32 bits as they see fit).
To come up with a completely general "lambda label" one could/should 
define both a (i) wavelength label specified in meters and (ii) a 
frequency label specified in Hertz (Hz).  These could be specified 
either with a 32 bit IEEE floating point number or via a suitable 32 bit 
integer by suitably adjusting the base units.  We could represent the 
frequency via a 32 bit integer in MHz, then a 193.1THz light source 
could be characterized by the integer 193,100,000. Similarly we could 
represent the wavelength label via a 32 bit integer in pico meters 
(10-12 meters), then a 1550nm wavelength could be characterized by the 
integer 1,550,000.

 Now any of the previous formats could be used with the 32 bit lambda 
label already defined.  The problem here is to pick a format for 
interoperability and compatibility with potentially common wavelength 
switched control operations.
Issues with the previously mentioned formats:

(a)    While floating point numbers provide great flexibility, as a 
label they have issues when it comes to comparison operations. 

(b)   An integer format with a suitably scaled exponent is relatively 
simple and just leaves the choice of "exponent" to be decided.

(c)    Neither format contains any "context" information about the WDM 
system in general.

The format proposed in [Otani]. avoids the above three issues and 
enhances common control plane operations as follows:

(a)    The format is integer based, hence avoids issues with floating 
point comparisons.

(b)   The format is based on the widely recognized ITU-T standard grids 
(ITU-T G.694.1 and .2) and fosters interoperability more than 
potentially any other choice. 

(c)    The ITU-T grids come in various widths and hence have an inherent 
growth path.

(d)   The ITU-T grids come in both frequency (G.694.1) and wavelength 
(G.694.2) flavored versions an both are incorporated in the [Otani] 
label format.

(e)    The format includes information on the grid spacing which is 
important WDM context information useful in many label selection 
processes.  For example a tunable laser associated with a 50GHz spacing 
WDM system could specify acceptable label range via the inclusive range 
label set mechanism.  Note that only those frequencies (labels) that 
fall on the grid are supported and not intermediate frequencies.

At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger) 
that since a lambda label already exists and that existing 
implementations may make use of it that the proposed label of [Otani] 
would be better off referred to as a "G.694 label". With such a change I 
think that this label format (and accompanying draft) should move 
forward as a working group document.

Comments, suggestions, issues?

Regards

Greg B.

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

---

From: Dan Li <[email-masked]>
Date: Mon, 17 Dec 2007 10:49:15 +0800

Hi Greg,

For the last part of your email, do you mean we need a field in the 32bit label to indicate this is a G.694 label?

Thanks,

Dan

  ----- Original Message ----- 
  From: Greg Bernstein 
  To: ccamp 
  Sent: Saturday, December 15, 2007 12:16 AM
  Subject: On Labels for Wavelength Switched Optical Networks...

  Hi folks, at the Vancouver meeting the lambda label format of Otani, et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt [Otani] was presented for a second time and a few new issues seemed to arise. I'm writing this note to see if we can resolve these on the list so this work can move forward, since the label format is valuable, in general, to the control of wavelength switched optical networks (WSON).

  First, a general 32 bit lambda label has been defined in RFC3471.  This previous label does not directly relate to either the wavelength or frequency of the light used in a lambda LSP in a standardized way (folks can use the 32 bits as they see fit).
  To come up with a completely general "lambda label" one could/should define both a (i) wavelength label specified in meters and (ii) a frequency label specified in Hertz (Hz).  These could be specified either with a 32 bit IEEE floating point number or via a suitable 32 bit integer by suitably adjusting the base units.  We could represent the frequency via a 32 bit integer in MHz, then a 193.1THz light source could be characterized by the integer 193,100,000. Similarly we could represent the wavelength label via a 32 bit integer in pico meters (10-12 meters), then a 1550nm wavelength could be characterized by the integer 1,550,000.

   Now any of the previous formats could be used with the 32 bit lambda label already defined.  The problem here is to pick a format for interoperability and compatibility with potentially common wavelength switched control operations.
  Issues with the previously mentioned formats:

  <!--[if !supportLists]-->(a)    <!--[endif]-->While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.  

  <!--[if !supportLists]-->(b)   <!--[endif]-->An integer format with a suitably scaled exponent is relatively simple and just leaves the choice of "exponent" to be decided.

  <!--[if !supportLists]-->(c)    <!--[endif]-->Neither format contains any "context" information about the WDM system in general.

  The format proposed in [Otani]. avoids the above three issues and enhances common control plane operations as follows:

  <!--[if !supportLists]-->(a)    <!--[endif]-->The format is integer based, hence avoids issues with floating point comparisons.

  <!--[if !supportLists]-->(b)   <!--[endif]-->The format is based on the widely recognized ITU-T standard grids (ITU-T G.694.1 and .2) and fosters interoperability more than potentially any other choice. 

  <!--[if !supportLists]-->(c)    <!--[endif]-->The ITU-T grids come in various widths and hence have an inherent growth path.

  <!--[if !supportLists]-->(d)   <!--[endif]-->The ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2) flavored versions an both are incorporated in the [Otani] label format.

  <!--[if !supportLists]-->(e)    <!--[endif]-->The format includes information on the grid spacing which is important WDM context information useful in many label selection processes.  For example a tunable laser associated with a 50GHz spacing WDM system could specify acceptable label range via the inclusive range label set mechanism.  Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.

  At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger) that since a lambda label already exists and that existing implementations may make use of it that the proposed label of [Otani] would be better off referred to as a "G.694 label". With such a change I think that this label format (and accompanying draft) should move forward as a working group document.

  Regards

  Greg B.

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 17 Dec 2007 09:59:20 +0100

HI Greg,

            Thanks for this very useful summary.

I'm one of the author of this ID so my comment is not fully neutral :-) btw in IETF we always state that the data plane is not part of our work and in-fact we rely as much as possible on other standard bodies (IEEE, ITU-T, ...) for data plane definition.

For G.709 and G.707 (SDH) we used as label what was defined in the ITU-T.  As example the RFC4606 defines the SONET/SDH label as extension of the numbering scheme defined in G.707.

My view is that we already have a standard body (ITU-T) that defined how to identify a wavelength and that definition fits well in our 32 bits format so IMHO it is straightforward to use that definition.

My two cents

Diego

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: venerdì 14 dicembre 2007 17.17
To: ccamp
Subject: On Labels for Wavelength Switched Optical Networks...

Hi folks, at the Vancouver meeting the lambda label format of Otani, et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt <http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt>  [Otani] was presented for a second time and a few new issues seemed to arise. I'm writing this note to see if we can resolve these on the list so this work can move forward, since the label format is valuable, in general, to the control of wavelength switched optical networks (WSON).

(a)    While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.  

(b)   An integer format with a suitably scaled exponent is relatively simple and just leaves the choice of "exponent" to be decided.

(c)    Neither format contains any "context" information about the WDM system in general.

(a)    The format is integer based, hence avoids issues with floating point comparisons.

(b)   The format is based on the widely recognized ITU-T standard grids (ITU-T G.694.1 and .2) and fosters interoperability more than potentially any other choice. 

(c)    The ITU-T grids come in various widths and hence have an inherent growth path.

(d)   The ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2) flavored versions an both are incorporated in the [Otani] label format.

(e)    The format includes information on the grid spacing which is important WDM context information useful in many label selection processes.  For example a tunable laser associated with a 50GHz spacing WDM system could specify acceptable label range via the inclusive range label set mechanism.  Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.

Regards

Greg B.

---

From: Tomohiro Otani <[email-masked]>
Date: Mon, 17 Dec 2007 22:39:55 +0900

Hi Greg and Diego,

Thank you for your initiation and clarification.

As Diego clearly pointed out, we actually rely on the data plane which 
is especially
defined by ITU-T. All transmitters, MUX/DEMUXs, ROADMs and WSS's follow
the ITU-T frequency (wavelength) grid now. In that sense, it is 
advantageous for us to
compliant with that specification in terms of the control plane.

Furthermore, taking advantage of this e-mail message, I would like to 
clarify, again, the
label format definition. During the meeting, there seems to be an 
misunderstanding about
the label definition. It has some bits to indicate a wavelength spacing, 
but this info. is utilized
only to calculate the wavelength value for switching, not to control the 
channel spacing of
the node itself.

Regards,

Tomo

Diego Caviglia さんは書きました:
> I’m one of the author of this ID so my comment is not fully neutral J 
> btw in IETF we always state that the data plane is not part of our 
> work and in-fact we rely as much as possible on other standard bodies 
> (IEEE, ITU-T, …) for data plane definition.
>
> For G.709 and G.707 (SDH) we used as label what was defined in the 
> ITU-T. As example the RFC4606 defines the SONET/SDH label as extension 
> of the numbering scheme defined in G.707.
>
> My view is that we already have a standard body (ITU-T) that defined 
> how to identify a wavelength and that definition fits well in our 32 
> bits format so IMHO it is straightforward to use that definition.
>
> My two cents
>
>
> Diego
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Greg Bernstein
> *Sent:* venerdì 14 dicembre 2007 17.17
> *To:* ccamp
> *Subject:* On Labels for Wavelength Switched Optical Networks...
>
> Hi folks, at the Vancouver meeting the lambda label format of Otani, 
> et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt 
> arise. I'm writing this note to see if we can resolve these on the 
> list so this work can move forward, since the label format is 
> valuable, in general, to the control of wavelength switched optical 
> networks (WSON).
>
> frequency of the light used in a lambda LSP in a standardized way 
> (folks can use the 32 bits as they see fit).
> either with a 32 bit IEEE floating point number or via a suitable 32 
> bit integer by suitably adjusting the base units. We could represent 
> the frequency via a 32 bit integer in MHz, then a 193.1THz light 
> source could be characterized by the integer 193,100,000. Similarly we 
> could represent the wavelength label via a 32 bit integer in pico 
> meters (10-12 meters), then a 1550nm wavelength could be characterized 
> by the integer 1,550,000.
>
> (a) While floating point numbers provide great flexibility, as a label 
> they have issues when it comes to comparison operations.
>
> simple and just leaves the choice of “exponent” to be decided.
>
> (c) Neither format contains any “context” information about the WDM 
> system in general.
>
> WDM system could specify acceptable label range via the inclusive 
> range label set mechanism. Note that only those frequencies (labels) 
> that fall on the grid are supported and not intermediate frequencies.
>
>
> At the CCAMP WG meeting in Vancouver it was pointed out (by Lou 
> Berger) that since a lambda label already exists and that existing 
> would be better off referred to as a “G.694 label”. With such a change 
> I think that this label format (and accompanying draft) should move

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 20 Dec 2007 07:39:06 -0800

Hi folks I've gotten a couple of questions on my note, so I wanted to 
clarify. The essence of the discussion below is to show that  no 
significantly simpler method exists to specify a global label for 
lambdas (in either frequency or wavelength) and that the label of 
[Otani] has the advantage of being based on a widely accepted and used 
standard.  I do not think that we need to modify the label of [Otani] in 
any significant way, though I have discussed with the authors a slight 
"tweak" to the CWDM format to more closely mirror the DWDM format.

Regards

Greg B.

Greg Bernstein wrote:
> First, a general 32 bit lambda label has been defined in RFC3471.  
> This previous label does not directly relate to either the wavelength 
> or frequency of the light used in a lambda LSP in a standardized way 
> (b)   The format is based on the widely recognized ITU-T standard 
> grids (ITU-T G.694.1 and .2) and fosters interoperability more than 
> processes.  For example a tunable laser associated with a 50GHz 
> spacing WDM system could specify acceptable label range via the 
> inclusive range label set mechanism.  Note that only those frequencies 
> (labels) that fall on the grid are supported and not intermediate 
> frequencies.
>
>  
> would be better off referred to as a "G.694 label". With such a change

---

From: "Richard Rabbat" <[email-masked]>
Date: Thu, 20 Dec 2007 10:53:51 -0800

hey Greg,
When you have a minute, can you send out the proposal for the slight tweak?
I put these together to make things simpler and they're perfect :)
Richard.

On Dec 20, 2007 7:39 AM, Greg Bernstein <[email-masked]> wrote:

> significantly simpler method exists to specify a global label for lambdas
> (in either frequency or wavelength) and that the label of [Otani] has the
> advantage of being based on a widely accepted and used standard.  I do not
> think that we need to modify the label of [Otani] in any significant way,
> though I have discussed with the authors a slight "tweak" to the CWDM format
> to more closely mirror the DWDM format.
>
> Regards
>
> Greg B.
>
>
> Greg Bernstein wrote:
>
> al. draft-otani-ccamp-gmpls-lambda-labels-01.txt<http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt>[Otani] was presented for a second time and a few new issues seemed to
> arise. I'm writing this note to see if we can resolve these on the list so
> this work can move forward, since the label format is valuable, in general,
> to the control of wavelength switched optical networks (WSON).
>
> frequency of the light used in a lambda LSP in a standardized way (folks can
> use the 32 bits as they see fit).
> define both a (i) wavelength label specified in meters and (ii) a frequency
> label specified in Hertz (Hz).  These could be specified either with a 32
> bit IEEE floating point number or via a suitable 32 bit integer by suitably
> adjusting the base units.  We could represent the frequency via a 32 bit
> integer in MHz, then a 193.1THz light source could be characterized by the
> integer 193,100,000. Similarly we could represent the wavelength label via a
> 32 bit integer in pico meters (10-12 meters), then a 1550nm wavelength could
> be characterized by the integer 1,550,000.
>
> The format proposed in [Otani]. avoids the above three issues and enhances
> common control plane operations as follows:
>
> (ITU-T G.694.1 and .2) and fosters interoperability more than potentially
> any other choice.
>
> (d)   The ITU-T grids come in both frequency (G.694.1) and wavelength (
> G.694.2) flavored versions an both are incorporated in the [Otani] label
> format.
>
> important WDM context information useful in many label selection processes.
> For example a tunable laser associated with a 50GHz spacing WDM system
> could specify acceptable label range via the inclusive range label set
> mechanism.  Note that only those frequencies (labels) that fall on the
> grid are supported and not intermediate frequencies.
>
>
> that since a lambda label already exists and that existing implementations
> may make use of it that the proposed label of [Otani] would be better off
> referred to as a "G.694 label". With such a change I think that this label
> format (and accompanying draft) should move forward as a working group
> document.
>