GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7167

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc7167.txt · Last modified: 2014/04/14 18:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki