RE: Label type to be used

"Pandian, Vijay" <Vijay.Pandian@sycamorenet.com> Fri, 02 April 2004 03:56 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00303 for <ccamp-archive@ietf.org>; Thu, 1 Apr 2004 22:56:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9FnC-0006yt-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:56:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9FmE-0006sF-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:55:31 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Flh-0006nh-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:54:57 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9Fct-000AW0-Fe for ccamp-data@psg.com; Fri, 02 Apr 2004 03:45:51 +0000
Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Fcs-000AVh-4f for ccamp@ops.ietf.org; Fri, 02 Apr 2004 04:45:50 +0100
Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <2DL2K1CC>; Thu, 1 Apr 2004 22:49:23 -0500
Message-ID: <5533E74FC0108E41A8217C0899CA56CF081D46@mach5.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>, "Ong, Lyndon" <LyOng@Ciena.com>
Cc: 'Lou Berger' <lberger@movaz.com>, Kireeti Kompella <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: RE: Label type to be used
Date: Thu, 01 Apr 2004 22:49:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Dimitri,

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?

What exactly you mean by OCh/lambda/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?

Thanks,

Vijay


-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, April 01, 2004 5:18 PM
To: Ong, Lyndon
Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org
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: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Saturday, March 27, 2004 4:31 AM
> To: Ong, Lyndon
> Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org
> 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:lberger@movaz.com]
>>Sent: Friday, March 26, 2004 11:17 AM
>>To: Kireeti Kompella
>>Cc: ccamp@ops.ietf.org; 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:kireeti@juniper.net>mailto:kireeti@juniper.net]
>>>
>>>
>>>>Sent: Thursday, March 18, 2004 9:58 AM
>>>>To: ccamp@ops.ietf.org
>>>>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 : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491