[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on draft-otani-ccamp-gmpls-lambda-labels-00.txt
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,
Dan Li さんは書きました:
> 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
> ----- Original Message -----
> From: "Greg Bernstein" <email@example.com>
> To: "Adrian Farrel" <firstname.lastname@example.org>
> Cc: <email@example.com>; "Tomohiro Otani" <firstname.lastname@example.org>; <email@example.com>; "K. Miyazaki" <firstname.lastname@example.org>; "Diego Caviglia (GO/MCI)" <email@example.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
>> 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
>> 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.
>> Greg B.
>> Adrian Farrel wrote:
>>> 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.
>>> 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 |
>>> 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.
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237