The MPLS WG Archive

[John Drake <jdrake@calient.net>]

Juergen,

The capabilities of the LSP endpoints are an integral part of the LSP and
are advertised as link characteristics in the link state database.  

I.e., if you have a link between a PXC and a router, then the unidirectional
link from the PXC to the router is advertised as PSC, while the link from
the router to the PXC is advertised as LSC.  If you had an FA-LSP between
two routers that transited multiple PXCs, then both unidirectional LSPs
would be advertised as PSC.

In the latter case, the FA LSP may transit intermediate PXC links which are
LSC.  It is the case that the encoding of the LSP needs to be consistent
across all of the links that it transits, which I think was your concern.

In your example, if you wanted to establish an FA LSP of type LSC, then it
would begin and terminate on links in the links state database that are
advertised as links of type LSC, not not PSC or T(DM)SC.  If one wanted to
create another LSP, whose endpoints were either PSC or T(DM)SC, then that
LSP could transit the FA LSP of type LSC. 

You should probably read the GMPLS routing drafts, which explain this in
more detail.   

John   

-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Wednesday, December 06, 2000 8:53 AM
To: John Drake; Heiles Juergen; mpls@UU.NET
Cc: ip-optical@lists.bell-labs.com
Subject: RE: [IP-Optical] GMPLS - Hierarchies


John,

I agree that at the endpoints of a trail (in ITU terms), where the signal
that is connected through the network is terminated, the same processing for
the payload is needed (either multiplexing or any other kind of adaptation).
However this is not part of the LSP and of the LSR functionality. Consider a
Optical Channel/lambda LSP. According to the document - as I read it -  the
LSP is should be terminated on a LSR with Lambda switch capable (LSC)
interfaces (e.g. an optical switch), hwoever the paylaod of the Optical
Channel is a SDH or IP signal which require TDM or packet processing.
For sure you want to connect your signal between endpoints with the same
client processing, but this is only of interest for the selection of the
correct endpoints, but not for the LSP set-up itself. The LSP set up should
only care about the signal itself and not about its payload. FAX and
telphones use the same infrastrucutre for the setup of the connection, you
have to be shure to connect the same endpoints by using up to correct number
or you have a automatic selection of the correct payload processing using
signaling. This signaling should only apply to theendpoints and not to
intermediate  nodes.

Furthermore a LSP -at least for circuit switching - doesn't have to start
and end at the trail termination where you extract your payload. A LSP could
be used only for a sub part of the overall connection, e.g. a DS1 signal
starts in a user domain with tradional TMN path setup or even manual
connections, the DS1 comes to a operator which uses GMPLS for path -setup
(in this case a permanent connection set-up by himself as the user doesn't
support the UNI). The LSP starts in the middleof the overall DS1 connection
and no access to the paylaod of the DS1 is requried at that point.

	Regards

	Juergen


> -----Original Message-----
> From:	John Drake [SMTP:jdrake@calient.net]
> Sent:	Wednesday, December 06, 2000 5:14 PM
> To:	'Heiles Juergen'; mpls@UU.NET
> Cc:	ip-optical@lists.bell-labs.com
> Subject:	RE: [IP-Optical] GMPLS - Hierarchies
> 
> Jergen,
> 
> An LSP has an two endpoints.  At the ingress endpoint, a node is
> multiplexing stuff into a given LSP.  At the egress endpoint, a node is
> demultiplexing stuff from that LSP.  If the ingress and egress endpoints
> aren't multiplexing and demultiplexing stuff consistently, how is stuff
able
> to successfully transit the LSP?
> 
> Thanks,
> 
> John 
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> Sent: Wednesday, December 06, 2000 4:34 AM
> To: mpls@UU.NET
> Cc: ip-optical@lists.bell-labs.com
> Subject: [IP-Optical] GMPLS - Hierarchies
> 
> 
> draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a
> hierachy with fiber switching at the top followed by lambda, time-slot and
> packet switching and clearly distinguish between these levels. I don't
agree
> with this view that a LSP starts and ends on the same LSR type and onyl
> nesting of LSPs of different LSR types is possible.
> Take for example an optical cross-connect that switches fiber between its
> ports (=> fiber switch capable). The single or multiple lambdas on this
> fiber might be directly after the cross-connect or later combined with
other
> signals from other fibers in a WDM system => (lambda switch capable) or a
> TDM technique is used to combine several of these signals to a higher
> bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch
> capable). So a LSP that starts at LSC device ends up at a TSC device and
> might have a LSC device in between. Even an interchange of LSPs between
> packet and circuit switch capable devices is possible, take for a example
> circuit emulation via ATM. With circuit emulation you can also have a LSP
> that starts on a TSC device nested into a LSP that starts on a PSC device.
> A LSP represents a connection through the network/sub-network for a
certain> 
> signal. This is independent of the switching technologies along the route
> and at the end as long as the specific signal is supported. At both ends
> access to the specific signal has to be provided, but it doesn't matter if
> e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on
a
> single wavelength of a WDM system (not economic), over a CDMA radio system
> or with circuit emulation over an ATM network.
> The Hierarchy is defined by different signals nested into each other
> (client/server relationship), but not by the switching types.
> 
> Regards
> 
> Juergen Heiles
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical