Re: Label type to be used
Dimitri.Papadimitriou@alcatel.be Thu, 01 April 2004 22:35 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 RAA05016 for <ccamp-archive@ietf.org>; Thu, 1 Apr 2004 17:35:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9AmO-0004B9-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:35:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9AlS-000441-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:34:23 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9AkW-0003x2-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:33:24 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9ATi-000BeI-QP for ccamp-data@psg.com; Thu, 01 Apr 2004 22:16:02 +0000
Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9ATg-000Bde-Ft for ccamp@ops.ietf.org; Thu, 01 Apr 2004 23:16:00 +0100
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i31MFfpv021980; Fri, 2 Apr 2004 00:15:42 +0200
Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004040200153860:204 ; Fri, 2 Apr 2004 00:15:38 +0200
Message-ID: <406C950B.7010706@alcatel.be>
Date: Fri, 02 Apr 2004 00:17:47 +0200
From: Dimitri.Papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "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
References: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com>
In-Reply-To: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 00:15:39, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 00:15:41, Serialize complete at 04/02/2004 00:15:41
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Alcanet-MTA-scanned-and-authorized: yes
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.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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