diff options
Diffstat (limited to 'doc/rfc/rfc7167.txt')
| -rw-r--r-- | doc/rfc/rfc7167.txt | 675 |
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] + |