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

Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification



Jonas,
	A very good question!  In the common/general setup case I think it
won't matter.  But there are cases where it may:

- In GMPLS we have a precedent of being able to use the label to
represent a specific physical resource, be it a time slot, frequency or
even port.  If we assume that this is a function worth preserving (and I
believe it is, at least with today's equipment) than it is
desirable/required to be able to use GMPLS to control a specific laser.
 Even a tunable one.  With the current definition, this isn't possible.

- The more practical/import case is graceful restart.  In certain
restart cases, the restarting node may need to match particular node
resources (e.g., tunable lasers) against a particular frequency to
ensure no data loss and the restarting node may no longer have the
information to do the matching.  In all other cases that I know about,
GMPLS allows for sufficient information for a node to reconstruct this
mapping.

- MP to CP handover may also need to identify specific node resources
(e.g., tunable lasers).

I believe these are the primary cases.

I hope this helps,
Lou

On 11/2/2009 5:35 AM, Jonas Mårtensson wrote:
> Lou,
> 
> Maybe this is a silly question but if all lasers in the system are tunable, why does it matter which one is used? Can't the node decide this locally?
> 
> Regards,
> Jonas 
> 
>> -----Original Message-----
>> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] 
>> On Behalf Of Lou Berger
>> Sent: den 30 oktober 2009 14:02
>> To: Richard Rabbat
>> Cc: ccamp at ietf.org
>> Subject: Re: [CCAMP] 
>> draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique 
>> resource identification
>>
>> Richard,
>>
>> Okay let me try again with a specific case.  If I have an rro 
>> or ero that identifies the label (lambda) per your document, 
>> how does a node know which laser the label corresponds to 
>> when all lasers in the system are tunable?
>>
>> Thanks,
>> Lou
>>
>> On 10/29/2009 2:22 PM, Richard Rabbat wrote:
>>> sorry for the lag.
>>> do you want to describe your use-case further in terms of what you 
>>> can't do and your proposed change?
>>> thanks,
>>> Richard.
>>>
>>> On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger <lberger at labn.net 
>>> <mailto:lberger at labn.net>> wrote:
>>>
>>>     Authors,
>>>            Have you given any additional thought on the 
>> repesentation of
>>>     tunable
>>>     lasers (and unique resource identification) beyond what 
>> is currently in
>>>     the draft? The current text is:
>>>       If the node has a tunable wavelength transponder, the tuning
>>>       wavelength is considered as a part of wavelength switching
>>>       operation.
>>>
>>>     In the past, labels used for TE LSPs always represented 
>> a specific
>>>     resource that is uniquely identifiable by the node that 
>> allocates the
>>>     label and resource.  Such unique identification is 
>> important/required
>>>     for certan restart and other corner cases. Your current 
>> definition works
>>>     fine for fixed lasers that can only be mapped to a 
>> single fiber.  But,
>>>     the defined global label will not uniquely identify a 
>> resource on a node
>>>     when (a) tunable lasers are used, or (b) when a node 
>> supports multiple
>>>     fixed lasers that can be (optically) switched to a 
>> particular output
>>>     interface.
>>>
>>>     What are your thoughts on how to provide such link-scoped unique
>>>     resource identification in the context of your draft?
>>>
>>>     I don't think it'll be too difficult to address this 
>> critical point, and
>>>     see a couple of straightforward solutions if you'd like 
>> to discuss
>>>     off-line.
>>>
>>>     Much thanks,
>>>     Lou
>>>
>>>
>>>     _______________________________________________
>>>     CCAMP mailing list
>>>     CCAMP at ietf.org <mailto:CCAMP at ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP at ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
> 
> 
> 
>