Subject: RE: [IP-Optical] GMPLS - Hierarchies

From: John Drake <[email-masked]>
Date: Wed, 6 Dec 2000 08:14:03 -0800

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:[email-masked]]
Sent: Wednesday, December 06, 2000 4:34 AM
To: [email-masked]
Cc: [email-masked]
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
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: John Drake <[email-masked]>
Date: Wed, 6 Dec 2000 10:01:29 -0800

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:[email-masked]]
Sent: Wednesday, December 06, 2000 8:53 AM
To: John Drake; Heiles Juergen; [email-masked]
Cc: [email-masked]
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

> From:	John Drake [SMTP:[email-masked]]
> Sent:	Wednesday, December 06, 2000 5:14 PM
> To:	'Heiles Juergen'; [email-masked]
> Subject:	RE: [IP-Optical] GMPLS - Hierarchies
> 
> Jergen,
> 
> A LSP represents a connection through the network/sub-network for a
certain>

---

From: [email-masked]
Date: Wed, 6 Dec 2000 22:06:57 -0000

We really must start to get layering in into our heads......the user-plane
*must* apply a well-known piece of characteristic information between the
source and sink of a trail.  These are the 'true' labels....the fact that
some control-plane sets them up is almost incidental.  The real arguments
starts as to the *nature* of that control-plane, but as I said that is
orthogonal to the fact that LSPs do create real hierarchies (in the
user-plane).

neil

> From:	Udo Neustadter [SMTP:[email-masked]]
> Sent:	Wednesday, December 06, 2000 5:03 PM
> To:	Peter Ashwood-Smith
> Cc:	mpls; ip-optical
> Subject:	RE: Re: GMPLS - Hierarchies
> 
> May understanding is that the hierarchy build is a logical one, and no
> real
> labels are added to the flow. The flow is identified by the specific TDM
> channels. I just can not see where the waste of bandwidth is coming from.
> 
> Udo
> 
> >...
> >
> >  This is most likely to occur with TDM and OXC equipement at the OC-192
> and OC-48 rates where there is a
> >close mapping between the OXC lambda and the TDM signal bandwidth. It
> won't
> work sell so well at lower rates
> >because you waste too much bandwidth and are forced into a heirarchy
> whether you want one or not.
> >
> >  Cheers,
> >
> >  Peter Ashwood-Smith
> >...

---

From: [email-masked]
Date: Wed, 6 Dec 2000 22:06:54 -0000

Spot on John.  Its called layering in functional architecture.  Each LSP
creates a layer network.  It has a source and a sink point at which certain
characteristic information (eg the shim header for MPLS, or some other
header if say ATM-based MPLS is being used (actually also the AAL)) is
applied and removed respectively.  The header is only relevant between these
points and *should* have no direct impact on other client or server layers
during normal operation (things are different under failures...I must get
that OAM ID out!)......if it does there is danger of layer violation causing
both backward and future cross-layer evolutionary problems, re my various
mail concerns on EXP, TTL and PHP issues that some will have seen wrt to the
shim header and the point of LSP trail termination and server->client
(layer) adaptation.

I really believe if more people had a better understanding of this (ie func
arch) then we could make better and more accurate progress.  Many of the
questions I see coming up are because what are to me/others basic functional
arch concepts are not understood or being applied.  Can I make a plea to
those who have access to G.805 to go and have a look at it and those that
don't check out the Book from Andy Reid (a close colleague of mine) and Mike
Sexton [Broadband Networking, Hardcover - 589 pages 1st edition (January 15,
1997) Artech House; ISBN: 0890065780].  This work was found essential to
unambiguously define SONET/SDH......not by operators, but by manufacturers
......and is in common usage today in many parts of our industry.  It is
also applicable to all other layer network technologies I can think of.

Neil

> nesting of LSPs of different LSR types is possible.
	<snipped>

---

From: [email-masked]
Date: Wed, 6 Dec 2000 22:06:56 -0000

<snipped>

> 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

---

From: [email-masked]
Date: Thu, 7 Dec 2000 11:18:04 -0000

Hi Marten......just one small observation to clarify what is really
meant by service interworking....see below:
	<snipped>
