Re: Label type to be used

[[e-mail]]

hi

> I would like a clarification on the following three combinations of your
> proposal:
> 
> 
>> >    [LSC, LSC] - label represents a G.709 OCh/lambda/port
>> >    [PSC, LSC] - label represents a G.709 OCh/lambda/port
>> >    [TDM, LSC] - label represents a G.709 OCh/lambda/port
> 
> 
> What exactly you mean by OCh?

optical channel

> What exactly you mean by OCh/lambda/port? 

these combinations described in gmpls-routing tells what the label 
represents when considering both ends of the te link from their 
interface switching capability perspective - taking the examples
here above it is either an optical channel, or a lambda or a port

> Does it mean that the devices on both sides of such a TE-Link must be able
> to generate and accept all these three types? If the answer is yes, then it
> is not clear to me how a TDM/PSC capable device be able to do that. A TDM
> device knows how to switch time slots and that's it. Does it make sense for
> a TDM capable device that is also an LTE to advertise FSC capability for the
> TE-Links?

i don't think this FSC interpretation would be inline with the
FSC definition, so the response to your last question is no

thanks,
- dimitri.

> Thanks,
> 
> Vijay
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, April 01, 2004 5:18 PM
> To: Ong, Lyndon
> Cc: 'Lou Berger'; Kireeti Kompella; [e-mail]
> Subject: Re: Label type to be used
> 
> 
> hi lyndon,
> 
> Ong, Lyndon wrote:
> 
> 
>>Hi Dimitri,
>>
>>I think it was my mistake, in testing I have seen people use
>>FSC to describe an interface to an opaque OXC with SDH framing
>>when they wish to have the entire signal (minus some SDH
>>overhead) switched rather than sorting through individual
>>channels.  On further reading of draft-ietf-ccamp-gmpls-routing-09.txt
>>it looks like section 3.5 specifically describes this as a
>>case where LSC would be advertised rather than FSC, since 
>>there is conceptually a single wavelength, is this
>>still correct?
> 
> 
> yes, this is why i have proposed the below to adapt the below
> in-line with the following paragraph of section 3.5
> 
> "   An interface  on an opaque OXC handles a single wavelength, and
>     cannot switch multiple wavelengths as a whole.  Thus, an interface on
>     an opaque OXC is always LSC, and not FSC, irrespective of whether
>     there is DWDM external to it."
> 
> 
> thanks,
> - dimitri.
> 
> 
>>Thanks,
>>
>>Lyndon
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]
>>Sent: Saturday, March 27, 2004 4:31 AM
>>To: Ong, Lyndon
>>Cc: 'Lou Berger'; Kireeti Kompella; [e-mail]
>>Subject: Re: Label type to be used
>>
>>
>>the proposal that makes a fully transparent Sonet/SDH encoded capable 
>>link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as 
>>a port and/or lambda is aligned with the evolution of the definition 
>>towards OTN (coming from the so-called pre-OTN) technology and thus 
>>probably better than trying to retain the TDM value for it (with several 
>>flavours)
>>
>>so you would have something like this when trying to harmonize in 
>>between the several documents we have tnat deals with this specific 
>>representation issue, i also think it provides the distinction you're 
>>asking for b/w fiber and so-called clear channels:
>>
>>2.4.4. Lambda-Switch Capable
>>
>>   If an interface is of type LSC, it means that the node receiving data
>>   over this interface can recognize and switch individual lambdas
>>   within the interface.  An interface that allows only one lambda per
>>   interface, and switches just that lambda is of type LSC.
>> > This includes interfaces that only support fully transparent SONET/SDH
>> > signals, as defined in [GMPLS-SONET-SDH].
>>
>>[...]
>>
>>2.4.7. Interface Switching Capabilities and Labels
>>
>>      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>> >    [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH],
>>                      [GMPLS-G709])
>> >    [LSC, LSC] - label represents a G.709 OCh/lambda/port
>> >    [FSC, FSC] - label represents a fiber (i.e. physical port)
>> >    [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH],
>>                      [GMPLS-G709])
>> >    [PSC, LSC] - label represents a G.709 OCh/lambda/port
>> >    [PSC, FSC] - label represents a fiber
>> >    [TDM, LSC] - label represents a G.709 OCh/lambda/port
>> >    [TDM, FSC] - label represents a fiber
>> >    [LSC, FSC] - label represents a fiber
>>
>> > Note: except when explicitly indicated the label encoding MUST follow 
>> > the rules defined in [RFC3471] Section 3.2.
>>
>>ps: in fact one sees here that for the "timeslot" case, the switching 
>>type TDM value equates the encoding one
>>
>>
>>Ong, Lyndon wrote:
>>
>>
>>>Hi Lou,
>>>
>>>Your proposed text looks pretty good to me.
>>>
>>>Side note: is there a way that the
>>>existing text can be clarified to distinguish
>>>between the case of only one lambda allowed
>>>on an interface and the case of fiber switching?  
>>>
>>>Currently the text seems to allow an overlap
>>>in the case of a non-channelized OC-12/48/etc. as in
>>>a sense there is only one "lambda" but you would
>>>typically request fiber switching.
>>>
>>>Cheers,
>>>
>>>Lyndon
>>>
>>>-----Original Message-----
>>>From: Lou Berger [mailto:[e-mail]]
>>>Sent: Friday, March 26, 2004 11:17 AM
>>>To: Kireeti Kompella
>>>Cc: [e-mail]; John Drake
>>>Subject: RE: Label type to be used
>>>
>>>
>>>Kireeti,
>>>        I think John's points on (a) and (c) are reasonable.  I think the
> 
> 
>>>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make 
>>>this clear are:
>>>
>>>   2.4.4. Lambda-Switch Capable
>>>
>>>   If an interface is of type LSC, it means that the node receiving data
>>>   over this interface can recognize and switch individual lambdas
>>>   within the interface.  An interface that allows only one lambda per
>>>   interface, and switches just that lambda is of type LSC.
>>>
>>>> This includes interfaces that only support fully transparent SONET/SDH
>>>>  signals, as defined in [GMPLS-SONET-SDH].
>>>
>>>and
>>>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>
>>>>     [LSC, LSC] - label represents a lambda/port
>>>
>>>       [FSC, FSC] - label represents a port on an OXC
>>>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>
>>>>     [PSC, LSC] - label represents a lambda/port
>>>
>>>       [PSC, FSC] - label represents a port
>>>
>>>>     [TDM, LSC] - label represents a lambda/port
>>>
>>>       [TDM, FSC] - label represents a port
>>>       [LSC, FSC] - label represents a port
>>>
>>>Lou
>>>
>>>PS This matches all but one implementation we've interoperated with.
>>>
>>>At 01:49 PM 3/26/2004 -0500, John Drake wrote:
>>>
>>>
>>>
>>>
>>>
>>>>>-----Original Message-----
>>>>>From: Kireeti Kompella 
>>>>
>>>>[<mailto:[e-mail]>mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>>Sent: Thursday, March 18, 2004 9:58 AM
>>>>>To: [e-mail]
>>>>>Subject: Label type to be used
>>>>>
>>>>>Hi,
>>>>>
>>>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc
>>>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>>>>>Editor's queue:
>>>>>
>>>>>In section 2.4.7 is the following table defining the type of label
>>>>>for various combinations of switching types:
>>>>>
>>>>>    [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>>>    [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>>>    [LSC, LSC] - label represents a lambda
>>>>>    [FSC, FSC] - label represents a port on an OXC
>>>>>    [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>>>    [PSC, LSC] - label represents a lambda
>>>>>    [PSC, FSC] - label represents a port
>>>>>    [TDM, LSC] - label represents a lambda
>>>>>    [TDM, FSC] - label represents a port
>>>>>    [LSC, FSC] - label represents a port
>>>>>
>>>>>The one at issue is [PSC, LSC]; above it says that the label
>>>>>represents a lambda; and in the case of [PSC, TDM] with a fully
>>>>>transparent signal, the above indicates the label represents a TDM
>>>>>time slot.  The proposal is to change this to:
>>>>>
>>>>>    [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>>>    [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>>>    [LSC, LSC] - label represents a lambda
>>>>>    [FSC, FSC] - label represents a port on an OXC
>>>>>    [PSC, TDM] - fully transparent signal: label represents a port
>>>>>                 ("transparency" is defined in [GMPLS-SONET-SDH])
>>>>>    [PSC, TDM] - non-transparent signal: label represents a TDM time
>>>>>                 slot [GMPLS-SONET-SDH]
>>>>>    [PSC, LSC] - label represents a port
>>>>>    [PSC, FSC] - label represents a port
>>>>>    [TDM, LSC] - label represents a lambda
>>>>>    [TDM, FSC] - label represents a port
>>>>>    [LSC, FSC] - label represents a port
>>>>>
>>>>>Please respond by Friday 3/26, 5pm PST with comments on:
>>>>>
>>>>>a) do you agree with the above change?
>>>>
>>>>[John Drake]
>>>>
>>>>I don't have a problem with the [PSC, LSC] change but I don't
>>>>understand the distinction between transparent and non-transparent
>>>>TDM as it pertains to GMPLS routing.  As I indicated in a previous
>>>>e-mail, I think the transparent TDM case should be handled with a
>>>>switching type of LSC and an encoding type of SDH/SONET, and I think
>>>>that this should be specified in the SDH/SONET I-D, where the distinction
>>>>between transparent and non-transparent TDM is defined, rather than in
>>>>this document.
>>>>
>>>>
>>>>
>>>>
>>>>>b) in your implementation today, what do expect the label to represent
>>>>> i) in the case of [PSC, LSC]?
>>>>
>>>>[John Drake]
>>>>
>>>>Port/lambda
>>>>
>>>>
>>>>
>>>>
>>>>> ii) in the case of [PSC, TDM] with a fully transparent signal?
>>>>>c) if you implement as the draft says, would it be a hardship to change
>>>>> this?
>>>>
>>>>[John Drake]
>>>>
>>>>N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's
> 
> pretty
> 
>>>>clear about which types of labels are in the transparent and
> 
> non-transparent
> 
>>>>TDM cases.
>>>>
>>>>
>>>>
>>>>
>>>>>If we can get closure on this, I'll take up the task of modifying the
>>>>>pending RFC with the ADs.
>>>>>
>>>>>Kireeti.
>>>>>-------
>>>
>>>
>>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]