[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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