The MPLS WG Archive

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

Neil,

I agree with you that we have to distinguish between user-plane (G.astn uses transport-plane) and control-plane.

User plane:
I fully agree with your view that the label/shim header is responsible for the connection in the IP world and a LSP is the trail.
In the circuit switched world we don't need the lable as we have already connections (the lable is a tool to bring connections to connection-less networks) and the trail is clearly defined by the layered network strucutre.

Control plane:
We can set-up a connection using signaling or by configuration hop by hop via the TMN. MPLS uses the first approach, but basically you could also configure a MPLS LSP hop by hop via the TMN. In SDH/Sonet and the OTN we have today only the TMN approach and I don't expect that all networks and users will switch to signaling on day one. So we have to cope with a mixed enviroment, some networks use signaling some not. In this case only sub-network connections of the overall trail are set-up via the control-plane using signaling. This is what I was concerned about in my first mail and what should be covered by GMPLS.

Juergen



> -----Original Message-----
> From:	neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com]
> Sent:	Thursday, December 07, 2000 2:32 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
> 
> 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 
> > > 
> > > >