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
- Label type to be used Kireeti Kompella
- Re: Label type to be used Anca Zamfir
- Re: Label type to be used Dimitri.Papadimitriou
- Re: Label type to be used Dimitri.Papadimitriou
- Re: Label type to be used Kireeti Kompella
- Re: Label type to be used Anca Zamfir
- Re: Label type to be used Ashok Narayanan
- Re: Label type to be used Lou Berger
- Re: Label type to be used Ashok Narayanan
- Re: Label type to be used Ashok Narayanan
- Re: Label type to be used dimitri papadimitriou
- Re: Label type to be used Kireeti Kompella
- Re: Label type to be used dimitri papadimitriou
- Re: Label type to be used Kireeti Kompella
- Re: Label type to be used Lou Berger
- RE: Label type to be used Pandian, Vijay
- RE: Label type to be used John Drake
- Re: Label type to be used Ben Mack-Crane
- RE: Label type to be used John Drake
- Re: Label type to be used Kireeti Kompella
- Re: Label type to be used Arthi Ayyangar
- Re: Label type to be used Ben Mack-Crane
- Re: Label type to be used Ashok Narayanan
- RE: Label type to be used John Drake
- RE: Label type to be used Lou Berger
- RE: Label type to be used Ong, Lyndon
- Re: Label type to be used Dimitri.Papadimitriou
- RE: Label type to be used Ong, Lyndon
- Re: Label type to be used Dimitri.Papadimitriou
- RE: Label type to be used Pandian, Vijay
- Re: Label type to be used Dimitri.Papadimitriou