[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Routing and signaling across devices with different switching cap abilities
Vijay,
I'd suggest that you study
http://www.calient.net/files/IEEEGMPLSpublished.pdf
Thanks,
John
> -----Original Message-----
> From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com]
> Sent: Saturday, April 24, 2004 6:43 PM
> To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay
> Cc: ccamp@ops.ietf.org
> Subject: RE: Routing and signaling across devices with different switching
> cap abilities
>
> 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
> >
> >