MPLS Working Group D. Frost, Ed.
Internet-Draft S. Bryant, Ed.
Intended status: Informational Cisco Systems
Expires: July 07, 2013 M. Bocci, Ed.
L. Berger, Ed.
LabN Consulting
January 03, 2013

A Framework for Point-to-Multipoint MPLS in Transport Networks


The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to-multipoint transport paths.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 07, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to meet the requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] provides an overall introduction to the MPLS-TP and defines the general architecture of the Transport Profile, as well as those aspects specific to point-to-point transport paths. The purpose of this document is to define the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to-multipoint transport paths.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.

1.1. Scope

This document defines the elements and functions of the MPLS-TP architecture related to supporting point-to-multipoint transport paths. The reader is referred to [RFC5921] for those aspects of the MPLS-TP architecture that are generic, or concerned specifically with point-to-point transport paths.

1.2. Terminology

Term Definition
LSP Label Switched Path
MPLS-TP MPLS Transport Profile
SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode
OTN Optical Transport Network
OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel
GAL G-ACh Label
MEP Maintenance End Point
MIP Maintenance Intermediate Point
APS Automatic Protection Switching
SCC Signaling Communication Channel
MCC Management Communication Channel
EMF Equipment Management Function
FM Fault Management
CM Configuration Management
PM Performance Monitoring
LSR Label Switching Router
MPLS-TE MPLS Traffic Engineering
P2MP Point-to-multipoint
PW Pseudowire

1.2.1. Additional Definitions and Terminology

Detailed definitions and additional terminology may be found in [RFC5921] and [RFC5654].

1.3. Applicability

The point-to-multipoint connectivity provided by an MPLS-TP network is based on the point-to-multipoint connectivity provided by MPLS networks. MPLS TE-LSP support is discussed in [RFC4875] and [RFC5332], and PW support is being developed based on [I-D.ietf-pwe3-p2mp-pw-requirements] and [I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to-multipoint connectivity is analogous to that provided by traditional transport technologies such as Optical Transport Network (OTN) point-to-multipoint [ref?] and optical drop-and-continue [ref?], and thus supports the same class of traditional applications.

2. MPLS Transport Profile Point-to-Multipoint Requirements

The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], and [RFC5951]. This section provides a brief summary of point-to-multipoint transport requirements as set out in those documents; the reader is referred to the documents themselves for the definitive and complete list of requirements.

3. Architecture

The overall architecture of the MPLS Transport Profile is defined in [RFC5921]. The architecture for point-to-multipoint MPLS-TP comprises the following additional elements and functions:

The following subsections summarise the encapsulation and forwarding of point-to-multipoint traffic within an MPLS-TP network, and the encapsulation options for delivery of traffic to and from MPLS-TP Customer Edge devices when the network is providing a packet transport service.

3.1. MPLS-TP Encapsulation and Forwarding

Packet encapsulation and forwarding for MPLS-TP point-to-multipoint LSPs is identical to that for MPLS-TE point-to-multipoint LSPs. MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the related data-plane behaviour was further clarified in [RFC5332]. MPLS-TP allows for both upstream-assigned and downstream-assigned labels for use with point-to-multipoint LSPs.

Packet encapsulation and forwarding for point-to-multipoint PWs is currently being defined by the PWE3 Working Group [I-D.raggarwa-pwe3-p2mp-pw-encaps].

4. Operations, Administration and Maintenance (OAM)

The overall OAM architecture for MPLS-TP is defined in [RFC6371], and P2MP OAM design considerations are described in Section 3.7 of that RFC.

All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves, thus every OAM packet is sent to all leaves, and thus can simultaneously instrument all the MEs in a P2MP MEG. If an OAM packet is to be processed by only one leaf, it requires information to indicate to all other leaves that the packet must be discarded. To address a packet to an intermediate node in the tree, TTL based addressing is used to set the radius and addressing information in the OAM payload is used to identify the specific destination node.

P2MP paths are unidirectional; therefore, any return path to an originating MEP for on-demand transactions will be out-of-band. Out of band return paths are discussed in Section 3.8 of [RFC5921].

Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already considers the P2MP case and it is not thought that any change is needed to the MPLS-TP profile of [RFC6374] [RFC6375].

