[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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