1. MPLS-TP INTER-OP: WHAT, WHY, AND HOW? General Objectives for MPLS-TP Inter-Op Test Program at UNH-IOL

2. 2 MPLS-TP - WHAT? L2 transport network profile of MPLS that is independent of any (L3) client protocols such as IP -- http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-08 http://tools.ietf.org/html/draft-ietf-mpls-tp-requirements-08 * : 1. Introduction “it MUST be possible for operators to be able to completely operate (including OAM and protection capabilities) an MPLS-TP network in the absence of any control plane protocols for dynamic configuration.” 1.2. Transport network overview “An important attribute of a transport network is that it is able to function regardless of which clients are using its connection service or over which transmission media it is running.” 2.1. General requirements [selected] 15 MPLS-TP MUST support the logical separation of the control and management planes from the data plane. 17 MPLS-TP MUST support static provisioning of transport paths via the management plane. 19 Static provisioning MUST NOT depend on the presence of any element of a control plane. 20 MPLS-TP MUST support the capability for network operation (including OAM and recovery) via the management plane (without the use of any control plane protocols). 2.4. Control plane requirements [selection] 47 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. i.e. the data plane only operates on the MPLS label. *This ID defines functionality of MPLS-TP ‘building blocks’; individual implementations may support various subsets of that standard toolkit. To get actually started on L2 MPLS-TP inter-op, our initial focus is on the simplified, L3-independent operation of MPLS-TP; hence the above selections from the ID.

3. 3 MPLS-TP - WHY? http://en.wikipedia.org/wiki/MPLS-TP (emphasis added):http://en.wikipedia.org/wiki/MPLS-TP “MPLS-TP is expected to be a low cost L2 technology (if the limited profile to be specified is implemented in isolation) that will provide QoS, end-to-end OA&M and protection switching.” Key objective of MPLS-TP inter-op charter: –Define multi-vendor Implementation Agreements (IAs) via appropriate standard committees, to enable inter-operable products and services for this much needed, cost-efficient, simplified (yet extensible where needed), high-quality L2 transport technology. –Demonstrate full network scale inter-operability per the IAs in practical, multi-vendor deployment scenarios, to facilitate faster market adoption, and to deliver the cost-efficiency gains to the service providers and the end-customers.

4. 4 MPLS-TP - HOW? 1)Data plane inter-op mechanics, independent of any client (L3) protocols: oCurrently, MPLS protocol testers can be provisioned for statically assigned labels oIP-MPLS LERs to support initially IP/MPLS over MPLS-TP similar to e.g. IP over FR  IP-MPLS LERs to be interconnected over non-IP-aware MPLS-TP core 2)Implementation Agreements for automated MPLS-TP Labeling oTo avoid need for manual Label assignment oFor L2 MPLS-TP layer networks (isolated from other L2 networks by the L3 nodes they interconnect), a pre-defined Label pattern can be standardized, knowing which the L3 nodes can query L3 addresses from their L3 peers on same MPLS-TP network, automating L3 next hop (e.g. IP) to L2 address (MPLS-TP Label) bindings - E.g. geometrical, stackable forwarding enable vector based MPLS-TP Label pattern option to support broad/multicast as general case with uni-cast as trivial special case (just one bit set) - Note that packet forwarding decisions in all cases need to be resolved down to 1:N demuxing keys, so by formatting the L2 forwarding labels directly as such forwarding enable vectors only eliminates the non-value-adding intermediate lookups, and even the need for any route/switching tables at MPLS-TP networks supporting this standard library labeling option  Unlimited scalability with elimination of outlying complex special cases, enabling low-cost, high-reliability hardware automation, while maintaining all necessary flexibility at L3 3)Remainder of MPLS-TP requirements, as needed for practical deployments  The extensible internetworking testbed independent of current IP routing protocol implementations can provide effective Future Internet development platform

5. 5 Interested? Contacts: Thomas Peterson (603)862-2804 thomasp@iol.unh.edu UNH-IOL