> - service interworking has been added (section 5.5/G.805 (03/00) in  
>   the form of a generic definition of "layer network interworking".
>   The importance here is that not only the traffic is forwarded, but 
>   also the associated trail overhead/OAM information. 
>   
	 NH=> I would have put this slightly differently........
	-	Payload is moved from layer X trail to (peer) layer Y trail
intact and transparently, ie the payload area must be the same size.
	-	Overhead functionality is *mapped* between the specific O/H
of the layer X trail and the layer Y trail.  This mapping may not be 100%
complete, since there could be functionality provided in the layer X trail
that is not present in the layer Y trail (or vice versa).  For example, in
ATM there is an AIS function but this does not exist in FR.  In FR there is
a BECN function, but this does not exist in ATM.  ATM uses LLC-SNAP client
(ie payload) encapsulation but FR uses NPLID. etc.

	neil

---

From: Heiles Juergen <[email-masked]>
Date: Thu, 7 Dec 2000 13:40:21 +0100

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

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, December 06, 2000 11:07 PM
> To:	[email-masked]; [email-masked]; [email-masked]

---

From: [email-masked]
Date: Thu, 7 Dec 2000 13:32:26 -0000

<snipped top/bottom>
>  So the question is indeed, is the functional architecture defined in
> G.805
> applicable to the MPLS/MPlambaS worlds?
>  How does this cope with G.cls (connectionless) work?
> 
Excellent question Nuno.  I and some colleagues have been discussing this in
BT for a while.  Indeed one of my colleagues has a Rapportuership for this
very issue in ITU SG13.  Only problem is finding the time to set it all down
for IP and MPLS.....but it really ought to be done at some point, and the
sooner the better.

I don't really want to open a debate up here on specific functional entities
(ie like the ones you suggested in your response), but I will flag this up
internally to my collegues and try to see if we can get some action going on
this.  I know there are lots of people tuned-in to this list who understand
the benefits of func arch descriptions and I am sure would like to see some
activity here.

Neil

---

From: [email-masked]
Date: Thu, 7 Dec 2000 13:32:23 -0000

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 

> From:	Heiles Juergen [SMTP:[email-masked]]
> Sent:	Thursday, December 07, 2000 12:40 PM
> To:	[email-masked]'; Heiles Juergen; [email-masked];
> [email-masked]
> 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
>

---

From: [email-masked]
Date: Thu, 7 Dec 2000 19:53:03 -0000

Hi Maarten...you asked me a question:

> For SDH/SONET and ATM one tandem connection level is defined. 
> For OTN, 6 levels of tandem connection are defined in G.709. 
> For MPLS, ... levels of tandem connection are proposed in the MPLS OAM
> activity (Neil can you provide the number here) in draft Y.17oam.1.
> 
	Before I answer the question wrt MPLS let me say this.....

	TCM is a very useful tool when one has fixed hierarchies.  For
example, ATM only has a VP and VC level (the VP being the server to the VC).
This means that if a customer is 'using' the VP (or VC) level (ie the VP/VC
trail starts/ends in a domain outside the operator providing the transit
connectivity), then there is no way for the operator to measure the
performance of a partition of the end-end external VP/VC trail.  So 2
sub-levels were introduced.....these were the VP-segment and VC-segment.
OAM flows can be instigated on these by the operator to provide the TCM
function.  There are rules for such segments (and indeed problems with ATM
OAM per se, that I know you too know only too well), but to discuss these
would be outside the scope of your question...which I now come back to.

	The reason I explained the above first, was to point out that in
MPLS (user-plane) there is no fixed hierarchy.  In theory it can be
infinite....though in practice this would make little sense.  This 'simple
wrapper' approach has some very attractive features.  And in the case of
TCM, it simply means that if one has an LSP going A->B->C->D->E-> etc but
the partition of interest (for a transit operator say) is just B->C->D, then
all the operator has to do is to set up a lower LSP between B and D to
monitor the flow, ie just add a new label in effect and create this new
layer/LSP trail.  This means there is, as far as I can see, no need to
introduce TCM into MPLS.....and recall I am talking here only about 'pure'
user-plane MPLS trails as defined by the shim header.  There is no shim
header in the Generalised MPLS case, since we have just whatever the
user-plane (that is being controlled) has defined here.
	Note - In the OAM work I am progressing I am putting performance
monitoring (ie QoS) as a 2nd order issue.  My main focus is
definition/detection/handling of defects, and in particular the
near-end/far-end state processing algorithms for measuring the availability
of LSPs....since in my view this is the key in-service metric we need (and
we need this anyway before QoS can be even considered, since this has only
relevance when the LSP is in the up-state).

	Regards, Neil

---

From: Heiles Juergen <[email-masked]>
Date: Fri, 8 Dec 2000 10:58:20 +0100

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

> Sent:	Thursday, December 07, 2000 2:32 PM
> is set-up as a separate issue.> 
> 
> neil 
>

---

From: [email-masked]
Date: Fri, 8 Dec 2000 16:10:21 -0000

Yangguang,

> If all of us are going to be at San Diego, we can arrange a discussion
> there and
> put our thoughts together. Sounds good?
> 
	NH=> Fine by me.

---

From: Heiles Juergen <[email-masked]>
Date: Thu, 14 Dec 2000 10:57:15 +0100

Hi Maarten

> From:	Maarten Vissers [SMTP:[email-masked]]
> Sent:	Monday, December 11, 2000 10:45 AM
> To:	[email-masked]; [email-masked]
> Subject:	Re: [IP-Optical] GMPLS - Hierarchies
> 
> Neil, Nuno,
> 
> I get the impression that a LSP is being used for both the trail and a
> tandem connection (subnetwork connection). But also as a tributary slot
> identifier. 
	[Heiles Juergen]  The label switched path (LSP) represents a connection/trail while the label itself represents a tributary slot identifier. You have to distinguish between the two.

	[Heiles Juergen]  One other point. In the transport network architecture we distinguish between network connection and trail. Basically the trail is the network connection + end-to-end supervision (e.g .connectivity, continuity). It is the question if the LSP includes this supervision or if it is just the connection. For example does the LSP automatically activate some kind of supervision in the transport plane at both end points during set-up?

	Jürgen

---

From: [email-masked]
Date: Tue, 19 Dec 2000 07:22:54 -0000

Hi Maarten,

Good to see you looking at this stuff at last....it certainly needs some
functional arch rigour which you can bring.  Your points:
<snip>

> tandem connection (subnetwork connection).
	NH=> You need to consider what is happening in the user-plane and at
which level.

	For the user-plane at the packet level then a shim-header is used to
provide additional OH functionality.....so this is part of the trail term
stuff as you point out later.  And despite some reluctance to accept the
fact, this shim-header is creating new layer networks......some call it
'L2.5', but this is not accurate since all layer networks are L3 (you only
need addressing/routing to meet L3 requirements) and what is really being
talked about here is the difference in transfer mode, ie CNLS vs CO, of the
particular layer network technology concerned.

	However, once one considers what you and I would call transport
layer networks (eg SDH, PDH, OTN) the shim-header disappears as far as the
user-plane is concerned (why?.....because its no longer pkt-based), and all
that is used in the user-plane is whatever framing OH is defined for the
particular network layer technology considered.  So here, there is *no* new
trail term functionality.......the only issue being 'what control-plane
facets should be used?', and the aim here is commonality across all layer
networks (the so-called GMPLS)....which is OK *providing* the control-plane
facets are fit for purpose (and I am not sure some are, eg 32 bit addressing
in the OTN (irrespective of format, which is something else that need
studying) looks unacceptably too small to me).

	So, in the pkt-case we do have new layer networks and there is *no*
TC (subnetwork) entity....one can just create new nested layer trails to any
hirearchical depth one wants (this is really a digital wrapper if you think
about it)......whilst in the trad CO transport layer case there are *no* new
layer networks.  These are very distinct and different cases.  I tried to
point this fact out some time ago on the MPLS list....maybe you missed
it?......but I am still not sure everyone has got a grip on it yet.

	 But also as a tributary slot identifier. 
> 	Note - Tributary slot identifiers in other technologies are: 
> 	VPI, VCI, time slot, frequency slot (wavelength).
> 
> A tributary slot identifier is bound to a "link connection". 
> A signal passing through from an incoming link connection (via a "matrix
> connection" in a fabric) to an outgoing link connection may see a
> tributary slot identifier change. E.g. VPI_in=124 => VPI_out=765,
> timeslot_in=1, timeslot_out = 18, lambda_in = 15 => lambda_out = 63, and
> label_in=5354 => label_out=678521.
> 
> TTP and CTP are terms defined in association with the information
> modelling. 
> *	A TTP in the information model is equivalent with a Trail
> Termination
> function (_TT) and the common part of the Adaptation function (_A) in
> the functional model. 
> *	A CTP in the information model is equivalent with the Connection
> Point
> at the Connection function (_C) and the client specific part of the
> Adaptation function (_A) in the functional model.
> 
> A link connection (LC) starts at a CTP and ends at the next CTP:
> 	Link Connection: CTP - server layer trail - CTP
> 
> A matrix connection (MC) starts at a TTP/CTP and ends at the TTP/CTP at
> the other end of the fabric (connection function):
> 	Matrix Connection: TTP/CTP - TTP/CTP
> 
> A matrix connection is the smallest subnetwork connection (SNC).
> A subnetwork connection is in general defined as:
> 	SNC: SNC - LC - SNC, with the smallest SNC being a MC.
> 
	NH=> Agreed.  If I can paraphrase the key issue you are describing
above in func arch terms ........this is the differnce between 'relative
addressing' which is only interface unique and can change on a link basis,
as opposed to 'absolute addressing' which *must* be globally unique (at
least for the network access point population considered) and can only
change on a trail basis. [though there are subtle differences between the
'identifiers' used at a TTP and an access point which I don't want to get
into here]

> >  TTPs - are the IP interfaces/ports?
> 
> TTPs are the LSP termination points, where bits 20-31 of the MPLS label
> are added/removed and the information in the payload of this MPLS packet
> extracted.
	NH=> Only for the pkt layer technology cases is this true.  It does
not apply for trad transport networks, and the TTP here is detremined by the
framing OH used in whatever layer technology is considered.

> >  CTPs- are the labels?
> 
> CTPs are the boundaries of the link connection. The 20-bit label value
> is added/removed here. A link connection starts/ends at each LSR and
> LER.
> 
> Associated with a CTP may be a tandem connection TTP. Such tandem
> connection TTP adds another 32-bit MPLS label and associated MPLS OAM
> packet flow.
	NH=> This is where we disagree.....but I am open to arguments to
pursuade me otherwise.  I see each pkt-based LSP as a layer network in its
own right with *no* fixed hierachies.  CF ATM which has 2 clear hierachies,
ie VP and VC.  One cannot keep 'wrapping' labels in ATM (due to fixed VP/VC
structure) but one can keep wrapping labels in true MPLS.  These are quite
different cases and MPLS (user-plane at pkt-level) is quite unique in this
respect.  So I don't see there is a case for TC per LSP....one simply
creates a lower layer LSP (ie true server trail) over the subnetwork region
of the higher LSP one wants to look at.  I like this feature very much.

> >  LCs - are the connections/associations between 2 labels in two
> >  different LSRs?
> 
> A LC is the connection between the egress of one LSR [or LER] and the
> ingress of the next LSR [or LER].
	NH=> Agreed *but* only for a given LSP level where no LSP nesting is
considered, ie within a single layer network.

> >  SNCs- are the forwarding tables in the LSRs and LERs? (a connection
> >  between the TTP and CTP in the LER, or a connection between CTPs in
> >  the LSRs)?
> 
> The set of MCs (matrix connections) are the forwarding tables in the
> LSRs and LERs.
	NH=> Seems true.

---

From: [email-masked]
Date: Tue, 19 Dec 2000 07:22:55 -0000

Maarten....hope my last mail helped on this....some additional comment
in-line:
	<snipped>

> Up to now, tandem connection trails are viewed as being additional
> monitoring overhead/OAM within the same layer network as the main
> signal.
> 
> 	E.g. VC-4 and VC-4 Tandem Connection (TC-4), ATM VP end to end
> 	connection and ATM VP segment, or ODU1 Path and ODU1 Tandem
> 	Connection.
	NH=> Correct.

> But within GMPLS with its "generic LSP" concept, we could view a VT1.5
> as being a tandem connection LSP of the DS1 LSP for connection setup.
> Similarly, we could view MS64, RS64, ODU2, OTU2 and OCh as tandem
> connection LSPs of the VC-4-64c LSP for connection setup.
	NH=> No.  Differentiate user and control planes.  See my last mail I
tried really hard to make this distinction clear.

> I believe that we are already doing something like this in SDH; e.g. the
> set up of a E1 (2 Mbit/s) circuit is realised by means of setup of a
> VC-12 trail.
	NH=> No. The E1 and VC12 are 2 distinct layer networks and both have
their own TT OH.
	<snipped>