doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc7167.txt b/doc/rfc/rfc7167.txt
new file mode 100644
index 0000000..b9a8e2f
--- /dev/null
+++ b/doc/rfc/rfc7167.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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]
+