The MPLS WG Archive

[neil.2.harrison@bt.com]

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