The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Juergen,

What you are alluding to here is the distinction I tried to make a couple of
days ago when 'explicit' and 'implicit' LSPs were being considered, that is:
-	implicit infers that some clear user-plane header in is force that
is created at the start of the LSP and terminated at the sink of the LSP.
This is the shim header, though it can be used with even *lower* layer
server trails using PPP, FR or ATM  (you would need to draw the func arch
represenation of what I am saying here if not clear to see the trails at
play).
-	explicit infers no shim header in the user-plane...and what is
really being talked about is a common-control plane for whatever user-plane
trail overhead has been defined for the layer network technology considered,
eg ODU (for the OTN), VC4 (in a lower layer STM-N trail), etc.

These are very different cases as I think should be obvious.

You are referring to the second point above.  So now we have a concept of an
LSP that has no specific MPLS user-plane (shim) header as such, just
whatever that layer technology has been defined with.  Well that's OK.  It
does not really matter to me whether a control-plane or a management-plane
is involved in setting up the server layer trail.......lets say a VC4 for
example.  But what *is* clear and indisputable, is that there can only be 2
points that delimit that VC4 trail....the source where the VC4 trail is 1st
created and the sink where the VC4 trail is terminated (and where the client
layer network trails, if any, are exposed, eg ATM, PPP, VC12s, etc).  Now
you seem to be suggesting that the *control* entity responsible for setting
up the VC4 is somehow partitioned.  Well that's OK too I guess......and this
is how we would provision a VC4 today (ie via management) across >=2
different operator boundaries.  I think the case that is worrying you is
where this 'control' partitioning is 1/2 management and 1/2
signalling........Hm!.......would not seem brilliant, but could be made to
work I guess (bit like have S-PVCs running to some international gateway,
but not beyond I guess....not good for resilience though).

Have a think about what I am saying above and see if it helps.....I think
its just a mattter of (i) looking/drawing-out at what real trail entities
are involved in the user-plane and (ii) considering how this overall trail
is set-up as a separate issue.

neil 

> -----Original Message-----
> From:	Heiles Juergen [SMTP:Juergen.Heiles@icn.siemens.de]
> Sent:	Thursday, December 07, 2000 12:40 PM
> To:	'neil.2.harrison@bt.com'; Heiles Juergen; jdrake@calient.net;
> mpls@UU.NET
> Cc:	ip-optical@lists.bell-labs.com
> Subject:	RE: [IP-Optical] GMPLS - Hierarchies
> 
> Neil,
> 
> I think this is a fundamental question we have to anwser:
> Is the LSP always identical to a trail in the transport plane?
> In my view not necessarly. The LSP could also be a sub-network connection.
> Consider in the future a VC-4 trail crossing several operator domains.
> Some operators can automatically set-up the VC--4 path through their
> network using GMPLS. Other operators still use todays method with
> path-setup via the TMN. The operator with GMPLS sets-up a SPC for this
> VC-4 (and not any server layer) through its network. The set-up request
> for this LSP comes from the TMN and not via a UNI/NNI as the other
> operator or the user at the end-point doesn't support it. In this case the
> LSP spans only a part/sub-network connection of the overall VC-4 trail.
> I might be also only a definition problem. What is a LSP, the overall
> connection through the network or only the part that is set-up using GMPLS
> signaling?
> 
> Juergen
> 
> > -----Original Message-----
> > From:	neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com]
> > Sent:	Wednesday, December 06, 2000 11:07 PM
> > To:	Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET
> > Cc:	ip-optical@lists.bell-labs.com
> > Subject:	RE: [IP-Optical] GMPLS - Hierarchies
> > 
> > <snipped>
> > 
> > > Furthermore a LSP -at least for circuit switching - doesn't have to
> start
> > > and end at the trail termination where you extract your payload.
> > 	NH=> I fudamentally disagree *if* we are adhering to functional
> > arch. 
> > >  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.
> > 	NH=> The DSI signal is 'an LSP' in its own right......it is, after
> > all, a clear layer network trail entity.  The fact that it may be served
> (on
> > link connections, which are a partition of the end-end DS1 trail) by
> lower
> > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which
> themselves
> > are trails *but* only between their points of source/sink) is
> > academic.....the DS1 trail is completely unaware of this, and the
> layering
> > recursion of client_links=>server_trails can recurse many
> times.......its
> > stops at the duct network.
> > 	Your example *must*, and indeed does, fit this. 
> > 	neil 
> > 
> > >