A Framework for Point-to-Multipoint MPLS in Transport Networks
draft-ietf-mpls-tp-p2mp-framework-05

Abstract

The Multiprotocol Label Switching Transport Profile 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.

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://datatracker.ietf.org/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 May 22, 2014.

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://trustee.ietf.org/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
• 1.1. Scope
• 1.2. Terminology
• 1.2.1. Additional Definitions and Terminology
• 1.3. Applicability
• 2. MPLS Transport Profile Point-to-Multipoint Requirements
• 3. Architecture
• 3.1. MPLS-TP Encapsulation and Forwarding
• 4. Operations, Administration and Maintenance
• 5. Control Plane
• 5.1. Point-to-Multipoint LSP Control Plane
• 5.2. Point-to-Multipoint PW Control Plane
• 6. Survivability
• 7. Network Management
• 8. Security Considerations
• 9. IANA Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

The Multiprotocol Label Switching Transport Profile 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.

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

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. P2MP MPLS TE-LSP support is discussed in [RFC4875] and [RFC5332], and P2MP 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 point-to-multipoint [G.798] and drop-and-continue [G.780], and thus supports the same class of traditional applications, e.g., video distribution.

There is no definition for MPLS TE-LSP support of multipoint-to-multipoint connectivity and none is anticipated.

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. This summary does not include the [RFC2119] conformance language used in original documents as this document is not authoritative.

From [RFC5654]:

• MPLS-TP must support traffic-engineered point-to-multipoint transport paths.
• MPLS-TP must support unidirectional point-to-multipoint transport paths.
• MPLS-TP must be capable of using P2MP server (sub)layer capabilities as well as P2P server (sub)layer capabilities when supporting P2MP MPLS-TP transport paths.
• The MPLS-TP control plane must support establishing all the connectivity patterns defined for the MPLS-TP data plane (i.e., unidirectional P2P, associated bidirectional P2P, co-routed bidirectional P2P, unidirectional P2MP) including configuration of protection functions and any associated maintenance functions.
• Recovery techniques used for P2P and P2MP should be identical to simplify implementation and operation.
• Unidirectional 1+1 and 1:n protection for P2MP connectivity must be supported.
• MPLS-TP recovery in a ring must protect unidirectional P2MP transport paths.

From [RFC5860]:

• The protocol solution(s) developed to perform the following OAM functions must also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs:
  • Continuity Check
  • Connectivity Verification, proactive
  • Lock Instruct
  • Lock Reporting
  • Alarm Reporting
  • Client Failure Indication
  • Packet Loss Measurement
  • Packet Delay Measurement
• The protocol solution(s) developed to perform the following OAM functions may also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs:
  • Connectivity Verification, on-demand
  • Route Tracing
  • Diagnostic Tests
  • Remote Defect Indication

From [RFC5951]:

• For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is required.
• For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is required.

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:

• Unidirectional point-to-multipoint LSPs
• Unidirectional point-to-multipoint PWs
• Optional point-to-multipoint LSP and PW control planes
• Survivability, network management, and Operations, Administration and Maintenance functions for point-to-multipoint PWs and LSPs

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 CE 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 has been discussed within the PWE3 Working Group [I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for further study.

4. Operations, Administration and Maintenance

The requirements for MPLS-TP OAM are specified in [RFC5860]. 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 towards all the leaves, and thus may be processed by all the MIPs and MEPs associated with a P2MP MEG. If an OAM packet is to be processed by only a specific 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 additional information in the OAM payload is used to identify the specific destination. It is worth noting that a MIP and MEP may be instantiated on a single node when it is both a branch and leaf 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].

A more detailed discussion of P2MP OAM considerations can be found in [I-D.hmk-mpls-tp-p2mp-oam-framework].

5. Control Plane

The framework for the MPLS-TP control plane is provided in [RFC6373]. This document reviews MPLS-TP control plane requirements 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:

• requirement 6 (P2MP transport paths),
• requirement 34 (use P2P sub-layers),
• requirement 49 (common recovery solutions for P2P and P2MP),
• requirement 59 (1+1 protection),
• requirement 62 (1:n protection),
• and requirement 65 (1:n shared mesh recovery).

[RFC6373] defines the control plane approach used to support MPLS-TP transport paths. It identifies GMPLS as the control plane for MPLS-TP LSPs tLDP as the control plane for 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 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 should be based on the LDP control protocol used for point-to-point PWs [RFC4447], with updates as required for P2MP applications. A detailed specification of the control plane for P2MP PWs is for further study.

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. For 1+1, 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. For 1:1, the source/root MPLS-TP node needs to identify the existence of a fault condition impacting delivery to any of the leaves. Fault notification happens from the node identifying the fault to the root node via an out of band path. 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, particularly if a requirement emerges to provide survivability for P2MP PWs in an MPLS-TP context.

7. Network Management

An overview of network management considerations for MPLS-TP can be found in Section 3.14 of "Framework for MPLS in Transport Networks" [RFC5921]. The provided description applies equally to P2MP transport paths.

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. [RFC5951] covers all MPLS-TP connection types, including P2MP.

[RFC6639] provides the MIB-based architecture for MPLS-TP. It reviews the interrelationships between different non MPLS-TP specific MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. While the document does not consider P2MP transport paths, it does provide a foundation for an analysis of areas where MIB module modification and addition may be needed to fully support P2MP transport paths. There has also been work in the MPLS working group on a P2MP specific MIB, [I-D.ietf-mpls-p2mp-te-mib].

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

There are no requests for IANA actions in this document.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses