1 / 5

MPLS-TP INTER-OP: WHAT, WHY, AND HOW?

MPLS-TP INTER-OP: WHAT, WHY, AND HOW?. General Objectives for MPLS-TP Inter-Op Test Program at UNH-IOL. 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 * :

zinnia
Download Presentation

MPLS-TP INTER-OP: WHAT, WHY, AND HOW?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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*: 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. MPLS-TP - WHY? • http://en.wikipedia.org/wiki/MPLS-TP (emphasis added): “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. MPLS-TP - HOW? • Data plane inter-op mechanics, independent of any client (L3) protocols: • Currently, MPLS protocol testers can be provisioned for statically assigned labels • IP-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 • Implementation Agreements for automated MPLS-TP Labeling • To avoid need for manual Label assignment • For 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 • 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. Interested? Contacts: Thomas Peterson (603)862-2804 thomasp@iol.unh.edu UNH-IOL

More Related