RE: Routing and signaling across devices with different switching cap abilities

["Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>]

Dimitri,

Sorry for not being very clear with my previous e-mail.

Let me re-phrase my question with a different picture:

       OC-48      OC-192      NxOC-192      NxOC-192      OC-192      OC-48
   R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <----->
R2
   PSC-1      TDM         LSC           FSC           LSC         TDM
PSC-1


    OC-48
   <-----> TE-Links


R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching
Capability (SC) for the TE-Links to S1 and S2.

S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that
are in-capable of transparently switching a port/lambda (i.e., Section and
Line OH bytes are terminated and re-generated). S1 and S2 thus advertise
TE-LSA's with TDM as the SC for all their TE-Links in this picture.

L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all
their TE-Links in this picture.

FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in
this picture.

This should be a valid configuration, right? Do we need any additional SC's
in the TE-LSA's?

Given this combination of TE-LSA's, will R1 be able to compute a path to R2?

If R1 could successfully compute a PATH, what is the expected "LSP-Enc.
Type", and "Switching Type" in the Generalized Label Request Object for each
LINK?

   R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label?

   S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label?

   L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label?

   FX ---> L2: Fiber(9) and FSC(200) with "port" as the label?

   L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label?

   S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label?

How about the G-PID? Does it change as well?

How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is
incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the S1
---> L1 Link? 

Thanks,

Vijay

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Saturday, April 24, 2004 4:18 AM
> To: Pandian, Vijay
> Cc: ccamp@ops.ietf.org
> Subject: Re: Routing and signaling across devices with different
> switching cap abilities
> 
> 
> hi,
> 
> Pandian, Vijay wrote:
> > Consider a mix of devices with varying switching 
> capabilities connected as
> > follows:
> > 
> >      PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 
> <===> TDM-2 <===>
> > PSC-2
> > 
> > Is it fair to assume that PSC-1 and PSC-2 would advertise 
> TE-LSA's with
> > "PSC" as the switching capability, TDM-1 and TDM-2 would 
> advertise TE-LSA's
> > with "TDM" as the switching capability, LSC-1 and LSC-2 
> would advertise
> > TE-LSA's with "LSC" as the switching capability...?
> 
> what "fair" means in this context ? further the hierarchy refers
> to region boundaries as follows:
> 
> PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC
> 
> so assuming you're using different values (non-reported in gmpls- 
> routing see below) for TDM and LSC, GMPLS mandates that for inst.
> you're crossing region boundary at [TDM,LSC] the LSR at the edge
> of the TDM region must capable to find [LSC,TDM], and if such
> boundary doesn't exist it is fair to assume that the LSP will not
> be established - note that we've specific values for L2SC (51),
> TDM (100), LSC (150) and FSC (200) so what are you inferring with
> TDM-1 and TDM-2 ?
> 
> > Given this, would the PSC device (say PSC-1) be able to 
> compute a path using
> > CSPF to PSC-2?
> 
> well why don't you use the value defined in gmpls-routing, instead
> of trying to assess a rule for SC relationship that doesn't exist ?
> 
> > There had been some discussion regarding the type of label 
> (SUKLM vs. lambda
> > vs. port) to be used across these switching capabilities. 
> How about the
> > "LSP-Enc. Type", and "Switching Type" in the Generalized 
> Label Request
> > Object? How about the Bandwidth Encoding in the 
> SENDER_TSPEC and FLOWSPEC
> > object?
> 
> what's more precisely the question here ?
> 
> > According to rfc3471, section 3.1.1, the switching type is 
> expected to map
> > to one of the values advertised for the corresponding link. 
> In that case,
> > would the LSC-device accept a Generalized Label Request 
> with TDM switching
> > capability and "port" as the label coming from the TDM 
> capable device?
> 
> i think we've sorted out this issue, during our previous discussion,
> and the response is "the LSC interface accepts a Generalized Label 
> Request with LSC switching capability and "port" as the label coming 
> from the TDM capable device" i guess you mean when crossing the 
> [TDM,LSC] boundary
> 
> > Any clarification on this is appreciated...
> > 
> > Thanks,
> > 
> > Vijay
> > 
> > PS: During various GMPLS interop events, an additional FSC 
> (and LSC?)
> > switching capability in the TE-LSA's was required for the 
> end devices to
> > compute path.
> 
> yes, because some people didn't quite accurately translated the term 
> "port" in their implementation ("port" =/= "physical port" such as a
> fiber), but as discussed this is erroneous
> 
> hope this clarifies,
> - dimitri.
> -- 
> 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
> 
>