path: root/doc/rfc/rfc7167.txt

Internet Engineering Task Force (IETF)                          D. Frost
Request for Comments: 7167                                      Blue Sun
Category: Informational                                        S. Bryant
ISSN: 2070-1721                                            Cisco Systems
                                                                M. Bocci
                                                          Alcatel-Lucent
                                                               L. Berger
                                                         LabN Consulting
                                                              April 2014


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

Abstract

   The Multiprotocol Label Switching 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 that are applicable specifically to supporting point-to-
   multipoint transport paths.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7167.













Frost, et al.                 Informational                     [Page 1]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  MPLS-TP P2MP Requirements . . . . . . . . . . . . . . . . . .   4
   4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  MPLS-TP Encapsulation and Forwarding  . . . . . . . . . .   6
   5.  Operations, Administration, and Maintenance . . . . . . . . .   6
   6.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  P2MP LSP Control Plane  . . . . . . . . . . . . . . . . .   8
     6.2.  P2MP PW Control Plane . . . . . . . . . . . . . . . . . .   8
   7.  Survivability . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Network Management  . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10

















Frost, et al.                 Informational                     [Page 2]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


1.  Introduction

   The Multiprotocol Label Switching 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 the 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 the aspects of the
   MPLS-TP architecture that are generic or are concerned specifically
   with point-to-point transport paths.

1.2.  Terminology

   Term    Definition
   ------- ---------------------------------------------------
   CE      Customer Edge
   LSP     Label Switched Path
   LSR     Label Switching Router
   MEG     Maintenance Entity Group
   MEP     Maintenance Entity Group End Point
   MIP     Maintenance Entity Group Intermediate Point
   MPLS-TE MPLS Traffic Engineering
   MPLS-TP MPLS Transport Profile
   OAM     Operations, Administration, and Maintenance
   OTN     Optical Transport Network
   P2MP    Point-to-multipoint
   PW      Pseudowire
   RSVP-TE Resource Reservation Protocol - Traffic Engineering
   SDH     Synchronous Digital Hierarchy
   tLDP    Targeted LDP

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









Frost, et al.                 Informational                     [Page 3]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


2.  Applicability

   The point-to-multipoint connectivity provided by an MPLS-TP network
   is based on the point-to-multipoint connectivity provided by MPLS
   networks.  Traffic Engineered P2MP LSP support is discussed in
   [RFC4875] and [RFC5332], and P2MP PW support is being developed based
   on [P2MP-PW-REQS] and [VPMS-FRMWK-REQS].  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.

   The scope of this document is limited to point-to-multipoint
   functions and it does not discuss multipoint-to-multipoint support.

3.  MPLS-TP P2MP 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 RFC
   2119 [BCP14] conformance language used in the original documents as
   this document is not authoritative.

   From [RFC5654]:

   o  MPLS-TP must support traffic-engineered point-to-multipoint
      transport paths.

   o  MPLS-TP must support unidirectional point-to-multipoint transport
      paths.

   o  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.

   o  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.

   o  Recovery techniques used for P2P and P2MP should be identical to
      simplify implementation and operation.

   o  Unidirectional 1+1 and 1:n protection for P2MP connectivity must
      be supported.



Frost, et al.                 Informational                     [Page 4]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


   o  MPLS-TP recovery in a ring must protect unidirectional P2MP
      transport paths.

   From [RFC5860]:

   o  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

   o  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]:

   o  For unidirectional (P2P and point-to-multipoint (P2MP))
      connection, proactive measurement of packet loss and loss ratio is
      required.

   o  For a unidirectional (P2P and P2MP) connection, on-demand
      measurement of delay measurement is required.




Frost, et al.                 Informational                     [Page 5]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


4.  Architecture

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

   o  Unidirectional point-to-multipoint LSPs

   o  Unidirectional point-to-multipoint PWs

   o  Optional point-to-multipoint LSP and PW control planes

   o  Survivability, network management, and Operations, Administration,
      and Maintenance functions for point-to-multipoint PWs and LSPs.

   The following subsection summarises 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.

4.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 [P2MP-PW-ENCAPS], but
   such definition is for further study.

5.  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, Time-to-Live-based addressing is
   used to set the radius and additional information in the OAM payload



Frost, et al.                 Informational                     [Page 6]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


   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
   [MPLS-TP-P2MP-OAM].

