RFC 4834
Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
RFC 4834: Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) 🎀
okay bestie, this is the title block 💖
- Network Working Group 🌸
- Author: T. Morin, Ed., France Telecom R&D 🦋
- Request for Comments: 4834 ✨
- Category: Informational 📚
- Date: April 2007 📅
- Obsoletes/Updates: nothing! This one doesn't obsolete or update any other RFC 🙌
Status of This Memo 🫶
Okay so this bit is basically the disclaimer. This memo gives information to the Internet community. It is not an Internet standard of any kind, and it's free to share with anyone, no cap 💅
Copyright Notice 🌈
Copyright (C) The IETF Trust (2007). Legal stuff, but make it cute 🎀
Abstract 🧚
Okay so the vibe here is: this document lays out a set of functional requirements for network solutions that let IP multicast live inside Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). ✨ It covers requirements from both the end user side and the service provider side. The plan is that any future solution for multicast in these VPNs will use these requirements as guidelines. It's giving blueprint 📋💜
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7
3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9
4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10
4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10
4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11
4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11
4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11
4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12
4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12
4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12
4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13
4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13
5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13
5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13
5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13
5.1.2. CE-PE Multicast Routing and Group Management
Protocols . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14
5.1.4. Operations and Management . . . . . . . . . . . . . . 15
5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16
5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18
5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18
5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19
5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20
5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21
5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21
5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23
5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24
5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26
5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26
5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27
5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27
5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28
5.2.10. Operation, Administration, and Maintenance . . . . . . 28
5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 331. Introduction ✨
Okay so Virtual Private Network (VPN) services that meet the requirements in [RFC4031] are now being offered by tons of service providers around the world 🌍 VPNs are super popular because customers don't need to know what VPN tech is running inside the provider network. 💅 They scale well for these reasons:
- because P routers (Provider Routers) don't need to be aware of VPN service details 🧚
- because adding a new VPN member only takes a little bit of configuration effort 🍓
There's also a growing need for IP multicast-based services 🔥 Standards bodies have put real work into efficient IP multicast routing protocols and multicast group management, and that's how we got Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP) 🎀
However, multicast traffic isn't natively supported in existing L3 PPVPN solutions 😭 Deploying multicast over an L3VPN today, using only currently standardized solutions, means building customized solutions. Those are inherently limited when it comes to scalability, operational efficiency, and bandwidth usage. 💀
This document complements the generic L3VPN requirements document [RFC4031] 💜 It adds requirements that are specific to deploying IP multicast-based services within PPVPNs. It clarifies what both VPN clients and providers need, and it lays out the problems that technical solutions should address. The key objective is to stay solution agnostic 🦋 This document doesn't specify solution-specific details or application-specific requirements. It also does not try to express multicast-related requirements that aren't specific to L3 PPVPNs.
Solutions that specify procedures and protocol extensions for multicast in L3 PPVPNs SHOULD satisfy these requirements. 🫶
2. Conventions Used in This Document 📚
2.1. Terminology 🌸
Okay so the reader is assumed to already know the terminology from [RFC4031], [RFC4364], [RFC4601], and [RFC4607]. Even so, the glossary below may be worth a look 👀
We also propose generic terms here for concepts that naturally come up when people talk about multicast in VPNs 🧚
ASM: Any Source Multicast. One of the two multicast service models, where a terminal subscribes to a multicast group to receive data sent to the group by any source. 🌈
Multicast-enabled VPN, multicast VPN, or mVPN: A VPN that supports IP multicast capabilities. In other words, some PE devices (if not all) are multicast-enabled, and its core architecture supports multicast VPN routing and forwarding. 🦋
PPVPN: Provider-Provisioned Virtual Private Network. 💖
PE, CE: "Provider Edge" and "Customer Edge," as defined in [RFC4026]. Following [RFC4026], these notations refer to the equipment, routers, and devices themselves. So "PE" is the router on the provider's edge that faces the "CE," which is the router on the customer's edge. 🎀
VRF or VR: These terms refer to the entity defined in a PE that's dedicated to a specific VPN instance. "VRF" means "VPN Routing and Forwarding table" as defined in [RFC4364], and "VR" means "Virtual Router" as defined in the [VRs] terminology. 🍓
MDTunnel: Multicast Distribution Tunnel. This is the means by which the customer's multicast traffic gets carried across the SP network. It's meant in a generic way, so these tunnels can be either point-to-point or point-to-multipoint. The definition might seem to assume distribution tunnels are unidirectional, but the wording also covers bidirectional tunnels. 🌊
S: Denotes a multicast source. 🧚
G: Denotes a multicast group. 🧚
Multicast channel: In the multicast SSM model [RFC4607], a "multicast channel" means traffic from a specific source S to a multicast group G. It's also called "(S,G)". 💜
SP: Service provider. 💅
SSM: Source Specific Multicast. One of the two multicast service models, where a terminal subscribes to a multicast group to receive data sent to the group by one specific source. ✨
RP: Rendezvous Point (from Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]). 🌈
P2MP, MP2MP: These mean "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees. 🌳
L3VPN, VPN: Throughout this document, "L3VPN," or even just "VPN," refers to "Provider-Provisioned Layer 3 Virtual Private Network" (PP L3VPNs). The shorter forms are used because they're easier to read. 🙈
For details on terminology that's specifically relevant to VPN aspects, check [RFC4026]. For multicast performance or quality of service (QoS)-related terms, check [RFC2432]. 🎀
2.2. Conventions 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 👑
3. Problem Statement 🔥
3.1. Motivations 🌟
More and more L3VPN customers are using IP multicast services inside their private infrastructures 📡 Naturally, they want to extend those multicast services to remote sites that are connected through a VPN. 🫶
For example, the customer could be a national TV channel with several geographic locations that wants to broadcast a TV program from a central point to several regional locations within its VPN 📺
A solution that supports multicast traffic could consist of point-to-point tunnels across the provider network. That requires the PEs (Provider Edge routers) to replicate traffic. Honestly, this would be sub-optimal, because it would put the replication burden on the PE and would have very poor scaling characteristics. It would also probably waste bandwidth and control plane resources in the provider's network. 😬
So, to provide multicast services for L3VPN networks efficiently (meaning with a scalable impact on signaling and protocol state, as well as on bandwidth usage) in a large-scale environment, new mechanisms are required to enhance existing L3VPN solutions so they properly support multicast-based services. 🦋✨
3.2. General Requirements
Okay bestie, this is the big vibe check 💅✨ This document sets out requirements for L3 provider-provisioned VPN solutions that carry customers' multicast traffic 🦋. The main requirement is that a solution SHOULD first satisfy the requirements documented in [RFC4031]: as far as possible, a multicast service should have the same characteristics as its unicast equivalent, including the same simplicity (technology unaware), the same quality of service (if any), the same management (e.g., performance monitoring), and so on 🎀.
Moreover, it also has to be clear that a multicast VPN solution MUST interoperate seamlessly with current unicast VPN solutions 🫶. It would also make sense that multicast VPN solutions define themselves as extensions to existing L3 provider-provisioned VPN solutions (such as, for instance, [RFC4364] or [VRs]) and retain consistency with those, although this is not a core requirement 🌸.
The requirements in this document are equally applicable to IPv4 and IPv6, for both customer- and provider-related matters 🌈.
3.3. Scaling vs. Optimizing Resource Utilization
When transporting multicast VPN traffic over a service provider network, there intrinsically is tension between scalability and resource optimization 😭. The latter is likely to require the maintenance of control plane states related to replication trees in the core network [RFC3353], so it's a whole thing.
Consequently, any deployment will require a trade-off to be made. This document will express some requirements related to this trade-off 🍓.
4. Use Cases
The goal of this section is to highlight how different applications and network contexts may have a different impact on how a multicast VPN solution is designed, deployed, and tuned 🧚. For this purpose, we describe some typical use case scenarios and express expectations in terms of deployment orders of magnitude.
Most of the content of these sections originates from a survey done in summer 2005, among institutions and providers that expect to deploy such solutions 📋. The full survey text and raw results (13 responses) were published separately, and we only present here the most relevant facts and expectations that the survey exposed.
For scalability figures, we considered that it was relevant to highlight the highest expectations, those that are expected to have the greatest impact on solution design 👑. For balance, we do also mention cases where such high expectations were expressed in only a few answers.
4.1. Scenarios
We don't provide here an exhaustive set of scenarios that a multicast VPN solution is expected to support -- no solution should restrict the scope of multicast applications and deployments that can be done over a multicast VPN 💜.
Hence, we only give here a short list of scenarios that are expected to have a large impact on the design of a multicast VPN solution.
4.1.1. Live Content Broadcast
Under this label, we group all applications that distribute content (audio, video, or other content) with the property that this content is expected to be consulted at once ("live") by the receiver 📺. Typical applications are broadcast TV, production studio connectivity, and distribution of market data feeds.
The characteristics of such applications are the following:
- one or few sources to many receivers
- sources are often in known locations; receivers are in less predictable locations (this latter point may depend on applications)
- in some cases, it is expected that the regularity of audience patterns may help improve how the bandwidth/state trade-off is handled
- the number of streams can be as high as hundreds, or even thousands, of streams
- bandwidth will depend on the application, but may vary between a few tens/hundreds of Kb/s (e.g., audio or low-quality video media) and tens of Mb/s (high-quality video), with some demanding professional applications requiring as much as hundreds of Mb/s 🎬
- QoS requirements include, in many cases, a low multicast group join delay
- QoS of these applications is likely to be impacted by packet loss (some applications may be robust to low packet loss) and to have low robustness against jitter
- delay sensitivity will depend on the application: some applications are not so delay sensitive (e.g., broadcast TV), whereas others may require very low delay (professional studio applications)
- some of these applications may involve rapid changes in customer multicast memberships as seen by the PE, but this will depend on audience patterns and on the amount of provider equipments deployed close to VPN customers
4.1.2. Symmetric Applications
Some use cases exposed by the survey can be grouped under this label, and include many-to-many applications such as conferencing and server cluster monitoring 🗣️.
They are characterized by the relatively high number of streams that they can produce, which has a direct impact on scalability expectations.
A sub-case of this scenario is the case of symmetric applications with small groups, when the number of receivers is low compared to the number of sites in the VPNs (e.g., video conferencing and e-learning applications) 🎓.
This latter case is expected to be an important input to solution design, since it may significantly impact how the bandwidth/state is managed.
Optimizing bandwidth may require introducing dedicated states in the core network (typically as much as the number of groups) for the following reasons:
- small groups, and low predictability of the location of participants ("sparse groups")
- possibly significantly high bandwidth (a few Mb/s per participant)
Lastly, some of these applications may involve real-time interactions and will be highly sensitive to packet loss, jitter, and delay ⏱️.
4.1.3. Data Distribution
Some applications that are expected to be deployed on multicast VPNs are non-real-time applications aimed at distributing data from few sources to many receivers 📦.
Such applications may be considered to have lower expectations than their counterparts proposed in this document, since they would not necessarily involve more data streams and are more likely to adapt to the available bandwidth and to be robust to packet loss, jitter, and delay.
One important property is that such applications may involve higher bandwidths (hundreds of Mb/s).
4.1.4. Generic Multicast VPN Offer
This ISP scenario is a deployment scenario where IP-multicast connectivity is proposed for every VPN: if a customer requests a VPN, then this VPN will support IP multicast by default 🌍. In this case, the number of multicast VPNs equals the number of VPNs. This implies a quite important scalability requirement (e.g., hundreds of PEs, hundreds of VPNs per PE, with a potential increase by one order of magnitude in the future).
The per-mVPN traffic behavior is not predictable because how the service is used is completely up to the customer. This results in a traffic mix of the scenarios mentioned in Section 4.1. QoS requirements are similar to typical unicast scenarios, with the need for different classes. Also, in such a context, a reasonably large range of protocols should be made available to the customer for use at the PE-CE level 🧩.
Also, in such a scenario, customers may want to deploy multicast connectivity between two or more multicast VPNs as well as access to Internet Multicast 🦋.
4.2. Scalability Orders of Magnitude
This section proposes orders of magnitude for different scalability metrics relevant for multicast VPN issues 📏. It should be noted that the scalability figures proposed here relate to scalability expectations of future deployments of multicast VPN solutions, as the authors chose to not restrict the scope to only currently known deployments.
4.2.1. Number of VPNs with Multicast Enabled
From the survey results, we see a broad range of expectations. There are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), but more typical answers are split between the low range of tens of VPNs (7 answers) and the higher range of hundreds or thousands of VPNs (2 + 4 answers) 📊.
A solution SHOULD support a number of multicast VPNs ranging from one to several thousands.
A solution SHOULD NOT limit the proportion of multicast VPNs among all (unicast) VPNs 🙅.
4.2.2. Number of Multicast VPNs per PE
The majority of survey answers express a number of multicast VPNs per PE of around tens (8 responses between 5 and 50); a significant number of them (4) expect deployments with hundreds or thousands (1 response) of multicast VPNs per PE 🌷.
A solution SHOULD support a number of multicast VPNs per PE of several hundreds, and may have to scale up to thousands of VPNs per PE.
4.2.3. Number of CEs per Multicast VPN per PE
Survey responses span from 1 to 2000 CEs per multicast VPN per PE. Most typical responses are between tens (6 answers) and hundreds (4 responses) 🏢.
A solution SHOULD support a number of CEs per multicast VPN per PE going up to several hundreds (and may target the support of thousands of CEs).
4.2.4. PEs per Multicast VPN
People who answered the survey typically expect deployments with the number of PEs per multicast VPN in the range of hundreds of PEs (6 responses) or tens of PEs (4 responses). Two responses were in the range of thousands (one mentioned a 10k figure) 🌟.
A multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands.
4.2.4.1. ... with Sources
The number of PEs (per VPN) that would be connected to sources seems to be significantly lower than the number of PEs per VPN. This is obviously related to the fact that many respondents mentioned deployments related to content broadcast applications (one to many) 📡.
Typical numbers are tens (6 responses) or hundreds (4 responses) of source-connected PEs. One respondent expected a higher number of several thousands.
A solution SHOULD support hundreds of source-connected PEs per VPN, and some deployment scenarios involving many-to-many applications may require supporting a number of source-connected PEs equal to the number of PEs (hundreds or thousands) 💖.
4.2.4.2. ... with Receivers
The survey showed that the number of PEs with receivers is expected to be of the same order of magnitude as the number of PEs in a multicast VPN. This is consistent with the intrinsic nature of most multicast applications, which have few source-only participants 🫧.
4.2.5. PEs with Multicast VRFs
A solution SHOULD scale up to thousands of PEs having multicast service enabled 🚀.
4.2.6. Number of Streams Sourced
Survey responses led us to retain the following orders of magnitude for the number of streams that a solution SHOULD support 🔥:
- per VPN: hundreds or thousands of streams
- per PE: hundreds of streams
5. Requirements for Supporting IP Multicast within L3 PPVPNs
Again, the aim of this document is not to specify solutions but to give requirements for supporting IP multicast within L3 PPVPNs 🙈.
In order to list these requirements, we have taken the standpoint of two different important entities: the end user (the customer using the VPN) and the service provider 🧁.
In the rest of the document, by "a solution" or "a multicast VPN solution", we mean a solution that allows multicast in an L3 provider-provisioned VPN, and which addresses the requirements listed in this document ✨.
5.1. End User/Customer Standpoint
5.1.1. Service Definition ✨
Okay so, just like unicast, the multicast service MUST be provider provisioned 🎀. It SHALL NOT make customer devices (CEs) learn any extra tricks beyond what they'd need for multicast outside a VPN, which is honestly so considerate 🥹. Turning on multicast for a VPN SHOULD be possible with no impact (or very limited impact) on any multicast protocols that are already running on the CE devices. Main character energy for the CEs 💅
5.1.2. CE-PE Multicast Routing and Group Management Protocols
Bc of Section 5.1.1, the multicast-related protocol chats between a CE and its directly connected PE SHOULD happen through the existing multicast protocols 🦋
The usual suspects are:
- PIM-SM [RFC4601]
- bidirectional-PIM [BIDIR-PIM]
- PIM - Dense Mode (DM) [RFC3973]
- IGMPv3 [RFC3376] (this version implicitly supports hosts that only implement IGMPv1 [RFC1112] or IGMPv2 [RFC2236])
Out of those, supporting PIM-SM (which includes the SSM model) and either IGMPv3 (for IPv4 solutions) and/or Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions) is REQUIRED 👑. Bidir-PIM support at the PE-CE interface is RECOMMENDED ✨. And when you think about real deployments, PIM-DM is considered OPTIONAL 🌸
When a multicast VPN solution is built on a VPN solution that supports IPv6 unicast, it MUST also support the v6 variants of the above protocols, including MLDv2, and the PIM-SM IPv6-specific procedures 🧚. For a multicast VPN solution built on a unicast VPN solution that only supports IPv4, it is RECOMMENDED that the design favors the definition of procedures and encodings that make adapting to IPv6 easy 🫶
5.1.3. Quality of Service (QoS)
Firstly, the general QoS vibes for L3VPNs in Section 5.5 of [RFC4031] are also relevant here 💖
QoS is measured in terms of delay, jitter, packet loss, and availability 📊. These metrics are already defined for current unicast PPVPN services and get written into Service Level Agreements (SLAs). Sometimes the agreed SLA is different for unicast and multicast, and that means you'll need differentiation mechanisms so you can monitor both SLAs 🔥
The level of availability for the multicast service SHOULD be on par with what exists for unicast traffic 💅. For instance, comparable traffic protection mechanisms SHOULD be available for customer multicast traffic when it's carried over the service provider's network 🛡️
A multicast VPN solution SHALL let a service provider define at least the same level of quality of service as exists for unicast, and as exists for multicast in a non-VPN context ✨. From that angle, multicast-based services inside an L3VPN SHALL benefit from Diffserv [RFC2475] mechanisms, including multicast traffic identification, classification, and marking, plus multicast traffic policing, scheduling, and conditioning 🎀. So those capabilities MUST be supported by every participating device that helps set up and maintain the multicast distribution tunnel within the VPN 🙈
Multicast is often used for high-quality stuff like TV broadcast 📺, so a multicast VPN solution MAY provide extra features for high QoS, like bandwidth reservation and admission control 👑
Also, since multicast reception is receiver-triggered, group join delay (as defined in [RFC2432]) is an important QoS parameter too 🦋. So it is RECOMMENDED that a multicast VPN solution be designed with this in mind 💜
The group leave delay (as defined in [RFC2432]) may also matter on the CE-PE link for some usage scenarios 🍓. When the typical bandwidth of multicast streams is close to the bandwidth of a PE-CE link, it's important to be able to stop a stream on the PE-CE link as soon as the CE stops requesting it, so you can switch fast between two high-throughput multicast streams 🌈. This means that it SHOULD be possible to tune the multicast routing or group management protocols (e.g., IGMP/MLD or PIM) used on the PE-CE adjacency to bring the group leave delay down to the minimum ⏱️
Lastly, a multicast VPN solution SHOULD, as much as possible, make sure client multicast traffic packets are neither lost nor duplicated, even when the way a client multicast data stream is carried over the provider network changes 😭. Packet loss also has to be considered when a new source starts sending traffic to a group: any receiver interested in that traffic SHOULD be serviced accordingly 🫶
5.1.4. Operations and Management
The requirements and definitions for operations and management (OAM) of L3VPNs that are defined in [RFC4176] apply to multicast too, so they aren't repeated at length here 💅. This subsection just calls out the most important guidelines and points that matter specifically for multicast in L3VPNs 📝
A multicast VPN solution SHOULD let a multicast VPN customer manage the capabilities and characteristics of their multicast VPN services 🎀
A multicast VPN solution MUST support SLA monitoring capabilities 🔍. Those SHOULD rely on techniques similar to the ones used for the unicast service for the same monitoring purposes. Multicast SLA-related metrics SHOULD be available through means similar to those already used for unicast monitoring, such as Simple Network Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT] 🦋
Multicast-specific things you might monitor include: multicast statistics per stream, end-to-end delay, and group join/leave delay (time to start or stop receiving a multicast group's traffic across the VPN, as defined in [RFC2432], Section 3) 🧚
The monitoring of multicast-specific parameters and statistics MUST include multicast traffic statistics: total, incoming, outgoing, and dropped traffic, by period of time 📊. It MAY also include IP Performance Metrics (IPPM, [RFC2330]) information that's relevant to how the multicast traffic is used, such as the one-way packet delay, the inter-packet delay variation, etc. See [MULTIMETRICS] 💜
A generic discussion of SLAs is in [RFC3809] 📚
Besides stats on multicast traffic, customers of a multicast VPN will want to know how their multicast resources are doing (multicast routing states and bandwidth) 💖. As mentioned in Section 5.2.5, a service provider may limit the number (and/or throughput) of multicast streams that are received from or sent to a client site, for scalability reasons 🙈. In that case, a multicast VPN solution SHOULD let customers find out their current resource usage (multicast routing states and throughput), and get some kind of feedback if their usage goes over the agreed bounds 🚨. Whether this is better handled at the protocol level on the PE-CE interface, or at the Service Management Level interface [RFC4176], is still open for discussion 🤔
It is RECOMMENDED that any OAM mechanism designed to trigger alarms for performance or resource usage metrics also include the ability to limit how fast those alarms get generated (e.g., some form of hysteresis mechanism based on low/high thresholds defined for the metrics) 🚨
5.1.5. Security Requirements
Security is a huge deal for a customer who uses a VPN service 🔐. For example, the [RFC4364] model gives some guarantees about the security level of data transmission within the VPN 💅
A multicast VPN solution MUST provide an architecture with the same level of security for both unicast and multicast traffic 🛡️
Also, turning on multicast features SHOULD be possible:
- per VRF / per VR
- per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR)
- per multicast group and/or per channel
- with a distinction between multicast reception and emission
A multicast VPN solution may choose to make the optimality/scalability trade-off stated in Section 3.3, by sometimes distributing multicast traffic of a client group to a larger set of PE routers that may include PEs that aren't part of the VPN 🌍. From a security standpoint, this can be a problem for some VPN customers, so a multicast VPN solution using such a scheme MAY offer ways to avoid this for specific customers (and/or specific customer multicast streams) 😭
5.1.6. Extranet
In current PP L3VPN models, a customer site may be set up to be part of multiple VPNs, and that should still be possible when a VPN is multicast-enabled 🌸. In practice, that means a VRF or VR can be part of more than one VPN 🦋
A multicast VPN solution MUST support such deployments 💜
For instance, it must be possible to configure a VRF so that an enterprise site participating in a BGP/MPLS multicast-enabled VPN, and connected to that VRF, can receive a multicast stream from (or originate a multicast stream towards) another VPN associated with that VRF 🧚
This means that a multicast VPN solution MUST offer ways for a VRF to be configured so that multicast connectivity can be set up for a chosen set of extranet VPNs 🎀. More precisely, it MUST be possible to configure a VRF so that:
- receivers behind attached CEs can receive multicast traffic sourced in the configured set of extranet VPNs
- sources behind attached CEs can reach multicast traffic receivers located in the configured set of extranet VPNs
- multicast reception and emission can be independently enabled for each of the extranet VPNs
Also, a solution MUST let service providers control an extranet's multicast connectivity independently from its unicast connectivity 👑. More specifically:
- enabling unicast connectivity to another VPN MUST be possible without activating multicast connectivity with that VPN
- enabling multicast connectivity with another VPN SHOULD NOT require more than the strict minimal unicast routing. Sending multicast to a VPN SHOULD NOT require having unicast routes to that VPN; receiving multicast from a VPN SHOULD be possible with nothing more than unicast routes to the relevant multicast sources of that VPN
- when unicast routes from another VPN are imported into a VR/VRF for multicast Reverse Path Forwarding (RPF) resolution, this SHOULD be possible without making those routes available for unicast routing
Proper support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link, whether that link is physical or logical 🙅♀️💖
5.1.7. Internet Multicast
Connectivity with Internet Multicast is a special case of the previous section, where sites attached to a VR/VRF need to receive or send multicast traffic from or to the Internet 🌐✨
This should be considered OPTIONAL 🫧, given the extra considerations, like security, needed to meet the requirements for providing Internet Multicast 🔒
5.1.8. Carrier's Carrier 🧺
Okay so, lots of L3 PPVPN solutions, like [RFC4364] and [VRs], have this "Carrier's Carrier" model 💅, where a "carrier's carrier" service provider supports one or more customer ISPs, aka "sub-carriers" 🫶. A multicast VPN solution SHOULD support the carrier's carrier model in a scalable and efficient manner ✨.
Ideally, the range of tunneling protocols available for the sub-carrier ISP should be the same as those available for the carrier's carrier ISP 🌸. Which basically means the protocols that can be used at the PE-CE level SHOULD NOT be restricted to the ones required in Section 5.1.2, and they SHOULD include some of the protocols in Section 5.2.4, like P2MP MPLS signaling protocols 🦋.
In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs [RFC4364], this means that MPLS label distribution SHOULD happen at the PE-CE level 🌈. That gives the sub-carrier the ability to use multipoint LSPs as a tunneling mechanism 🧚.
5.1.9. Multi-Homing, Load Balancing, and Resiliency 💪
A multicast VPN solution SHOULD be compatible with current solutions that aim at improving service robustness for customers, like multi-homing, CE-PE link load balancing, and fail-over 🔥. It SHOULD also be able to offer those same features for multicast traffic 💖.
Any solution SHOULD support redundant topology of CE-PE links. It SHOULD minimize multicast traffic disruption and fail-over 🌟.
5.1.10. RP Engineering 🎀
When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer side, the RP function (or RP-address in the case of bidir-PIM) has to be associated to a node running PIM, and configured on this node 👑.
5.1.10.1. RP Outsourcing 🧁
In the case of PIM-SM in ASM mode, engineering the RP function needs specific protocols and associated configurations. A service provider may offer to manage customers' multicast protocol operation on their behalf. This means it's necessary to consider cases where a customer's RPs are outsourced (e.g., on PEs). So a VPN solution MAY support hosting the RP function in a VR or VRF 💅.
5.1.10.2. RP Availability 🛟
Availability of the RP function (or address) is required for proper operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity to the RP from a receiver or source will impact the multicast service 😭. That's why different mechanisms exist, like BSR [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)-based [RFC3446] or PIM-based [RFC4610]) 🧠.
These protocols and procedures SHOULD work transparently through a multicast VPN, and MAY, if relevant, be implemented in a VRF/VR 🫶.
Moreover, a multicast VPN solution MAY improve the robustness of the ASM multicast service regarding loss of connectivity to the RP, by providing specific features that help:
- a) maintain ASM multicast service among all the sites within an MVPN that maintain connectivity among themselves, even when the site(s) hosting the RP lose their connectivity to the MVPN
- b) maintain ASM multicast service within any site that loses connectivity to the service provider
5.1.10.3. RP Location 📍
In the case of PIM-SM, when a source starts to emit traffic toward a group (in ASM mode), if sources and receivers are located in VPN sites that are different from the RP's, then traffic may transiently flow twice through the SP network and the CE-PE link of the RP (from source to RP, and then from RP to receivers). This traffic peak, even short, may not be convenient depending on the traffic and link bandwidth 📈.
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue ✨.
5.1.11. Addressing 🏠
A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions on multicast group addresses used by VPN customers 🙅.
In particular, like unicast traffic, an overlap of multicast group address sets used by different VPN customers MUST be supported 🤝.
The use of globally unique means of multicast-based service identification at the scale of the domain where such services are provided SHOULD be recommended. For IPv4 multicast, this implies the use of the multicast administratively scoped range (239/8 as defined by [RFC2365]) for services that are to be used only inside the VPN, and of either SSM-range addresses (232/8 as defined by [RFC4607]) or globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for services for which traffic may be transmitted outside the VPN 🌍.
5.1.12. Minimum MTU 📏
For customers, it is often a serious issue whether or not transmitted packets will be fragmented 😬. In particular, some multicast applications might have different requirements than those that make use of unicast, and they may expect services that guarantee available packet length not to be fragmented.
Therefore, a multicast VPN solution SHOULD be designed with these considerations in mind. In practice:
- the encapsulation overhead of a multicast VPN solution SHOULD be minimized, so that customer devices can be free of fragmentation and reassembly activity as much as possible
- a multicast VPN solution SHOULD enable the service provider to commit to a minimum path MTU usable by multicast VPN customers
- a multicast VPN solution SHOULD be compatible with path MTU discovery mechanisms (see [RFC1191] and [RFC4459]), and particular care SHOULD be given to means to help troubleshoot MTU issues
Moreover, since Ethernet LAN segments are often located at first and last hops, a multicast VPN solution SHOULD be designed to allow for a minimum 1500-byte IP MTU for VPN customers multicast packet, when the provider backbone design allows it 💖.
5.2. Service Provider Standpoint 🏢
Note: To avoid repetition and confusion with terms used in solution specifications, we introduced in Section 2.1 the term MDTunnel (for Multicast Distribution Tunnel), which designates the data plane means used by the service provider to forward customer multicast traffic over the core network.
5.2.1. General Requirement 🌟
The deployment of a multicast VPN solution SHOULD be possible with no (or very limited) impact on existing deployments of standardized multicast-related protocols on P and PE routers 💫.
5.2.2. Scalability 📈
Some currently standardized and deployed L3VPN solutions have the major advantage of being scalable in the core regarding the number of customers and the number of customer routes. For instance, in the [RFC4364] and Virtual Router [VRs] models, a P router sees a number of MPLS tunnels that is only linked to the number of PEs and not to the number of VPNs, or customer sites 🧠.
As far as possible, this independence in the core, with respect to the number of customers and to customer activity, is recommended. Yet, it's recognized that in our context scalability and resource usage optimality are competing goals, so this requirement may be reduced to giving the possibility of bounding the quantity of states that the service provider needs to maintain in the core for MDTunnels, with a bound being independent of the multicast activity of VPN customers 🎯.
It is expected that multicast VPN solutions will use some kind of point-to-multipoint technology to efficiently carry multicast VPN traffic, and because such technologies require maintaining state information, this will use resources in the control plane of P and PE routers (memory and processing, and possibly address space) 🧮.
Scalability is a key requirement for multicast VPN solutions. Solutions MUST be designed to scale well with an increase in any of the following:
- the number of PEs
- the number of customer VPNs (total and per PE)
- the number of PEs and sites in any VPN
- the number of client multicast channels (groups or source-groups)
Please consult Section 4.2 for typical orders of magnitude up to which a multicast VPN solution is expected to scale 👀.
Scalability of both performance and operation MUST be considered.
Key considerations SHOULD include:
- the processing resources required by the control plane (neighborhood or session maintenance messages, keep-alives, timers, etc.)
- the memory resources needed for the control plane
- the amount of protocol information transmitted to manage a multicast VPN (e.g., signaling throughput)
- the amount of control plane processing required on PE and P routers to add or remove a customer site (or a customer from a multicast session)
- the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
- other particular elements inherent to each solution that impact scalability (e.g., if a solution uses some distribution tree inside the core, topology of the tree and number of leaf nodes may be some of them)
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
These considerations naturally lead us to believe that proposed solutions SHOULD offer the possibility of sharing such resources between different multicast streams (between different VPNs, between different multicast streams of the same or of different VPNs). This means, for instance, if MDTunnels are trees, being able to share an MDTunnel between several customers 🤝.
Those scalability issues are expected to be more significant on P routers, but a multicast VPN solution SHOULD address both P and PE routers as far as scalability is concerned 🫶.
5.2.3. Resource Optimization ⚡
5.2.3.1. General Goals 🎯
One of the aims of the use of multicast instead of unicast is resource optimization in the network 💰.
The two obvious suboptimal behaviors that a multicast VPN solution would want to avoid are needless duplication (when the same data travels twice or more on a link, e.g., when doing ingress PE replication) and needless reception (e.g., a PE receiving traffic that it does not need because there are no downstream receivers) 🚫.
5.2.3.2. Trade-off and Tuning
okay so, remember how we said earlier that designing a scalable solution that makes optimal use of resources is genuinely difficult? 😭 So what we expect from a multicast VPN solution is that it tackles the resource optimization issue while accepting that some trade-off has to happen 💅
And honestly? A "one size fits all" trade-off probably doesn't exist either 🙈 So a multicast VPN solution SHOULD offer service providers appropriate configuration settings that let them tune the trade-off to their own constraints (network topology, platforms, customer applications, level of service offered etc.) ✨
Here are some example bounds of the trade-off space 🦋:
- Bandwidth optimization: setting up optimized core MDTunnels whose topology (PIM or P2MP LSP trees, etc.) precisely follows a customer's multicast routing changes. This requires managing a large amount of state in the core, and also quick reactions of the core to customer multicast routing changes. This approach can be advantageous in terms of bandwidth, but it is poor in terms of state management. 💀
- State optimization: setting up MDTunnels that aggregate multiple customer multicast streams (all or some of them, across different VPNs or not). This will have better scalability properties, but at the expense of bandwidth since some MDTunnel leaves will very likely receive traffic they don't need, and because increased constraints will make it harder to find optimal MDTunnels. 🧚
5.2.3.3. Traffic Engineering
If the VPN service provides traffic engineering (TE) features for the connection used between PEs for unicast traffic in the VPN service, the solution SHOULD provide equivalent features for multicast traffic. Bestie, that's the vibe: if unicast has the glow-up, multicast gets it too 🌸
A solution SHOULD offer means to support key TE objectives as defined in [RFC3272], for the multicast service. ✨
A solution MAY also usefully support means to address multicast-specific traffic engineering issues: it is known that bandwidth resource optimization in the point-to-multipoint case is an NP-hard problem, and that techniques used for unicast TE may not be applicable to multicast traffic. Lowkey a hard problem, not gonna lie 🥲
Also, it has been identified that managing the trade-off between resource usage and scalability may incur uselessly sending traffic to some PEs participating in a multicast VPN. For this reason, a multicast VPN solution MAY permit that the bandwidth/state tuning take into account the relative cost or availability of bandwidth toward each PE. 💜
5.2.4. Tunneling Requirements
5.2.4.1. Tunneling Technologies
Following the principle of separation between the control plane and the forwarding plane, a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent: the control plane SHALL NOT depend on which forwarding plane is used (and vice versa), and the choice of forwarding plane SHOULD NOT be limited by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology. The planes stay separate, no drama 🫶
In a multicast VPN solution extending a unicast L3 PPVPN solution, consistency in the tunneling technology has to be favored: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast. Deployment consistency, ease of operation, and potential migrations are the main motivations behind this requirement. Same tech, less chaos 🎀
For MDTunnels, a solution SHOULD be able to use a range of tunneling technologies, including point-to-point and point-to-multipoint, such as:
- Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in multicast IP trees),
- MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP extensions to the Resource Reservation Protocol (RSVP) [P2MP-RSVP-TE] or Label Distribution Protocol (LDP) [P2MP-LDP-REQS] [P2MP-LDP]),
- Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast [RFC4045]),
- IPsec [RFC4031]
- IP-in-IP [RFC2003], etc.
Naturally, it is RECOMMENDED that a solution is built so that it can leverage the point-to-multipoint variants of these techniques. These variants allow for packet replications to happen along a tree in the provider core network, and they may help improve bandwidth efficiency in a multicast VPN context. Replication on the tree, aka the glow-up we want 🌳✨
5.2.4.2. MTU and Fragmentation
A solution SHOULD support a method that provides the minimum MTU of the MDTunnel (e.g., to discover MTU, to communicate MTU via signaling, etc.) so that:
- fragmentation inside the MDTunnel does not happen, even when allowed by the underlying tunneling technology
- proper troubleshooting can be performed if packets that are too big for the MDTunnel happen to be encapsulated in the MDTunnel
5.2.5. Control Mechanisms
The solution MUST provide some mechanisms to control the sources within a VPN. 🚦 This control includes the number of sources that are entitled to send traffic on the VPN, and/or the total bit rate of all the sources.
At the reception level, the solution MUST also provide mechanisms to control the number of multicast groups or channels VPN users are entitled to subscribe to and/or the total bit rate represented by the corresponding multicast traffic. Gatekeeping for the win 👑
All these mechanisms MUST be configurable by the service provider in order to control the amount of multicast traffic and state within a VPN. Total control, periodt 💅
Moreover, it MAY be desirable to be able to impose some bound on the quantity of state used by a VPN in the core network for its multicast traffic, whether on each P or PE router, or globally. The motivation is that it may be needed to avoid out-of-resources situations (e.g., out of memory to maintain PIM state if IP multicast is used in the core for multicast VPN traffic, or out of memory to maintain RSVP state if MPLS P2MP is used, etc.). Nobody wants their router running out of memory mid-stream 😭
5.2.6. Support of Inter-AS, Inter-Provider Deployments
A solution MUST support inter-AS (Autonomous System) multicast VPNs, and SHOULD support inter-provider multicast VPNs. Considerations about coexistence with unicast inter-AS VPN Options A, B, and C (as described in Section 10 of [RFC4364]) are strongly encouraged. 🌈
A multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers, and keep the need for detailed knowledge of providers' networks to a minimum -- all this being in comparison with corresponding unicast VPN options. Less group chat drama between providers, please 🙏
- Within each service provider, the service provider SHOULD be able on its own to pick the most appropriate tunneling mechanism to carry (multicast) traffic among PEs (just like what is done today for unicast)
- If a solution does require a single tunnel to span P routers in multiple ASs, the solution SHOULD provide mechanisms to ensure that the inter-provider coordination to set up such a tunnel is minimized
Moreover, such support SHOULD be possible without compromising other requirements expressed in this requirement document, and SHALL NOT incur penalties on scalability and bandwidth-related efficiency. No sacrificing scalability for the sake of it, iconic behavior only 👑
5.2.7. Quality-of-Service Differentiation
A multicast VPN solution SHOULD give a VPN service provider the ability to offer, guarantee and enforce differentiated levels of QoS for its different customers. VIP treatment for every customer, slay 🍓
5.2.8. Infrastructure security
The solution SHOULD provide the same level of security for the service provider as what currently exists for unicast VPNs (for instance, as developed in the Security sections of [RFC4364] and [VRs]). For instance, traffic segregation and intrinsic protection against DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks of the BGP/MPLS VPN solution must be supported by the multicast solution. Security is not optional here, bestie 🔥
Moreover, since multicast traffic and routing are intrinsically dynamic (receiver-initiated), some mechanism SHOULD be proposed so that the frequency of changes in the way client traffic is carried over the core can be bounded and not tightly coupled to dynamic changes of multicast traffic in the customer network. For example, multicast route dampening functions would be one possible mechanism. Calming down the flapping, very healthy behavior 🦋
Network devices that participate in the deployment and the maintenance of a given L3VPN MAY represent a superset of the participating devices that are also involved in the establishment and maintenance of the multicast distribution tunnels. As such, the activation of IP multicast capabilities within a VPN SHOULD be device-specific, not only to make sure that only the relevant devices will be multicast-enabled, but also to make sure that multicast (routing) information will be disseminated to the multicast-enabled devices only, hence limiting the risk of multicast-inferred DOS attacks. Only the right devices get the invite 🚫
Traffic of a multicast channel for which there are no members in a given multicast VPN MUST NOT be propagated within the multicast VPN, most particularly if the traffic comes from another VPN or from the Internet. No uninvited traffic at the party, ever 🙅♀️
Security considerations are particularly important for inter-AS and inter-provider deployments. In such cases, it is RECOMMENDED that a multicast VPN solution support means to ensure the integrity and authenticity of multicast-related exchanges across inter-AS or inter-provider borders. It is RECOMMENDED that corresponding procedures require the least possible coordination between providers; more precisely, when specific configurations or cryptographic keys have to be deployed, this shall be limited to ASBRs (Autonomous System Border Routers) or a subset of them, and optionally BGP Route Reflectors (or a subset of them). Keep the keys close and the borders tight 🔐
Lastly, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view. 🧚
5.2.9. Robustness
Resiliency is also crucial to infrastructure security; thus, a multicast VPN solution SHOULD either avoid single points of failures or propose some technical solution making it possible to implement a fail-over mechanism. No single point of failure is giving "one bad day ruins everything" energy 😭
As an illustration, one can consider the case of a solution that would use PIM-SM as a means to set up MDTunnels. In such a case, the PIM RP might be a single point of failure. Such a solution SHOULD be compatible with a solution implementing RP resiliency, such as anycast-RP [RFC4610] or BSR [PIM-BSR]. The RP is the main character with the biggest risk, so backup plans are a must 🌸
5.2.10. Operation, Administration, and Maintenance 🛠️✨
Okay bestie, the vibe for running a multicast VPN is keep it light 🫶. The operation of a multicast VPN solution SHALL be as light as possible, and automatic configuration and discovery SHOULD be a priority when you're designing one 💅. Especially, the operational burden of setting up multicast on a PE or for a VR/VRF SHOULD be as low as possible 🧚.
Also, as far as possible, the design of a solution SHOULD carefully consider how many protocols live in the core network 🌸. If any extra protocols get added compared with the unicast VPN service, the balance between their advantage and their operational burden SHOULD be examined thoroughly 🔍. No one wants a protocol pile-up, periodt.
Moreover, monitoring of multicast-specific parameters and statistics SHOULD be offered to the service provider, following the requirements expressed in [RFC4176] 📊.
Most notably, the provider SHOULD have access to:
- Multicast traffic statistics (incoming/outgoing/dropped/total traffic conveyed, by period of time)
- Information about client multicast resource usage (multicast routing state and bandwidth usage)
- Alarms when limits are reached on such resources
- The IPPM (IP Performance Metrics [RFC2330])-related information that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc.
- Statistics on decisions related to how client traffic is carried on distribution tunnels (e.g., "traffic switched onto a multicast tree dedicated to such groups or channels")
- Statistics on parameters that could help the provider to evaluate its optimality/state trade-off
This information SHOULD be made available through standardized SMIv2 [RFC2578] Management Information Base (MIB) modules to be used with SNMP [RFC3411], or through IPFIX [IPFIX-PROT]. For instance, in the context of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs defined in [RFC4382] SHOULD be proposed, with proper integration with [RFC3811], [RFC3812], [RFC3813], and [RFC3814] when applicable 📚.
Mechanisms similar to those described in Section 5.2.12 SHOULD also exist for proactive monitoring of the MDTunnels 👀.
Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be scalable with respect to the parameters mentioned in Section 5.2.2. In particular, it is RECOMMENDED that particular attention is given to the impact of monitoring mechanisms on performance and QoS 💖.
Moreover, it is RECOMMENDED that any OAM mechanism designed to trigger alarms in relation to performance or resource usage metrics integrate the ability to limit the rate at which such alarms are generated (e.g., some form of a hysteresis mechanism based on low/high thresholds defined for the metrics). Basically, don't let your alarms spam the group chat 🔔🙈.
5.2.11. Compatibility and Migration Issues 🔄🌈
Big requirement alert 🚨: unicast and multicast services MUST be able to coexist within the same VPN. That's a must-have, not a nice-to-have.
Likewise, a multicast VPN solution SHOULD be designed so that its activation in devices that participate in the deployment and maintenance of a multicast VPN SHOULD be as smooth as possible, i.e., without affecting the overall quality of the services that are already supported by the underlying infrastructure 🧈✨.
A multicast VPN solution SHOULD prevent compatibility and migration issues, for instance, by focusing on providing mechanisms facilitating forward compatibility. Most notably, a solution supporting only a subset of the requirements expressed in this document SHOULD be designed to allow compatibility to be introduced in further revisions 🔮.
It SHOULD be an aim of any multicast VPN solution to offer as much backward compatibility as possible. Ideally, a solution would have the ability to offer multicast VPN services across a network containing some legacy routers that do not support any multicast VPN-specific features 🦖💕. Old routers deserve love too.
In any case, a solution SHOULD state a migration policy from possibly existing deployments 📝.
5.2.12. Troubleshooting 🕵️♀️🔍
A multicast VPN solution that dynamically adapts the way some client multicast traffic is carried over the provider's network may incur the disadvantage of being hard to troubleshoot. Honestly, that's giving mystery novel energy 😭. In such a case, to help diagnose multicast network issues, a multicast VPN solution SHOULD provide monitoring information describing how client traffic is carried over the network (e.g., if a solution uses multicast-based MDTunnels, which provider multicast group is used for a given client multicast stream). A solution MAY also provide configuration options to avoid any dynamic changes, for multicast traffic of a particular VPN or a particular multicast stream 🎀.
Moreover, a solution MAY provide mechanisms that allow network operators to check that all VPN sites that advertised interest in a particular customer multicast stream are properly associated with the corresponding MDTunnel. Providing operators with means to check the proper setup and operation of MDTunnels MAY also be provided (e.g., when P2MP MPLS is used for MDTunnels, troubleshooting functionalities SHOULD integrate mechanisms compliant with [RFC4687], such as LSP Ping [RFC4379][LSP-PING]). Depending on the implementation, such verification could be initiated by a source-PE or a receiver-PE 🧚♀️.
6. Security Considerations 🔐
This document does not by itself raise any particular security issue. Phew 🫠.
A set of security issues has been identified that MUST be addressed when considering the design and deployment of multicast-enabled L3 PPVPNs. Such issues have been described in Section 5.1.5 and Section 5.2.8. This is NOT a drill, bestie 🚨💀. Take these seriously.
7. Contributors 👑
The main contributors to this document are listed below, in alphabetical order 💜:
Christian Jacquenet
France Telecom
3, avenue Francois Chateau
CS 36901 35069 RENNES Cedex, France
Email: christian.jacquenet@orange-ftgroup.comYuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: y.kamite@ntt.comJean-Louis Le Roux
France Telecom R&D
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: jeanlouis.leroux@orange-ftgroup.comNicolai Leymann
Deutsch Telecom
Engineering Networks, Products & Services
Goslarer Ufer 3510589 Berlin, Germany
Email: nicolai.leymann@t-systems.comRenaud Moignard
France Telecom R&D
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: renaud.moignard@orange-ftgroup.comThomas Morin
France Telecom R&D
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: thomas.morin@orange-ftgroup.com8. Acknowledgments 🌷
The authors would like to thank, in rough chronological order, Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, valuable input, and feedback 🥰.
We also thank the people who kindly answered the survey, and Daniel King, who took care of gathering and anonymizing its results 🙌.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for
Layer 3 Provider-Provisioned Virtual Private
Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned
Virtual Private Network (VPN) Terminology",
RFC 4026, March 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
Kouvelas, "Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised)",
RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
for IP", RFC 4607, August 2006.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual
Private Networks (L3VPN) Operations and Management",
RFC 4176, October 2005.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised)", RFC 3973,
January 2005.9.2. Informative References ✨
okay bestie, this is the reading list 📚 these are the docs the spec leans on for context but doesn't require you to implement. the vibe is "go deeper if you're curious" 🧚
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 💜
- [VRs] Ould-Brahim, H., "Network based IP VPN Architecture Using Virtual Routers", Work in Progress, March 2006. 🌸
- [RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998. 🎀
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 🦋
- [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. 👑
- [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. 💅
- [P2MP-RSVP-TE] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", Work in Progress, August 2006. ✨
- [PIM-BSR] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006. 🍓
- [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. 🌈
- [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003. 🫶
- [P2MP-LDP] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, October 2006. 🔥
- [P2MP-LDP-REQS] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", Work in Progress, June 2006. 🧚
- [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. ⭐
- [BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005. 💖
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 🌸
- [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment", RFC 3353, August 2002. 🦋
- [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. 🎀
- [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 💜
- [IPFIX-PROT] Claise, B., "Specification of the IPFIX Protocol for the Exchange", Work in Progress, November 2006. 🍓
- [RFC4045] Bourdon, G., "Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)", RFC 4045, April 2005. 👑
- [RFC3809] Nagarajan, A., "Generic Requirements for Provider-Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. 🌈
- [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. ✨
- [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. 🫶
- [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. 🔥
- [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004. 🧚
- [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. 💅
- [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. 🍓
- [MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for spatial and multicast", Work in Progress, October 2006. 🌸
- [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. 🦋
- [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. 🎀
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 💜
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 🌈
- [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. ⭐
- [RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", RFC 4382, February 2006. 👑
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 🔥
- [LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol", Work in Progress, September 2006. 🫶
- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006. 🧚
Author's Address
Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France
EMail: thomas.morin@orange-ftgroup.com 💌
Full Copyright Statement
Copyright (C) The IETF Trust (2007). 🌸
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🎀
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🦋
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4834 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms