Re: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt

[Greg Bernstein <gregb@grotto-networking.com>]

Hi Tomo et. al., I know that the 16 bits that Adrian suggested seems like a lot, but wouldn't  we'd like to describe the full range of the latest fibers (this doesn't mean all the channels are populated!!!) at a narrow spacing.

At the low end of the U-band is 1675nm (179.0THz), and the high end of the O-band is 1260nm (237.9THz), and we're basing the center (per ITU-T) at 193.1THz.

So positive n would go to 3586, and negative n would go to 1130. Now given things could change in the future, tighter spacing with new modulation formats it seems that 16 bits isn't out of the question.  Remember, that an MPLS LSR doesn't usually support 2^32 LSPs on a link either ;-)

I was thinking about something involving optical bands but those definitions aren't really firm and can't really see an advantage to that.

When it comes to reporting available lambda on a link then we may want to look at ways to describe that usage in a very compact manner but I think that can be orthogonal.  For example if I have a 32 channel C-band based system and I want a compact way to represent the usage (for example in routing) I could use something like:

(Otani Lambda Label indicating low start frequency and spacing) + (Channel Count m)  + (Bit map that is m bits long  with 0/1 indication available/in use).

Similarly if I wanted to specify the range of a single wavelength colorless drop port on a ROADM I could use something like:
(Otani Lambda Label indication low start frequency and spacing) + (channel range as a 16 bit integer).

Hence, the revision to your format that Adrian suggested (below) seems reasonable, provides for growth and we can leverage its use in many other contexts!

Regards

Greg



Tomohiro Otani wrote:

Hi Adrian, Greg and Dan,

Thank you very much for your comments and feedback.
We will update the draft and distribute it for reviewing.

I basically agree with more wavelength channels. At this moment,
how many wavelengths should we support ? 1024 ?
(I was a guy of transmission, but at that time, it was 8 to 16...)

With best regards,

Tomo


Dan Li さんは書きました:
  

Hi,

If the wavelength label only has the local significance, then the routing 
problem needs to be addressed only at the level of the TE link choice, 
and wavelength assignment can be resolved locally by the switches on 
a hop-by-hop basis.

But if we can have the "global semantic" labels, we can run into the 
wavelength level to choose the path.

I also agree with Adrian on the definition of the "global semantic" label,
current the 160 wavelengths per fiber WDM system is deployed by 
some carriers, and the 320 wavelengths per fiber is under developed. 
The 640 wavelengths per fiber is expected in the near future. So the
"n" field is better to be expanded, and leave some room for the new 
technologies. 

Regards,

Dan

----- Original Message ----- 
From: "Greg Bernstein" <gregb@grotto-networking.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>; "Tomohiro Otani" <otani@kddilabs.jp>; <ho-guo@kddilabs.jp>; "K. Miyazaki" <miyazaki.keiji@jp.fujitsu.com>; "Diego Caviglia (GO/MCI)" <diego.caviglia@ericsson.com>
Sent: Thursday, October 04, 2007 1:46 AM
Subject: Re: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt


  
    

Hi folks, I agree with Adrian that this draft is very valuable for LSC 
networks. In addition, it seems that  these "global semantic" labels can 
be very useful in characterizing optical subsystems and that information 
can feed into a PCE performing the routing and wavelength assignment 
problem.

For example a single wavelength drop port on a ROADM may be either a 
fixed lambda, or a range of lambda. So I'd like to characterize  this 
port with either one of your globally defined labels or via a range 
specified by by two of your nicely defined lambdas.

Note that in ultra high capacity systems multiple optical bands could be 
used. In 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt 
we estimated that to cover a wide band fiber at the narrowest channel 
spacing currently defined (12.5GHz) would require 4800 labels. Hence 
with advances in modulation formats and narrower channel spacing 
Adrian's suggestion of 16 bits for the "n" field below allows us to 
fully characterize a wide band fiber with room to grow.

Regards

Greg B.

Adrian Farrel wrote:
    
      

Hi,

I think this draft is introducing a useful feature for LSC networks by 
allowing lambda labels to have a global semantic.

Although this work is functionally not an absolute requirement (it is 
always possible to map lambdas on a hop-by-hop basis) it is clearly a 
simplification to have a common semantic just as in the TDM label case.
      
        

---snip---
    
      

===
Section 5.2
It looks like you have already almost run out of Channel Spacing bits 
in the CS field. Given that technology developments are likely to find 
ways of decreasing the channel spacing, I would suggest allocating 
another bit to the CS field.
Similarly, n is limited to 511 (if my bit counting is right), and it 
seems to me that the potential for more than 500 lambdas on a fiber is 
not so improbable.
So, how about...
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |S|    Reserved   |               n               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
===

      
        

--snip--
    
      

The two things you do need in this section are:
1. How do I use a new Lambda Label?
  Answer: in all of the places that an existing Generalized
  Label can be used.
2. How do I tell when a new Lambda Label is being used
  and when an existing Generalized Label is being used?
  Does this remain a link local issue (as it always has done)
  or do you propose to define a new field value in the
  Generalized label Request or a new C-Type for the
  Generalized Label Object?
===
Section 6.2
As mentioned before, I think that discussion of advertising lambda 
availability is best removed from this I-D.
===
Section 7
You might like to consider that the use of a global semantic makes the 
control plane signaling information slightly more vulnerable to 
snooping and external control. I don't think this changes the security 
model, but you should mention the fact.
===
Section 10
I think [G.694.1] and [G.694.2] are probably normative references.
===

Cheers,
Adrian



      
        

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



    
      

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