[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Routing and signaling across devices with different switching cap abilities
Dimitri,
I have no concern with the existing mechanism. It seems logical to solve
this using FA-LSP's.
Thanks and best regards,
Vijay
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, April 27, 2004 3:17 AM
To: Pandian, Vijay
Cc: 'John Drake'; ccamp@ops.ietf.org
Subject: Re: Routing and signaling across devices with different
switching cap abilities
vijay, would it be possible that you clarify either your concern wrt
existing mechanisms or what you want to achieve when saying "I am
looking for a solution which does not use the FA-LSP and looks like
there is none..." what does that mean ?
thanks,
- dimitri.
Pandian, Vijay wrote:
> John,
>
> Thanks for the pointer to this paper.
>
> So, in order to provision an LSP between R1 and R2, all the Border Nodes
> must be capable of forming high order LSPs (FA-LSP)? If there is at least
> one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP
> will fail?
>
> I am looking for a solution which does not use the FA-LSP and looks like
> there is none...
>
> Please correct me if my interpretation is wrong.
>
> Thanks,
>
> Vijay
>
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Sunday, April 25, 2004 12:37 PM
> To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be'
> Cc: ccamp@ops.ietf.org
> Subject: 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
>>>
>>>
--
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