RFC 7167
A Framework for Point-to-Multipoint MPLS in Transport Networks
RFC 7167 ✨ A Framework for Point-to-Multipoint MPLS in Transport Networks
Okay bestie, the header of this RFC is basically its ID card 🪪 It's an IETF doc, numbered 7167, and it's the framework for point-to-multipoint MPLS in transport networks 🦋 It was written by D. Frost (Blue Sun), S. Bryant (Cisco Systems), M. Bocci (Alcatel-Lucent), and L. Berger (LabN Consulting). It's categorised as Informational, with ISSN 2070-1721, and it's dated April 2014. The header doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 💅
Abstract
okay so MPLS-TP (the Multiprotocol Label Switching Transport Profile) is the common set of MPLS protocol functions for building and running packet transport networks 🚆 It supports both point-to-point and point-to-multipoint transport paths. This doc defines the bits of the MPLS-TP architecture that apply specifically to supporting point-to-multipoint transport paths 💜
Status of This Memo
This doc is not an Internet Standards Track specification. It's published purely for informational purposes 🌸
It's a product of the IETF, which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐
You can find the current status, any errata, and feedback info at http://www.rfc-editor.org/info/rfc7167 🔗
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as in effect on the publication date. Read these carefully, because they spell out your rights and restrictions with regard 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 they come 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 . . . . . . . . . . . . . . . . . 101. Introduction 🌈
MPLS-TP is the common set of MPLS protocol functions defined to meet the requirements in [RFC5654]. The MPLS-TP Framework [RFC5921] gives the overall intro to MPLS-TP and defines its general architecture, along with the stuff that's specific to point-to-point transport paths. This doc's job is to define the elements and functions of the MPLS-TP architecture that apply specifically to point-to-multipoint transport paths 🦋
1.1. Scope
This doc covers the elements and functions of the MPLS-TP architecture related to point-to-multipoint transport paths. For the parts of the architecture that are generic or specifically about point-to-point transport paths, go to [RFC5921] 🧭
1.2. Terminology
Here's the glossary, so you're not lost 📖
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 LDPDetailed definitions and extra terminology live in [RFC5921] and [RFC5654] 💅
2. Applicability 💜
The point-to-multipoint connectivity you get from an MPLS-TP network is built on the point-to-multipoint connectivity that MPLS networks already provide. Traffic Engineered P2MP LSP support is covered in [RFC4875] and [RFC5332]. P2MP PW support is still being developed, based on [P2MP-PW-REQS] and [VPMS-FRMWK-REQS] 🛠️
It's giving traditional transport vibes too. MPLS-TP point-to-multipoint connectivity is analogous to what traditional transport technologies offer, like Optical Transport Network point-to-multipoint [G.798] and drop-and-continue [G.780]. So it supports the same class of traditional applications, e.g., video distribution 📺
The scope here is limited to point-to-multipoint functions. This doc doesn't discuss multipoint-to-multipoint support 🙅♀️
3. MPLS-TP P2MP Requirements 🎯
The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], and [RFC5951]. This section gives a quick summary of the point-to-multipoint transport requirements from those docs. For the definitive, complete list, go read the docs themselves 📚 This summary doesn't include the RFC 2119 [BCP14] conformance language used in the original documents, since this document isn't authoritative.
From [RFC5654]:
- MPLS-TP must support traffic-engineered point-to-multipoint transport paths. 🌸
- MPLS-TP must support unidirectional point-to-multipoint transport paths.
- 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.
- 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.
- Recovery techniques used for P2P and P2MP should be identical to simplify implementation and operation.
- Unidirectional 1+1 and 1:n protection for P2MP connectivity must be supported.
- MPLS-TP recovery in a ring must protect unidirectional P2MP transport paths.
From [RFC5860]:
- 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
- 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]:
- For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is required. 📉
- For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is required. ⏱️
more of this iconic doc coming up in part 2 🧚💜
6. Control Plane ✨
okay so the framework for the MPLS-TP control plane lives in [RFC6373] 💖 This section looks at the MPLS-TP control-plane requirements and explains how the control plane meets them. Most of the requirements in [RFC6373] apply equally to P2P and P2MP transport paths 🦋 The key P2MP-specific control-plane requirements are:
- requirement 6 (P2MP transport paths),
- requirement 34 (use P2P sub-layers),
- requirement 49 (common recovery solutions for P2P and P2MP),
- requirement 59 (1+1 protection),
- requirement 62 (1:n protection), and
- requirement 65 (1:n shared mesh recovery).
[RFC6373] defines the control-plane approach used for MPLS-TP transport paths 🌸 It names GMPLS as the control plane for MPLS-TP LSPs and tLDP as the control plane for PWs. MPLS-TP lets either or both of LSPs and PWs be provisioned statically or through a control plane, so you've got options 💅 Here's the quote from [RFC6373] that sums it up:
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.
6.1. P2MP LSP Control Plane
bestie, the MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on RSVP-TE for P2MP LSPs as defined in [RFC4875] ✨ A full breakdown of how GMPLS satisfies the MPLS-TP control-plane requirements is in [RFC6373] 📚
Now the plot twist 🙈 [RFC6373] points out that recovery techniques for traffic-engineered P2MP LSPs aren't formally defined yet, and that a definition is needed. A formal definition will be based on existing RFCs and may not need any new protocol mechanisms, but it still 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 still for further study, so this one's a work in progress, babe 🌈
7. Survivability ⭐
the overall survivability architecture for MPLS-TP is defined in [RFC6372] 👑 and Section 4.7.3 of that RFC is the one that gets into how linear protection applies to unidirectional P2MP entities, using 1+1 and 1:1 protection architectures 🦋
Here's the vibe for 1+1: the root of the P2MP tree bridges the user traffic to both the working and the protection entities 💖 Each sink/leaf MPLS-TP node then selects the traffic from one of those entities based on some predetermined criteria.
For 1:1, it's a bit more hands-on 🔥 The source/root MPLS-TP node has to identify that a fault condition is affecting delivery to any of the leaves. Fault notification goes from the node that spotted the fault to the root node over an out-of-band path. Then the root 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 hasn't got any experience with P2MP PW survivability yet, so for now the P2MP PW survivability is going to initially rely on the LSP survivability 🫶 More work is needed on this, especially if a requirement shows up to provide survivability for P2MP PWs in an MPLS-TP context 👀
8. Network Management 🎀
an overview of network management considerations for MPLS-TP is in Section 3.14 of [RFC5921] 💜 That description applies equally to P2MP transport paths ✨
The network management architecture and requirements for MPLS-TP are specified in [RFC5951] 🧚 They come from the generic specifications in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. They also bring in the OAM requirements for MPLS networks [RFC4377] and MPLS-TP networks [RFC5860], and they expand on those to cover the changes needed for fault, configuration, performance, and security in a transport network 🌈 [RFC5951] covers all MPLS-TP connection types, including P2MP 🦋
[RFC6639] gives the MIB-based architecture for MPLS-TP 🍓 It reviews how the different MIB modules that aren't MPLS-TP specific relate to each other, and that can be leveraged for MPLS-TP network management. It also identifies areas where additional MIB modules are required 📚 The document doesn't consider P2MP transport paths, but it does give a foundation for analysing where MIB-module modification and addition might be needed to fully support P2MP transport paths 🙈 There's also been work in the MPLS working group on a P2MP specific MIB, [MPLS-TE-P2MP-MIB] 💅
9. Security Considerations 💀
okay, security time, and this one's serious 🔒 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 the ones covered in those documents. So go read those, no cap 🫶
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.
[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.
[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.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📦 where this page comes from
- ietf: rfc7167 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms