Re: [mpls-tp] MPLS-TP LSP questions

[<[e-mail]>]

S Velan asked:
01 March 2011 06:49
To: [e-mail]
Subject: [mpls-tp] MPLS-TP LSP questions

Hi Experts,

I quickly wanted to check with you all,

Can both,  MPLS-TP LSP and traditional MPLS LSP, exist in a LSR?  If both can exist, there is possibility of merging of these LSPs at a LSR.  How can we detect such merging LSPs?

Thanks in advance.
S.Velan

NH=> This is an important question....but it's much larger than you may have realised.  Consider the following:

You also need to ask yourself if you are dealing with a single layer network (traditional MPLS contains sublayers that are supposed to belong to the same layer network, though these do not have consistent Characteristic Information (CI) and this is a problem..see later), or a proper client/server situation, ie functionally isolated MPLS layer networks that may belong to different parties.

In the former case there is a tacit assumption that there is a common CP instance...well, at least a common routing instance (though MS PWs wreck this myth, and so will a need to isolate the resources controlled by MPLS LDP say from those controlled by MPLS-TP - see later), because the signalling aspects (ie protocols that issue labels for LSP set-up) can vary.

It should be obvious why this is an important question because one can have misconnectivity between LSPs belonging to the same layer network (including nested sublayer case) and misconnectivity between LSPs belonging to different layer networks.

The co-ps network mode based on label-swapping has the most rich set of misconnectivity defects possible compared to the cl-ps mode (eg IP, Ethernet), the co-cs mode (eg SDH VC4, PDH T1) or the co-ps mode based on no label-swapping (eg PBB-TE).

Misconnectivity defects don't just impact SLAs, but they give rise to security issues, ie the unintended replication of one customer's traffic and its mismerging into the LSP of some other customer's traffic.  Aside=> An interesting aspect here is miconnectivity that occurs in a server layer that a client layer has no control over but suffers the consequences of...this is a new case caused by same technology co-ps mode layering.

A label-swapping environment like MPLS can allow this to happen and so one needs *comprehensive and consistent OAM across *all* layer networks to detect this*.  Note the highlighted words (esp 'all') carefully.

When traffic is misdirected (for whatever reason) one would assume/expect the trail termination point (ie LSP sink point(s)) where it eventually arrives at to be able to correctly parse/interpret the traffic unit.  This requires 2 things (i) consistent traffic unit structure and (ii) consistent functional meaning of traffic unit fields.

Due to the sparse functional structure of the MPLS traffic unit and, more generally, the short-cuts that can be taken on the functional labelling of a traffic unit when dealing with the co-ps mode due to an assumption of a single source connection (though the LDP form of MPLS and PHP immediately wreck this last point), there is not consistent CI in the MPLS traffic unit....the 20 bit label field has to assume all manner of functions, eg the PW label for example must take on the role of source address (SA) proxy to recover from lower level LDP (or PHP) merging that loses source information.

Thus, when a MPLS traffic unit arrives at some trail termination point, the functional semantic meaning of the label field may not be correctly interpreted and the wrong actions taken.  And as noted above this is not simply in a single MPLS layer network of traditional stacked LSPs (==sublayers) but also in future proper client/server nested hierarchies of LSPs belonging to different MPLS layer networks.

You should not only consider the OAM aspects of running different types of MPLS layer network in the same box but also their resource management.  Distributed routing protocols can't deal with distributing real-time traffic load  (they become unstable).  But in any transport network worthy of the name resource management is of primary importance.  Further, since transport networks are about the topology creation of client layer networks (ie layer N client link connection (==hop) is provided by an E2E path layer N-1 server layer network connection) they (i) have long-holding connections (essential for client layer topology stability) and don't require highly dynamic resource management (hint => centralised route calculation and resource management is much better than distributed route calculation and resource management in transport networks) and (ii) MUST provide a *transparent* transport service to their clients.....and on the last point this means each/every bit (the atomic Shannon information unit) MUST be treated equally wrt importance.  Aside=> So if someone tries to sell you the notion of lots of QoS classes in a transport network (or worse, DPI) you know they don't understand this topic very well....

This last point effectively means that we would need to logically separate the resources used by an MPLS LDP layer network and a MPLS-TP layer network when they appear in the same physical box.  This is yet another nail in the common CP coffin.


So, to summarise, what I am saying here is that one wants comprehensive and consistent OAM across all layer networks and that each layer network needs to operate in its own functionally isolated resource partition.  However, this still leaves the question as to *how* does one ensure comprehensive and consistent OAM across all MPLS layer networks when nested in a client/server manner such that one can unambiguously detect/identify a source of misconnectivity, especially when one may not own all the layer networks to the duct?

Not sure if that helps.  But it should give you some additional things to consider here.

regards, Neil

Neil Harrison
BT Design

Tel: [phone]
Email: [e-mail]<mailto:[e-mail]>
Web: www.bt.com<http://www.bt.com/>
This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000