[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Generalizing WSON information...
I prefer this approach, as it also allows for mixing links that have and don't have this restriction.
Jonathan Sadler
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein
Sent: Thursday, April 16, 2009 11:11 AM
To: Drake, John E
Cc: julien.meuric@orange-ftgroup.com; ccamp@ops.ietf.org
Subject: Re: Generalizing WSON information...
Sounds like one way to encode the wavelength converter pool resource
state. Other ideas?
Regards
Greg
Drake, John E wrote:
> Greg,
>
> The work on switching capabilities, RFC4202, assumes a pool of node
> resources shared among links and was advertised as a link capability.
> When a given pool of resources was exhausted, the corresponding link
> capability was withdrawn for all links.
>
> Thanks,
>
> John
>
>
>> -----Original Message-----
>> From: Greg Bernstein [mailto:gregb@grotto-networking.com]
>> Sent: Wednesday, April 15, 2009 10:02 AM
>> To: julien.meuric@orange-ftgroup.com
>> Cc: ccamp@ops.ietf.org
>> Subject: Re: Generalizing WSON information...
>>
>> Hi Julien, interesting point. It did seem like older SDH
>> equipment did have a "time-slot continuity constraint", but I
>> never directly dealt with those systems. There was some work
>> a while ago on MS-SPRing (Diego?).
>> Maybe we need to think up a level, as you said in the usual
>> GMPLS, MPLS cases full label swapping is a typical
>> capability. Should we be explicit in the WSON case (maybe
>> with the connectivity matrix) in indicating that this may or
>> may not be the case? Right now we are being implicit about
>> this lack of wavelength (label) conversion capability.
>>
>> The notion of the shared wavelength converter pools and the
>> accompanying details seem very WSON specific. But the fact
>> that a switch or mux can't perform label exchange seems a
>> fairly general notion that we could group with other
>> generalizable information...
>>
>> Best Regards
>>
>> Greg
>>
>> julien.meuric@orange-ftgroup.com wrote:
>>
>>> Hi Greg.
>>>
>>> Just a small comment on Wavelength Converter Pool in
>>>
>> section 3.2. In some other GMPLS contexts, this may be
>> modelled as a label swapping capability, which is a common
>> enough to be considered as "Generalizable" (it's even a
>> typical case that becomes an exception due to our label
>> continuity constraint). However, as for several other
>> parameters, I don't think there is an actual need for it
>> (this is already the default); but maybe we could imagine
>> some MS-SPRing operations in SONET/SDH.
>>
>>> Regards,
>>>
>>> Julien
>>>
>>> -----Original Message-----
>>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>>> Behalf Of Greg Bernstein
>>> Sent: Tuesday, April 14, 2009 6:32 PM
>>> To: ccamp
>>> Subject: Generalizing WSON information...
>>>
>>> Hello fellow CCAMPers, at the 74th IETF meeting in San
>>>
>> Francisco the
>>
>>> question came up as to what if any of the WSON path computation
>>> information model would be useful in other technologies. Below is a
>>> first attempt at such an assesment based on the current version of
>>> draft-ietf-ccamp-rwa-info-02.txt.
>>> Existing GMPLS
>>> standard information is not included.
>>>
>>> From section 3.2 Node Information:
>>>
>>> Switched Connectivity Matrix: Generalizable:Yes. This can
>>>
>> be used to
>>
>>> model any type of asymetrical switch in any technology. Caveat:
>>> Besides optical is there any current products that can make use of
>>> this?
>>>
>>> Fixed Connectivity Matrix: Generalizable: Yes. This can be used to
>>> model fixed connectivity between ports. Caveat: Is there any need
>>> outside optical?
>>>
>>> Wavelength Converter Pool: Generally useful: No. This is very
>>> application specific to optical switching systems.
>>>
>>> From section 3.3 Link Information:
>>>
>>> Switched and Fixed Port Wavelength (label) Restrictions: Generally
>>> useful: I don't think so but open to examples. These
>>>
>> constraints must
>>
>>> be shared in the WSON case for two reasons: (a) the wavelength
>>> continuity constraint requires global label assignment, (b) WSON
>>> devices present many different types of wavelength
>>>
>> constraints. Note
>>
>>> that without requirement (a) then (b) doesn't need to be
>>>
>> shared since
>>
>>> local label (wavelength) assignment would suffice.
>>>
>>> From section 3.4 Dynamic Link information
>>>
>>> Available Wavelengths (labels): Generally useful? We need detailed
>>> wavelength availability information due to the wavelength
>>>
>> continuity
>>
>>> constraint.
>>> Way back
>>> in the old days many of us implemented bit maps to track SONET/SDH
>>> time slots but this never made it into the standards. Any
>>>
>> interest in
>>
>>> that now? Other examples?
>>>
>>> Shared Backup Wavelengths (labels): Similar to the above
>>>
>> but used in
>>
>>> efficient shared mesh backup path computation.
>>>
>>> From section 3.5 Dynamic Node Information
>>>
>>> Wavelength Converter Pool Status: Not generally applicable. Too
>>> application specific.
>>>
>>> Comments appreciated
>>>
>>> Greg
>>>
>>>
>>>
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>>
>>
>>
>
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================