6.  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:

   o  requirement 6 (P2MP transport paths),

   o  requirement 34 (use P2P sub-layers),

   o  requirement 49 (common recovery solutions for P2P and P2MP),

   o  requirement 59 (1+1 protection),

   o  requirement 62 (1:n protection), and

   o  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 and 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.  Quoting from [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.




Frost, et al.                 Informational                     [Page 7]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


6.1.  P2MP LSP Control Plane

   The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on
   RSVP-TE for P2MP LSPs as defined in [RFC4875].  A detailed listing of
   how GMPLS satisfies MPLS-TP control-plane requirements is provided in
   [RFC6373].

   [RFC6373] notes that recovery techniques for traffic engineered P2MP
   LSPs are not formally defined, and that such a definition is needed.
   A formal definition will be based on existing RFCs and may not
   require any new protocol mechanisms but, nonetheless, should be
   documented.  GMPLS recovery is defined in [RFC4872] and [RFC4873].
   Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3.

6.2.  P2MP PW Control Plane

   The MPLS-TP control plane for P2MP 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.

7.  Survivability

   The overall survivability architecture for MPLS-TP is defined in
   [RFC6372], and Section 4.7.3 of that RFC 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;
   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.








Frost, et al.                 Informational                     [Page 8]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


8.  Network Management

   An overview of network management considerations for MPLS-TP can be
   found in Section 3.14 of [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 MIB modules that are
   not MPLS-TP specific and 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, [MPLS-TE-P2MP-MIB].

9.  Security Considerations

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

10.  References

10.1.  Normative References

   [RFC4872]  Lang, J., 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.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, May 2007.

   [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.



Frost, et al.                 Informational                     [Page 9]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


   [RFC5332]  Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
              Multicast Encapsulations", RFC 5332, August 2008.

   [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.

10.2.  Informative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [G.7710]   ITU-T, "Common equipment management function
              requirements", ITU-T G.7710/Y.1701, July 2007.

   [G.780]    ITU-T, "Terms and definitions for synchronous digital
              hierarchy (SDH) networks", ITU-T G.780/Y.1351, July 2010.

   [G.798]    ITU-T, "Characteristics of optical transport network
              hierarchy equipment functional blocks", ITU-T G.798,
              December 2012.

   [MPLS-TE-P2MP-MIB]
              Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to-
              Multipoint Multiprotocol Label Switching (MPLS) Traffic
              Engineering (TE) Management Information Base (MIB)
              module", Work in Progress, April 2009.

   [MPLS-TP-P2MP-OAM]
              Arai, K., Koike, Y., Hamano, T., and M. Namiki, "Framework
              for Point-to-Multipoint MPLS-TP OAM", Work in Progress,
              January 2014.

   [P2MP-PW-ENCAPS]
              Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-
              Wire Encapsulation", Work in Progress, March 2010.

   [P2MP-PW-REQS]
              Jounay, F., Kamite, Y., Heron, G., and M. Bocci,
              "Requirements and Framework for Point-to-Multipoint
              Pseudowires over MPLS PSNs", Work in Progress, February
              2014.





Frost, et al.                 Informational                    [Page 10]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


   [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.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              Operations, Administration, and Maintenance (OAM) in MPLS
              Transport Networks", RFC 5860, May 2010.

   [RFC5951]  Lam, K., Mansfield, S., and E. Gray, "Network Management
              Requirements for MPLS-based Transport Networks", RFC 5951,
              September 2010.

   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.

   [RFC6372]  Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
              TP) Survivability Framework", RFC 6372, 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.

   [RFC6639]  King, D. and M. Venkatesan, "Multiprotocol Label Switching
              Transport Profile (MPLS-TP) MIB-Based Management
              Overview", RFC 6639, June 2012.

   [VPMS-FRMWK-REQS]
              Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
              and L. Jin, "Framework and Requirements for Virtual
              Private Multicast Service (VPMS)", Work in Progress,
              October 2012.














Frost, et al.                 Informational                    [Page 11]
^L
RFC 7167          MPLS Transport Profile P2MP Framework       April 2014


Authors' Addresses

   Dan Frost
   Blue Sun

   EMail: frost@mm.st


   Stewart Bryant
   Cisco Systems

   EMail: stbryant@cisco.com


   Matthew Bocci
   Alcatel-Lucent
   Voyager Place, Shoppenhangers Road
   Maidenhead, Berks  SL6 2PJ
   United Kingdom

   EMail: matthew.bocci@alcatel-lucent.com


   Lou Berger
   LabN Consulting

   Phone: +1-301-468-9228
   EMail: lberger@labn.net























Frost, et al.                 Informational                    [Page 12]
^L