Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7167.
Authors Dan Frost , Stewart Bryant , Matthew Bocci , Lou Berger
Last updated 2013-04-08
Replaces draft-fbb-mpls-tp-p2mp-framework
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Loa Andersson
IESG IESG state Became RFC 7167 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mpls-tp-p2mp-framework-01
MPLS Working Group                                         D. Frost, Ed.
Internet-Draft                                            S. Bryant, Ed.
Intended status: Informational                             Cisco Systems
Expires: October 10, 2013                                  M. Bocci, Ed.
                                                          Alcatel-Lucent
                                                          L. Berger, Ed.
                                                         LabN Consulting
                                                          April 08, 2013

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

Abstract

   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 functions 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://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 October 10, 2013.

Copyright Notice

Frost, et al.           Expires October 10, 2013                [Page 1]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

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

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.

Frost, et al.           Expires October 10, 2013                [Page 2]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   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 functions 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

Frost, et al.           Expires October 10, 2013                [Page 3]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   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 (OTN) point-
   to-multipoint [G.798] and drop-and-continue [G.780], and thus
   supports the same class of traditional applications, e.g., video
   distribution.

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.

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

   o  MPLS-TP must support traffic-engineered 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.

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

3.  Architecture

Frost, et al.           Expires October 10, 2013                [Page 4]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   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:

   o  Unidirectional point-to-multipoint Label Switched Paths (LSPs)

   o  Unidirectional point-to-multipoint pseudowires (PWs)

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

   o  Survivability, network management, and Operations, Administration
      and Maintenance (OAM) 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
   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.

Frost, et al.           Expires October 10, 2013                [Page 5]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

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

Frost, et al.           Expires October 10, 2013                [Page 6]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   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.  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 on any of the branches of the network.  Fault
   notification happens from the node identifying 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, particularly if a requirement 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

Frost, et al.           Expires October 10, 2013                [Page 7]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   [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

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

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

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

Frost, et al.           Expires October 10, 2013                [Page 8]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

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

   [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

   [G.7710]   ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common
              equipment management function requirements", 2007.

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

   [G.798]    ITU-T Recommendation G.798 (10/2010), "Characteristics of
              optical transport network hierarchy equipment functional
              blocks", 2010.

   [I-D.hmk-mpls-tp-p2mp-oam-framework]
              Koike, Y., Hamano, T., and M. Namiki, "Framework for
              Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp-
              oam-framework-02 (work in progress), February 2013.

   [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)", draft-ietf-l2vpn-vpms-
              frmwk-requirements-05 (work in progress), 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", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in
              progress), September 2011.

Frost, et al.           Expires October 10, 2013                [Page 9]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   [I-D.ietf-pwe3-p2mp-pw]
              Sivabalan, S., Boutros, S., and L. Martini, "Signaling
              Root-Initiated Point-to-Multipoint Pseudowire using LDP",
              draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.

   [I-D.raggarwa-pwe3-p2mp-pw-encaps]
              Aggarwal, R. and F. JOUNAY, "Point-to-Multipoint Pseudo-
              Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw-encaps-01
              (work in progress), March 2010.

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

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

   [RFC6718]  Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
              Redundancy", RFC 6718, August 2012.

Authors' Addresses

   Dan Frost (editor)
   Cisco Systems

   EMail: danfrost@cisco.com

Frost, et al.           Expires October 10, 2013               [Page 10]
Internet-Draft   MPLS Transport Profile P2MP Framework        April 2013

   Stewart Bryant (editor)
   Cisco Systems

   EMail: stbryant@cisco.com

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

   EMail: matthew.bocci@alcatel-lucent.com

   Lou Berger (editor)
   LabN Consulting

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

Frost, et al.           Expires October 10, 2013               [Page 11]