[Editor's note: Additional information / text has been published in [I-D.hmk-mpls-tp-p2mp-oam-framework]. The Editors will coordinate with the draft authors to identify which text should be folded into this document and which should remain in a standalone document.]

5. Control Plane

The framework for the MPLS-TP control plane is provided in [RFC6373]. This document reviews MPLS-TP control plane requirments as well as provides details on how the MPLS-TP control plane satisfies these requirements. Most of the requirements identified in [RFC6373] apply equally to P2P and P2MP transport paths. The key P2MP specific control plane requirements are identified in requirement 6 (P2MP transport paths), 34 (use P2P sub-layers), 49 (common recovery solutions for P2P and P2MP), 59 (1+1 protection), 62 (1:n protection), and 65 (1:n shared mesh recovery).

[RFC6373] defines the control plane approach used to support MPLS-TP transport paths. It identifies Generalized MPLS (GMPLS) as the control plane for MPLS-TP Label Switched Paths (LSPs) and Targeted LDP (T-LDP) as the control plane for pseudowires (PWs). MPLS-TP allows that either, or both, LSPs and PWs to be provisioned statically or via a control plane. As noted in [RFC6373]:

The PW and LSP control planes, collectively, must satisfy the MPLS-TP control-plane requirements. As with P2P services, when P2MP client services are provided directly via LSPs, all requirements must be satisfied by the LSP control plane. When client services are provided via PWs, the PW and LSP control planes can operate in combination, and some functions may be satisfied via the PW control plane while others are provided to PWs by the LSP control plane. This is particularly noteworthy for P2MP recovery.

5.1. Point-to-Multipoint LSP Control Plane

The MPLS-TP control plane for point-to-multipoint LSPs uses GMPLS and is based on Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for point-to-multipoint LSPs as defined in [RFC4875]. A detailed listing of how GMPLS satisfies MPLS-TP control plane requirements is provided in [RFC6373].

Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, should be documented. Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3.

5.2. Point-to-Multipoint PW Control Plane

The MPLS-TP control plane for point-to-multipoint PWs uses the LDP P2MP signaling extensions for PWs defined in [I-D.ietf-pwe3-p2mp-pw]. This definition is limited to single segment PWs and is based on LDP [RFC5036] with upstream-assigned labels [RFC5331]. The document does not address recovery of P2MP PWs. Such recovery can be provided via P2MP LSP recovery as generally discussed in [RFC6372]. Alternatively, PW recovery [RFC6718] can be extended to explicitly support recovery of P2MP PWs.

6. Survivability

The overall survivability architecture for MPLS-TP is defined in [RFC6372], and section 4.7.3 in particular describes the application of linear protection to unidirectional P2MP entities using 1+1 and 1:1 protection architecture. The approach is for the root of the P2MP tree to bridge the user traffic to both the working and protection entities. Each sink/leaf MPLS-TP node selects the traffic from one entity according to some predetermined criteria. Fault notification happens from the node idenifying the fault to the root node and from the leaves to the root via an out of band path. In either case the root then selects the protection transport path for traffic transfer. More sophisticated survivability approaches such as partial tree protection and 1:n protection are for further study.

The IETF has no experience with P2MP PW survivability as yet, and therefore it is proposed that the P2MP PW survivability will initially rely on the LSP survivability. Further work is needed on this subject, partiularly if a requiremnet emerges to provide survivability for P2MP PWs in an MPLS-TP context.

7. Network Management

The network management architecture and requirements for MPLS-TP are specified in [RFC5951]. They derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. They also incorporate the OAM requirements for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those requirements to cover the modifications necessary for fault, configuration, performance, and security in a transport network.

[Editor's note: Decide what if anything needs to be said about P2MP-specific network management considerations.]

Section 3.14 of " Framework for MPLS in Transport Networks" [RFC5921] describe the aspects of network management in the P2P MPLS-TP case. This apply to the P2MP case.

8. Security Considerations

General security considerations for MPLS-TP are covered in [RFC5921]. Additional security considerations for point-to-multipoint LSPs are provided in [RFC4875]. This document introduces no new security considerations beyond those covered in those documents.

9. IANA Considerations

IANA considerations resulting from specific elements of MPLS-TP functionality are detailed in the documents specifying that functionality. This document introduces no additional IANA considerations in itself.

10. References

10.1. Normative References

[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N. and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L. and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC4875] Aggarwal, R., Papadimitriou, D. and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4872] Lang, J.P., Rekhter, Y. and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R. and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5331] Aggarwal, R., Rekhter, Y. and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.

10.2. Informative References

, "
[RFC5860] Vigoureux, M., Ward, D. and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N. and E. Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, September 2011.
[RFC5951] Lam, K., Mansfield, S. and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[I-D.ietf-pwe3-p2mp-pw] Sivabalan, S, Boutros, S and L Martini, "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Internet-Draft draft-ietf-pwe3-p2mp-pw-04, March 2012.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y, JOUNAY, F, Niven-Jenkins, B, Brungard, D and L Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Internet-Draft draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012.
[I-D.ietf-pwe3-p2mp-pw-requirements] Bocci, M, Heron, G and Y Kamite, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs", Internet-Draft draft-ietf-pwe3-p2mp-pw-requirements-05, September 2011.
[I-D.raggarwa-pwe3-p2mp-pw-encaps] Aggarwal, R and F JOUNAY, "Point-to-Multipoint Pseudo-Wire Encapsulation", Internet-Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01, March 2010.
[RFC6718] Muley, P., Aissaoui, M. and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D. and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[I-D.hmk-mpls-tp-p2mp-oam-framework] Koike, Y, Hamano, T and M Namiki, "A framework for Point-to-Multipoint MPLS-TP OAM", Internet-Draft draft-hmk-mpls-tp-p2mp-oam-framework-01, November 2012.
[G.7710]ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment management function requirements"", 2005.

Authors' Addresses

Dan Frost (editor) Cisco Systems EMail:
Stewart Bryant (editor) Cisco Systems EMail:
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom EMail:
Lou Berger (editor) LabN Consulting Phone: +1-301-468-9228 EMail: