-----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