[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
Hi Igor,
I understand that it is useful to be able to indicate whether
regeneration should be performed. What was less clear to me was why it
matters exactly which regenerator or laser is used. If I understand
you correctly you say that one motivation is that different regens may
have different capabilities (eg tuning range) and/or connectivity and
therefore it could make a difference which one you use from a global
optimization perspective. For example, if a fixed laser is available
at the desired wavelength it might be better to use this rather than a
tunable one in order to have more flexibility for future connections.
I'm still not clear about the restart issue though.
Thanks,
Jonas
3 nov 2009 kl. 20.40 skrev "Igor Bryskin" <IBryskin at advaoptical.com>:
> Anders,
>
> Let me try to explain this. Within a given node there could be
> multiple ways how an incoming interface:lambda could be cross-
> connected with outgoing interface: lambda:
> a) transparent;
> b) fixed regeneration;
> c) tunable regeneration;
> d) chain of tunable/fixed transponders;
> e)etc.
>
> It is quite possible that a node on its own cannot decide on what is
> the proper way to build the cross-connect simply because it cannot
> see the network-wide picture, while a centralized authority (i.e.
> PCE, NMS) can. For example, because of optical impairment
> consideration the signal should be regenerated on this node with or
> without wavelength conversion. Note also that it is possible that
> more than one tunable resources with overlapping ranges are
> available on a given link, and (in the roadm directionless
> technology) the same transponder may be available from more than one
> links.
>
> You should see by now why it is paramount to be able to specify in
> the ERO not only link/lambda pairs but also the physical IDs of
> concrete transponders.
>
> This is one reason, amother is, as Lou pointed out, restarts. Think
> about the situation when you restart the node and during restart
> procedures two LSPs are associated with wrong transponders. Then
> when you delete one LSP you will bring down unintentionally the
> other one as well.
>
> Hope this helps.
>
> Igor
>
> -----Original Message-----
> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On
> Behalf Of Anders Gavler
> Sent: Tuesday, November 03, 2009 1:56 PM
> To: Lou Berger; Greg Bernstein
> Cc: ccamp at ietf.org
> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> unique resource identification
>
> Lou,
>
> I still do not get it.
>
> As long as a node uniquely can identify an LSP that starts, ends, or
> transits this node it should also be able to uniquely map which
> local resources the LSP corresponds to (e.g. tunable or non-tunable
> transponder, wavelength, ports etc).
>
> If this is true I do not see why the label needs to directly map to
> a certain laser since they both can map to a uniquely identifiable
> LSP and this information could be stored and used at restart.
>
> /Anders
>
>
>> -----Original Message-----
>> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On
>> Behalf Of
>> Lou Berger
>> Sent: den 3 november 2009 18:58
>> To: Greg Bernstein
>> Cc: ccamp at ietf.org
>> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
>> unique
>> resource identification
>>
>> Greg,
>> In the cases I'm referring to we're talking per node resource
>> information which typically has node (pair) local scope with the
>> exception of ERO and RROs. So no, I don't think an end-to-end LSP
>> attribute is a match.
>>
>> Lou
>>
>> On 11/3/2009 12:50 PM, Greg Bernstein wrote:
>>> Lou, do you think this information is better in a label or in some
>>> kind
>>> of LSP attribute? In the WSON compatibility draft we tentatively put
>>> similar information into a new ERO subobject for attributes. Those
>>> attributes included things like modulation format, FEC, and whether
>>> regeneration should occur at a node along the path. We didn't put
>>> them
>>> with the traffic descriptor since they can change along a path. I
>>> didn't
>>> think we should put them into labels... But I'm flexible.
>>>
>>> Regards
>>>
>>> Greg
>>>
>>> Lou Berger wrote:
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>
>>> --
>>> ===================================================
>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> 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
> _______________________________________________
> CCAMP mailing list
> CCAMP at ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>