RFC 5501
Requirements for Multicast Support in Virtual Private LAN Services
RFC 5501: Requirements for Multicast Support in Virtual Private LAN Services 💖
Okay bestie, this is the RFC that says what multicast over VPLS needs to do, and it's written as a checklist of requirements 🎀. It's Informational, not a standard, and the date is March 2009 🌸.
The title block lists five authors, and Y. Kamite is the editor 🧚. The others are Y. Wada (NTT), Y. Serbest (AT&T), T. Morin (France Telecom), and L. Fang (Cisco Systems, Inc.) 👑. It has no Obsoletes or Updates entries 🦋.
Status of This Memo ✨
This memo gives info to the Internet community 🫶. It is not a standard of any kind, and anyone can share it freely with no limits 💅.
Copyright Notice 🌈
Copyright (c) 2009 IETF Trust and the document authors 🎀. All rights reserved 💜.
This doc is governed by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date 📜. Please read those carefully, because they spell out your rights and restrictions 🙈. They live at http://trustee.ietf.org/license-info.
Abstract 🦋
This document gives the functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS) 💖. It covers requirements from both the end user side and the service provider side 👑. The plan is that future solutions will treat these requirements as guidelines 🫶.
Table of Contents 📋
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Scope of This Document .....................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Conventions ................................................6
3. Problem Statements ..............................................6
3.1. Motivation .................................................6
3.2. Multicast Scalability ......................................7
3.3. Application Considerations .................................8
3.3.1. Two Perspectives of the Service .....................8
4. General Requirements ............................................9
4.1. Scope of Transport .........................................9
4.1.1. Traffic Types .......................................9
4.1.1.1. Multicast and Broadcast ....................9
4.1.1.2. Unknown Destination Unicast ................9
4.1.2. Multicast Packet Types ..............................9
4.1.3. MAC Learning Consideration .........................11
4.2. Static Solutions ..........................................11
4.3. Backward Compatibility ....................................11
5. Customer Requirements ..........................................12
5.1. CE-PE Protocol ............................................12
5.1.1. Layer-2 Aspect .....................................12
5.1.2. Layer-3 Aspect .....................................12
5.2. Multicast Domain ..........................................13
5.3. Quality of Service (QoS) ..................................14
5.4. SLA Parameters Measurement ................................14
5.5. Security ..................................................15
5.5.1. Isolation from Unicast .............................15
5.5.2. Access Control .....................................15
5.5.3. Policing and Shaping on Multicast ..................15
5.6. Access Connectivity .......................................15
5.7. Multi-Homing ..............................................15
5.8. Protection and Restoration ................................15
5.9. Minimum MTU ...............................................16
5.10. Frame Reordering Prevention ..............................16
5.11. Fate-Sharing between Unicast and Multicast ...............16
6. Service Provider Network Requirements ..........................18
6.1. Scalability ...............................................18
6.1.1. Trade-Off of Optimality and State Resource .........18
6.1.2. Key Metrics for Scalability ........................19
6.2. Tunneling Requirements ....................................20
6.2.1. Tunneling Technologies .............................20
6.2.2. MTU of MDTunnel ....................................20
6.3. Robustness ................................................20
6.4. Discovering Related Information ...........................21
6.5. Operation, Administration, and Maintenance ................21
6.5.1. Activation .........................................21
6.5.2. Testing ............................................22
6.5.3. Performance Management .............................22
6.5.4. Fault Management ...................................23
6.6. Security ..................................................24
6.6.1. Security Threat Analysis ...........................24
6.6.2. Security Requirements ..............................25
6.7. Hierarchical VPLS support .................................28
6.8. L2VPN Wholesale ...........................................28
7. Security Considerations ........................................28
8. Acknowledgments ................................................28
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................291. Introduction ✨
1.1. Background 🌸
VPLS (Virtual Private LAN Service) is a provider service that copies the full vibe of a traditional Local Area Network (LAN) 🧚. It links several customer LAN segments over a packet switched network (PSN) backbone, which makes a multipoint-to-multipoint Ethernet VPN 💜. For customers, all those remote LAN segments act like one single LAN 🫶.
In a VPLS, the provider network acts like a learning bridge, and forwarding happens based on Ethernet MAC (media access control) learning 🎀. So a VPLS needs MAC address learning and aging on a per-PW (pseudowire) basis, where forwarding decisions treat the PW as a "bridge port" 🔥.
VPLS is a Layer-2 (L2) service, but from the customer's side it does two jobs 👑:
- LAN Routing application: it connects customer routers 🌈
- LAN Switching application: it connects customer Ethernet switches 🍓
So customers across MAN/WAN sometimes get transparent Layer-2 connectivity, even though what they really want is to run Layer-3 apps inside their routing domain 💅. That means different requirements show up depending on all those different apps 💖.
At first, PEs (Provider Edges) in VPLS sent broadcast and multicast Ethernet frames by copying every multicast or broadcast frame that came in from an Attachment Circuit (AC) out to every PW that belongs to a particular Virtual Switching Instance (VSI) 😭. The big upside is that the P (Provider Router) and PE devices stay totally unaware of IP multicast-specific stuff 🌸. The downside, obviously, is that it eats a lot of bandwidth, and that means higher costs for large-scale deployments 💀.
Meanwhile, there's a growing need for multicast-based services like IP TV ⭐. That trend means most VPLS deployments have to handle multicast more efficiently than before 🦋. It's also needed because customer routers are now likely running IP multicast protocols, and they're plugged into switches that will be carrying huge amounts of multicast traffic 🔥.
So it's desirable to have more efficient techniques for supporting IP multicast over VPLS 👑💖.
1.2. Scope of This Document 🧚
This document gives the functional requirements for network solutions that support IP multicast in VPLS [RFC4761] [RFC4762] 🎀. It identifies requirements that MAY apply to the existing base VPLS architecture in order to optimize IP multicast 💜. It also complements the generic L2VPN requirements document [RFC4665] by specifying extra requirements for deploying IP multicast in VPLS 🫶.
The technical specs are out of scope here 🙈. There's no intent to specify solution-specific details or application-specific requirements 🌈. This document also does NOT aim to express multicast-inferred requirements that aren't specific to VPLS 💅. It does NOT aim to express any requirements for native Ethernet specifications either 🍓.
This document is proposed as a solution guideline and a checklist of requirements, which we'll use to evaluate how well each solution satisfies the requirements 🌸.
It clarifies the needs from both the VPLS customer and provider standpoints, and it lays out the problems that technical solutions should address, all while staying solution agnostic ✨.
A technical solution and its service that supports this document's requirements are called a "multicast VPLS" from here on 💖.
2. Conventions Used in This Document 📖
2.1. Terminology ✨
okay so before we get into the juicy stuff, the reader is expected to already know the terminology, reference models, and taxonomy from [RFC4664] and [RFC4665] 📚 bestie, we're repeating a few of the terms here anyway so nobody gets lost 🫶
Plus we're proposing some extra terms we need for the IP multicast in VPLS discussion, so let's go 💅
- ASM: Any Source Multicast 🌸 One of the two multicast service models, where each service can have an arbitrary number of senders. Main character energy, honestly 👑
- G: denotes a multicast group 🦋
- MDTunnel: Multicast Distribution Tunnel 🎀 This is the means by which the customer's multicast traffic gets carried across the Service Provider (SP) network. It's meant in a generic way, so these tunnels can be point-to-point, point-to-multipoint, or multipoint-to-multipoint. Now, this definition might seem to assume distribution tunnels are unidirectional, but the wording actually covers bidirectional tunnels too 🙈
- Multicast Channel: In the multicast SSM (Source Specific Multicast) model [RFC4607], a "multicast channel" is traffic from one specific source S to a multicast group G 💖 It's also called "(S,G)" ✨
- Multicast domain: An area where multicast data gets transmitted 🌈 In this document it's a generic term that can mean Layer-2 or Layer-3. Usually the Layer-3 multicast domain is set by the Layer-3 multicast protocol that establishes reachability between all the potential receivers in that domain. The Layer-2 multicast domain can match the Layer-2 broadcast domain (aka a VLAN), but it can also be smaller than that if an extra control protocol is used 🧚
- CE: Customer Edge Device 🍓
- PE: Provider Edge 🍓
- P: Provider Router 🍓
- S: denotes a multicast source 🦋
- SP: Service Provider 💅
- SSM: Source Specific Multicast 💜 The other multicast service model, where each service relies on a single source ✨
- U-PE/N-PE: The device closest to the customer/user is the User-facing PE (U-PE), and the device closest to the core network is the Network-facing PE (N-PE) 🫶
- VPLS instance: A service entity you can manage in the VPLS architecture 🌸 All the CE devices in a single VPLS instance look like they're on the same LAN, forming a VPN across the SP's network. A VPLS instance is a group of VSIs that are interconnected using PWs (pseudowires) 🎀
- VSI: Virtual Switching Instance 🦋 A VSI is a logical entity in a PE that maps multiple ACs (Attachment Circuits) to multiple PWs. It gets populated pretty much the way a standard bridge populates its forwarding table 🧠 Each PE can have multiple VSIs, and each VSI belongs to a different VPLS instance 👑
2.2. Conventions 🎀
ngl this part is super important 🙈 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 Statements 💖
3.1. Motivation 🌈
okay so today there are sooo many kinds of IP multicast services popping up 🦋 Over their Layer-2 VPN service, especially over VPLS, customers would often love to run their multicast apps to remote sites. And VPN service providers using an IP-based network expect this Layer-2 infrastructure to handle multicast data traffic efficiently 💅
BUT 😭 VPLS has a shortcoming when it comes to multicast scalability, and it comes from the replication mechanisms built into the original architecture (more on that below) 💀 So the main goal for solutions is to fix this issue partially or completely, and to find efficient ways to support IP multicast services over VPLS 🫶
3.2. Multicast Scalability ✨
In VPLS, replication happens at an ingress PE (in the hierarchical VPLS (H-VPLS) case, at the N-PE) when a CE sends (1) Broadcast, (2) Multicast, or (3) Unknown destination unicast. There are two well-known issues with this approach 🙈
Issue A: Replication to non-member site 🌸
Here's the tea: in cases (1) and (3), the upstream PE has to transmit packets to all of the downstream PEs that belong to the common VPLS instance. You cannot decrease the number of members, so this is basically an inevitable situation for most VPLS deployments 😭
In case (2), though, there's a real issue: multicast traffic gets sent to sites with no members 💀 This usually happens because the upstream PE doesn't keep downstream membership information. The upstream PE just floods frames to all downstream PEs, and the downstream PEs forward them to directly connected CEs. But those CEs might not be members of any multicast group at all 🙅 From the customer's perspective, this can squeeze their own resources with unnecessary traffic 📉 From the SP's perspective, they would not like wasteful over-provisioning to cover that traffic 💸
Issue B: Replication of PWs on shared physical path 🦋
In VPLS, a VSI for each VPLS instance acts like a logical emulated bridge that can carry Ethernet across the PSN backbone using PWs 🧚 In principle, PWs are designed for unicast traffic 💜
In all cases, (1), (2), and (3), Ethernet frames get replicated on one or more PWs that belong to that VSI 🌀 This replication is often inefficient for bandwidth usage if those PWs traverse shared physical links in the backbone 😩
Let's do an example 🍓 Say there are 20 remote PEs in a particular VPLS instance, and all the PWs happen to traverse the same link from one local PE to its next-hop P. In this case, even if a CE sends 50 Mbps to the local PE, the total bandwidth of that link will be to 1000 Mbps 😱
Also, while traditional 802.1D Ethernet switches replicate broadcast/multicast flows once at most per output interface, VPLS often needs to transmit one or more flows duplicated over the same output interface 🫠
From the customer's perspective there's no serious issue, because they don't know what happens in the core 🙈 But from the SP's perspective, unnecessary replication brings the risk of resource exhaustion as the number of PWs increases 🔥
In both Issues A and B, these undesirable situations will become obvious with the wide-spread use of IP multicast applications by customers 📈 Naturally, the problem gets more serious as the number of sites grows. In other words, there are real concerns about the scalability of multicast in VPLS today 😭
3.3. Application Considerations 💅
3.3.1. Two Perspectives of the Service 👑
When it comes to IP multicast over VPLS, there are two different aspects in terms of service provisioning 🌈 They're closely related to the functional requirements from two technical standpoints:
Layer-2 and Layer-3.
- Native Ethernet service aspect 🦋
This aspect mainly affects Ethernet network service operators. Their main interest is solving the issue that existing VPLS deployments cannot always handle multicast/broadcast frames efficiently 🎀
Today, wide-area Ethernet services are super popular, and VPLS can be used to provide wide-area LAN services 🌸 As customers start using all kinds of content distribution apps that use IP multicast (or other protocols that lead to multicast/broadcast in the Ethernet layer), the total amount of traffic is going to grow 📈 Also, Operations, Administration, and Management (OAM), security, and other related points for multicast from a Layer-2 view are important 🔐
In that situation, the native VPLS specification would not always be satisfactory if multicast traffic takes up more of the total resource utilization than before 😬 The scalability issues from the previous section are expected to be solved ✨
- IP multicast service aspect 🧚
This aspect mainly affects both IP service providers and end users 💖 Their main interest is providing IP multicast services transparently but effectively, using VPLS as the network infrastructure 💜
SPs might expect VPLS as an access/metro network to deliver multicast traffic (such as Triple-play (Video, Voice, Data) and Multicast IP VPNs) efficiently 📺✨
4. General Requirements 🫶
We assume the basic requirements for VPLS written in [RFC4665] are fulfilled, unless otherwise specified in this document 💅
4.1. Scope of Transport 🌸
4.1.1. Traffic Types 🦋
4.1.1.1. Multicast and Broadcast 🎀
As described before, any solution is expected to have mechanisms for efficient transport of IP multicast 💖 Multicast is related to both Issues A and B (see Section 3.2). Broadcast, though, is related to Issue B only, because it does not need membership control 🧠
- A multicast VPLS solution SHOULD attempt to solve both Issues A and B, if possible 🌈 However, since some applications prioritize solving one issue over the other, the solution MUST identify which Issue (A or B) it is attempting to solve 🙈 If the solution is providing an approximate solution, it SHOULD provide a basis for evaluating how well it solves the issue(s) it is targeting 📊
4.1.1.2. Unknown Destination Unicast 🧚
Unknown destination MAC unicast requires flooding, but its characteristics are quite different from multicast/broadcast 🌀 When the unicast MAC address is learned, the PE changes its forwarding behavior from flooding over all PWs into sending over one PW ✨ So it will need different technical studies from multicast/broadcast, which is out of scope for this document 💅
4.1.2. Multicast Packet Types ✨
okay so Ethernet multicast is how we carry Layer-3 multicast data 🦋. When an IP multicast packet gets wrapped in an Ethernet frame, the IP multicast group address gets mapped onto the Ethernet destination MAC address. For IPv4, the mapping takes the lower 23 bits of the 32-bit IPv4 multicast address and drops them into the lower 23 bits of a destination MAC address with the fixed header 01-00-5E in hex. ngl this mapping is kinda messy 💀. It's many-to-one (1 Ethernet address to 32 IPv4 addresses), so MAC-based forwarding isn't ideal for IP multicast. Some hosts might receive packets they never wanted, and that's inefficient for traffic delivery and has an impact on security 🙈. If the solution tracks IP addresses instead of MAC addresses, this concern can be prevented. The drawback is that the network administration gets slightly more complicated 🎀.
Ethernet multicast is also used for Layer-2 control frames 🧚. For example, the BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning Trees uses a multicast destination MAC address (01-80-C2-00-00-00). Some IEEE 802.1ag [802.1ag] Connectivity Fault Management (CFM) messages also use a multicast destination MAC address, depending on their message type and application. From the IP multicast perspective, though, it's necessary in VPLS to flood these control frames to all participating CEs, without requiring any membership controls 👑.
For a multicast VPLS solution, you can only use Ethernet-related information if you stick to the strict version of the basic requirement: "a L2VPN service SHOULD be agnostic to customer's Layer 3 traffic" [RFC4665]. That means no Layer-3 information should be checked for transport. But honestly, that's an impediment to solving Issue A 😭.
So a multicast VPLS can use some Layer-3-related supplementary information to improve transport efficiency. This is lowkey the move 💅. Today's LAN-switch implementations often do this, snooping upper-layer protocols and examining IP multicast memberships (e.g., Protocol Independent Multicast (PIM) snooping and IGMP/MLD (Multicast Listener Discovery) snooping [RFC4541]). That implicitly suggests VPLS may adopt similar techniques, although this document does NOT state Layer-3 snooping is mandatory. If that approach is taken, careful consideration of Layer-3 state maintenance is necessary 🌸. Also, snooping sometimes hurts the system's transparency. One protocol's snooping solution might hinder other (especially future) protocols, like an IGMPv2-snooping switch vs. a new IGMPv3-snooping one. Here are the potential alternatives to snooping:
- Static configuration of multicast Ethernet addresses and ports/interfaces.
- Multicast control protocol based on Layer-2 technology that signals mappings of multicast addresses to ports/interfaces, such as Generic Attribute Registration Protocol / GARP Multicast Registration Protocol (GARP/GMRP) [802.1D], Cisco Group Management Protocol [CGMP], and Router-port Group Management Protocol (RGMP) [RFC3488].
Based on all of that, here are the general requirements about packet types 🦋:
- A solution SHOULD support a way to facilitate IP multicast forwarding of the customers. It MAY observe Layer-3 information (i.e., multicast routing protocols and state) to the degree necessary, but any information irrelevant to multicast transport SHOULD NOT be consulted.
- In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) SHOULD be flooded to all PE/CEs in a common VPLS instance. A solution SHOULD NOT change or limit the flooding scope to remote PE/CEs in terms of end-point reachability.
- In a solution, Layer-2 frames that encapsulate Layer-3 multicast control packets (e.g., PIM, IGMP (for IPv4), and MLD (for IPv6)) MAY be flooded only to relevant members, with the goal of limiting flooding scope. However, Layer-2 frames that encapsulate other Layer-3 control packets (e.g., OSPF, IS-IS) SHOULD be flooded to all PE/CEs in a VPLS instance.
4.1.3. MAC Learning Consideration 🌈
In a common VPLS architecture, PEs do MAC learning based on the incoming frame's source MAC address, independently of the destination MAC address. That means it works the same whether the destination is unicast, multicast, or broadcast 🫶. The multicast VPLS solution's environment works this way too. Improving MAC learning scalability is beyond the scope of this document, and it will be covered in future work ⭐.
4.2. Static Solutions 🍓
A solution SHOULD allow static configuration to account for various operator policies, for cases where the logical multicast topology does not change dynamically in conjunction with a customer's multicast routing 🎀.
4.3. Backward Compatibility 💜
A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is made up of both PEs that support the solution and PEs that don't, with the multicast optimization (both forwarding and receiving) achieved between the compliant PEs 🦋.
Note again that the existing VPLS solutions already have a simple flooding capability. So this backward compatibility gives customers and SPs the improved efficiency of multicast forwarding incrementally, as the solution gets deployed 🌸.
5. Customer Requirements 👑
5.1. CE-PE Protocol 💅
5.1.1. Layer-2 Aspect ✨
A solution SHOULD allow transparent operation of Ethernet control protocols employed by customers (e.g., Spanning Tree Protocol [802.1D]), and their seamless operation with multicast data transport 🧚.
Solutions MAY examine Ethernet multicast control frames for the purpose of efficient dynamic transport (e.g., GARP/GMRP [802.1D]). However, solutions MUST NOT assume all CEs are always running such protocols. This is typically the case where a CE is a router and isn't aware of Layer-2 details 🙈.
A whole Layer-2 multicast frame (whether for data or control) SHOULD NOT be altered from a CE to CE(s) EXCEPT for the VLAN ID field, so that it's transparently transported 🫶. If VLAN IDs are assigned by the SP, they can be altered. Note, however, that when VLAN IDs are changed, Layer-2 protocols may break in some cases, such as Multiple Spanning Trees [802.1s] 💀. Also, if the Layer-2 frame is encapsulating a Layer-3 multicast control packet (e.g., PIM/IGMP) and customers allow it to be regenerated at the PE (aka proxy: see Section 5.1.2), then the MAC address for that frame MAY be altered to the minimum necessary (e.g., use the PE's own MAC address as a source) 🦋.
5.1.2. Layer-3 Aspect 🌸
Again, a solution MAY examine the customer's Layer-3 multicast protocol packets for the purpose of efficient and dynamic transport. If it does, the supported protocols SHOULD include:
- PIM-SM (Sparse Mode) [RFC4601], PIM-SSM (Source-Specific Multicast) [RFC4607], bidirectional PIM [RFC5015], and PIM-DM (Dense Mode) [RFC3973].
- IGMP (v1 [RFC1112], v2 [RFC2236], and v3 [RFC3376]) (for IPv4 solutions).
- Multicast Listener Discovery Protocol (MLD) (v1 [RFC2710] and v2 [RFC3810]) (for IPv6 solutions).
A solution MUST NOT require any special Layer-3 multicast protocol packet processing by the end users. However, it MAY require some configuration changes (e.g., turning explicit tracking on/off in the PIM) 💖.
A whole Layer-3 multicast packet (whether for data or control), which is encapsulated inside a Layer-2 frame, SHOULD NOT be altered from a CE to CE(s), so that it's transparently transported 🧚. However, for Layer-3 multicast control (like PIM Join/Prune/Hello and IGMP Query/Report packets), it MAY be altered to the minimum necessary if that partial non-transparency is acceptable from the point of view of the multicast service. Similarly, a PE MAY consume such Layer-3 multicast control packets and regenerate an entirely new packet, if partial non-transparency is acceptable with legitimate reason for customers (aka proxy) ✨.
5.2. Multicast Domain 🎀
As noted in Section 2.1, the term "multicast domain" is used in a generic context for Layer-2 and Layer-3 🦋.
A solution SHOULD NOT alter the boundaries of customer multicast domains. It MUST ensure that the provided Ethernet multicast domain always encompasses the corresponding customer Layer-3 multicast domain 👑.
A solution SHOULD optimize those domains' coverage sizes. In other words, a solution SHOULD ensure that unnecessary traffic is not sent to CEs with no members 💅. Ideally, the provided domain size will be close to that of the customer's Layer-3 multicast membership distribution. However, it is OPTIONAL to achieve that absolute optimality from the perspective of Layer-3 🌈.
If a customer uses VLANs and a VLAN ID as a service delimiter (i.e., each VPLS instance is represented by a unique customer VLAN tag carried by a frame through the User Network Interface (UNI) port), a solution MUST provide a separate multicast domain for each VLAN ID. Note that if VLAN ID translation is provided (i.e., if a customer VLAN at one site is mapped into a different customer VLAN at a different site), multicast domains will be created per set of VLAN IDs that are associated with translation 🙈.
If a customer uses VLANs but a VLAN ID is not a service delimiter (i.e., the VPN disregards customer VLAN IDs), a solution MAY provide a separate multicast domain for each VLAN ID. An SP is not mandatorily required to provide a separate multicast domain for each VLAN ID, but it may be considered beneficial to do so 🌸.
A solution MAY build multicast domains based on Ethernet MAC addresses. It MAY also build multicast domains based on the IP addresses inside Ethernet frames. That is, PEs in each VPLS instance might control forwarding behavior and provide different multicast frame reachability depending on each MAC/IP destination address separately. If IP multicast channels are fully considered in a solution, the provided domain size will be closer to actual channel reachability 🧚.
5.3. Quality of Service (QoS) 💖
Customers require that multicast quality of service MUST be at least on par with what exists for unicast traffic 🔥. Moreover, as multicast is often used to deliver high-quality services such as TV broadcast, delay-, jitter-, and loss-sensitive traffic MUST be supported over multicast VPLS 📺.
To accomplish this, the solution MAY have additional features to support high QoS, such as bandwidth reservation and flow admission control. Also, multicast VPLS deployment SHALL benefit from IEEE 802.1p Class-of-Service (CoS) techniques [802.1D] and Diffserv [RFC2475] mechanisms ⭐.
Moreover, multicast traffic SHOULD NOT affect the QoS that unicast traffic receives, and vice versa. That is, separation of multicast and unicast traffic in terms of QoS is necessary 🫶.
5.4. SLA Parameters Measurement ✨
okay so SLA parameters are part of the service customers actually buy 💅 which means they just want to check how their apps are doing by measuring the numbers SP(s) promise them 📊
multicast-specific stuff you can keep an eye on includes multicast statistics per stream (like total, incoming, outgoing, and dropped traffic over a period of time) 📈, one-way delay, jitter, and group join/leave delay (how long it takes to start receiving traffic from a multicast group across the VPN after the join or leave was issued) ⏱️. an operator might also want to compare the one-way delay for one multicast group or stream going from a single source PE to multiple receiver PEs 👀
a solution SHOULD give you these parameters with Ethernet multicast group level granularity 🎀 (for example, a multicast MAC address is one of the entries used to classify flows for statistics, delay, and so on). however, if a solution is aimed at IP multicast transport efficiency, it MAY support IP multicast-level granularity 🌸
(for example, a multicast IP address/channel will be the entries for latency time 🧚)
to actually monitor all this, standard interfaces for statistics gathering SHOULD also be provided (e.g., standard Simple Network Management Protocol (SNMP) MIB Modules) 📡
5.5. Security 🔐
a solution MUST give customers architectures that provide the same level of security for both unicast and multicast 🫶
5.5.1. Isolation from Unicast
solutions SHOULD NOT affect any forwarding information base, throughput, or resiliency, etc., of unicast frames 🙅♀️ so basically, they SHOULD provide isolation from unicast 🦋
5.5.2. Access Control
a solution MAY filter multicast traffic inside a VPLS, upon the request of an individual customer (for example, MAC/VLAN filtering, IP multicast channel filtering, etc.) 🚧
5.5.3. Policing and Shaping on Multicast
a solution SHOULD support policing and shaping multicast traffic on a per-customer basis and on a per-AC (Attachment Circuit) basis 💜 this is meant to stop multicast traffic from eating up all the resources for unicast inside a common customer's VPN 🍽️ it might also be beneficial for QoS separation (see Section 5.3) ✨
5.6. Access Connectivity 🔌
first and foremost, the various physical connectivity types described in [RFC4665] MUST be supported 💖
5.7. Multi-Homing 🏠
a multicast VPLS MUST allow a situation where a CE is dual-homed to two different SPs via diverse access networks 👯 one of those SPs supports multicast VPLS, but the other one does not (because it is an existing VPLS or 802.1Q/QinQ network) 🙃
5.8. Protection and Restoration 🛟
a multicast VPLS infrastructure SHOULD allow redundant paths to keep things highly available 🌈
multicast forwarding restoration time MUST NOT be greater than the time it takes a customer's Layer-3 multicast protocols to detect a failure in the VPLS infrastructure ⏳ for example, if a customer uses PIM with default configuration, the hello hold timer is 105 seconds, and solutions are required to restore a failure no later than this period 😤 to pull that off, a solution might need to support providing alternative multicast paths 🛤️
also, if multicast forwarding was not successfully restored (e.g., in the case of no redundant paths), a solution MAY raise alarms to give customers outage notification before that hold timer expires 🚨
5.9. Minimum MTU 📦
multicast applications are often sensitive to packet fragmentation and reassembly, so the requirement to avoid fragmentation might be stronger than it is for the existing VPLS solution 🙈
a solution SHOULD give customers enough committed minimum MTU (i.e., service MTU) for multicast Ethernet frames so that IP fragmentation between customer sites never occurs 🍓 it MAY give multicast and unicast different MTU sizes 🎀
5.10. Frame Reordering Prevention 🔀
a solution SHOULD try to prevent frame reordering when it delivers customer multicast traffic 💅 likewise, for unicast and unknown unicast traffic, it SHOULD attempt not to increase the likelihood of reordering compared with existing VPLS solutions 🫧
okay but it's worth noting that delivering out-of-order frames can't be avoided in certain cases 😭 specifically, if a solution adopts some MDTunnels (see Section 6.2) and dynamically selects them for optimized delivery (e.g., switching from one aggregate tree to another), end-to-end data delivery is prone to arriving out of order 🌀 this is kind of a trade-off between bandwidth optimization and network stability ⚖️ so a solution like that is expected to promote awareness of this drawback 📣
5.11. Fate-Sharing between Unicast and Multicast 💞
in native Ethernet, multicast and unicast connectivity are often managed together 🤝 for instance, an 802.1ag CFM Continuity Check message is forwarded by multicast as a periodic heartbeat, but it is supposed to check the "whole" traffic continuity, regardless of unicast or multicast, at the same time 💓 so the aliveness of unicast and multicast is naturally coupled (i.e., fate-shared) in this customer's environment 🔗
a multicast VPLS solution may decouple the path that a customer's unicast and multicast traffic follow through an SP's backbone, so that multicast data traffic gets the most optimal path 🛣️ this may worry some multicast VPLS customers who want both unicast and multicast traffic to fail at the same time during a failure in the SP's network 😬
so there will be an additional requirement that couples unicast and multicast connectivity 💕 this means that if either one of them has a failure, the other is also disabled 💔 and if one of the services (either unicast or multicast) becomes operational, the other is also activated at the same time ✅
- it SHOULD be identified whether the solution can give customers fate-sharing between unicast and multicast connectivity for their LAN switching application 🧐 it MAY have a configurable mechanism for SPs to provide that on behalf of customers (e.g., aliveness synchronization), but its use is OPTIONAL 🌟
this policy benefits customers 🫶 some customers want to detect failure quickly at the CE side and restore full connectivity by switching over to their backup line, instead of keeping a half-broken connection (where either unicast or multicast is down) 🥲 even if one of them is still alive, it's just bad for customer application protocols that need both types of traffic 🙅 fate-sharing helps prevent that messy situation ✨
how serious this issue is depends on each customer's stance on Ethernet operation 🤔 if all CEs are IP routers (i.e., VPLS is provided for a LAN routing application), the customer might not care, because both unicast and multicast connectivity are assured at the IP layer 🧠 if the CE routers run an IGP (e.g., OSPF/IS-IS) and a multicast routing protocol (e.g., PIM), then the CEs will detect the aliveness of both the unicast and multicast paths 👀 this does not guarantee that unicast and multicast traffic follow the same path in the SP's backbone network, but it does mitigate the issue to some degree 💅
6. Service Provider Network Requirements 👑
6.1. Scalability 📈
the existing VPLS architecture has major advantages in scalability 💪 for example, P-routers are free from maintaining customers' information, because customer traffic is encapsulated in PSN tunnels 📦 also, a PW's split-horizon technique can prevent loops, which means PE routers are free from maintaining complicated spanning trees 🧚♀️
however, a multicast VPLS needs additional scalability considerations related to its expected enhanced mechanisms 🤓 [RFC3809] lists common L2VPN sizing and scalability requirements and metrics, which are applicable in multicast VPLS too 📋 so this section deals with the specific requirements related to scalability 🫧
6.1.1. Trade-Off of Optimality and State Resource
a solution needs to improve the scalability of multicast as shown in Section 3 🔍
Issue A: Replication to non-member site.
Issue B: Replication of PWs on shared physical path.
for both issues, optimizing physical resources (i.e., link bandwidth usage and router duplication performance) will become a major goal 🎯 however, there's a trade-off between optimality and state resource consumption 😵💫
to solve Issue A, a PE might have to maintain multicast group information for CEs that was not kept in the existing VPLS solutions 🗂️ this will present scalability concerns about state resources (memory, CPU, etc.) and their maintenance complexity 🥴
to solve Issue B, PE and P routers might have to know additional membership information for remote PEs, and possibly additional tree topology information, when they use point-to-multipoint (P2MP) techniques (PIM tree, P2MP-LSP (Label Switched Path), etc.) 🌳
so the scalability evaluation of multicast VPLS solutions needs a careful trade-off analysis between bandwidth optimality and state resource consumption 🧮✨
6.1.2. Key Metrics for Scalability 🔑
(Note: This part has a number of similar characteristics to requirements for Layer-3 Multicast VPN [RFC4834].)
a multicast VPLS solution MUST be designed to scale well as any of the following metrics increases 📊
- the number of PEs
- the number of VPLS instances (total and per PE)
- the number of PEs and sites in any VPLS instance
- the number of client VLAN IDs
- the number of client Layer-2 MAC multicast groups
- the number of client Layer-3 multicast channels (groups or source-groups)
- the number of PWs and PSN Tunnels (MDTunnels) (total and per PE)
each multicast VPLS solution SHALL document its scalability characteristics in quantitative terms 📝 a solution SHOULD quantify the amount of state that a PE and a P device has to support 🧾
the scalability characteristics SHOULD include:
- the processing resources required by the control plane in managing PWs (neighborhood or session maintenance messages, keepalives, timers, etc.)
- the processing resources required by the control plane in managing PSN tunnels
- the memory resources needed for the control plane
- the amount of protocol information transmitted to manage a multicast VPLS (e.g., signaling throughput)
- the amount of Layer-2/Layer-3 multicast information a P/PE router consumes (e.g., traffic rate of join/leave, keepalives, etc.)
- 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
another metric for scalability is operational complexity 🧩 operations naturally get more complicated if the number of managed objects (e.g., multicast groups) increases, or if topology changes occur more frequently 🌪️ a solution SHOULD note the factors that lead to additional operational complexity 📌
6.2. Tunneling Requirements 🚇
6.2.1. Tunneling Technologies 🎀
okay so an MDTunnel is a multicast distribution tunnel 🦋 It's a generic term for tunneling where customer multicast traffic gets carried over a provider's network. In the L2VPN service context, it corresponds to a PSN tunnel ✨
A solution SHOULD be able to use a range of tunneling technologies, including point-to-point (unicast oriented) and point-to-multipoint/multipoint-to-multipoint (multicast oriented). For example, there are so many tunneling protocols out there it's unreal: L2TP, IP (including multicast IP trees), MPLS (including P2MP-LSP [RFC4875], and P2MP/MP2MP-LSP [LDP-P2MP]), etc. 💅
Which variant gets used (point-to-point, point-to-multipoint, or multipoint-to-multipoint) depends largely on the trade-offs mentioned above and the targeted network and applications 🌸 So this document does not mandate any specific protocols. A solution, however, SHOULD state reasonable criteria if it adopts a specific kind of tunneling protocol 🫶
6.2.2. MTU of MDTunnel 📏
From an SP's point of view, it is not acceptable to have fragmentation/reassembly so often while packets are traversing an MDTunnel 😭 Therefore, a solution SHOULD support a method that provides the minimum path MTU of the MDTunnel in order to accommodate the service MTU.
6.3. Robustness 💜
Multicast VPLS solutions SHOULD avoid single points of failures or propose technical solutions that make it possible to implement a failover mechanism.
6.4. Discovering Related Information 🔍
The operation of a multicast VPLS solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be considered a high priority.
Therefore, in addition to the L2VPN discovery requirements in [RFC4665], a multicast VPLS solution SHOULD provide a method that dynamically allows multicast membership information to be discovered by PEs if the solution supports (A), as defined in Section 3.2. This means a PE needs to discover multicast membership (e.g., join group addresses) that is controlled dynamically from the sites connected to that PE. A PE also needs to discover such information automatically from other remote PEs in order to limit flooding scope across the backbone 🧚
6.5. Operation, Administration, and Maintenance 🛠️
6.5.1. Activation ⚡
The activation of multicast enhancement in a solution MUST be possible:
- with a VPLS instance granularity.
- with an Attachment Circuit granularity (i.e., with a PE-CE Ethernet port granularity, or with a VLAN ID granularity when it is a service delimiter).
Also it SHOULD be possible:
- with a CE granularity (when multiple CEs of the same VPN are associated with a common VPLS instance).
- with a distinction between multicast reception and emission.
- with a multicast MAC address granularity.
- with a customer IP multicast group and/or channel granularity (when Layer-3 information is consulted).
Also it MAY be possible:
- with a VLAN ID granularity when it is not a service delimiter.
6.5.2. Testing 🧪
A solution MUST provide a mechanism for testing multicast data connectivity and verifying the associated information. Examples that SHOULD be supported that are specific to multicast are:
- Testing connectivity per multicast MAC address
- Testing connectivity per multicast Layer-3 group/channel
- Verifying data plane and control plane integrity (e.g., PW, MDTunnel)
- Verifying multicast membership-relevant information (e.g., multicast MAC-addresses/PW-ports associations, Layer-3 group associations)
Operators usually want to check that an end-to-end multicast user's connectivity is OK before and after activation 👀 Such end-to-end multicast connectivity checking SHOULD enable the end-to-end testing of the data path used by that customer's multicast data packets. Specifically, end-to-end checking will have a CE-to-CE path test and a PE-to-PE path test. A solution MUST support the PE-to-PE path test and MAY support the CE-to-CE path test.
Operators will also want a testing mechanism for diagnosis and troubleshooting 🔧 In particular, a solution SHOULD be able to monitor information describing how client multicast traffic is carried over the SP network. Note that if a solution supports frequent dynamic membership changes with optimized transport, troubleshooting within the SP's network will tend to be difficult 😩
6.5.3. Performance Management 📊
Mechanisms to monitor multicast-specific parameters and statistics MUST be offered to the SP.
(Note: This part has a number of similar characteristics to requirements for Layer 3 Multicast VPN [RFC4834].)
A solution MUST provide SPs with access to:
- Multicast traffic statistics (total traffic forwarded, incoming, outgoing, dropped, etc., by period of time).
A solution SHOULD provide access to:
- Information about a customer's multicast resource usage (the amount of multicast state and throughput).
- Performance information related to multicast traffic usage, e.g., one-way delay, jitter, loss, delay variations (the difference in one-way delay for a solitary multicast group/stream from a single, source PE to multiple receiver PEs), etc.
- Alarms when limits are reached on such resources.
- Statistics on decisions related to how client traffic is carried on MDTunnels (e.g., "How much traffic was 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.
All or part of this information SHOULD be made available through standardized SNMP MIB Modules (Management Information Base) 📚
6.5.4. Fault Management 🚨
A multicast VPLS solution needs to consider the management steps taken by SPs below:
- Fault detection 🕵️
A solution MUST provide tools that detect group membership/reachability failure and traffic looping for multicast transport. It is anticipated that such tools are coordinated with the testing mechanisms mentioned in Section 6.5.2.
In particular, such mechanisms SHOULD be able to detect a multicast failure quickly, (on par with unicast cases). It SHOULD also avoid situations where multicast traffic has been in a failure state for a relatively long time while unicast traffic remains operational. If such a situation were to occur, it would end up causing problems with customer applications that depend on a combination of unicast and multicast forwarding.
With multicast, there may be many receivers associated with a particular multicast stream/group. As the number of receivers increases, the number of places (typically nearest the receivers) required to detect a fault will increase proportionately. This raises concerns over the scalability of fault detection in large multicast deployments. Consequently, a fault detection solution SHOULD scale well; in particular, a solution should consider key metrics for scalability as described in Section 6.1.2.
- Fault notification 📣
A solution MUST also provide fault notification and trouble tracking mechanisms (e.g., SNMP-trap and syslog).
In the case of multicast, one point of failure often affects a number of downstream routers/receivers that might be able to raise a notification. Hence, notification messages MAY be summarized or compressed for operators' ease of management.
- Fault isolation 🔬
A solution MUST provide diagnostic/troubleshooting tools for multicast as well. Also, it is anticipated that such tools are coordinated with the testing mechanisms mentioned in Section 6.5.2.
In particular, a solution needs to correctly identify the area inside a multicast group impacted by the failure. A solution SHOULD be able to diagnose if an entire multicast group is faulty or if some specific destinations are still alive.
6.6. Security 🔐
6.6.1. Security Threat Analysis 🚫
In multicast VPLS, there is a concern that one or more customer nodes (presumably untrusted) might cause multicast-related attacks on the SP network. There is a danger that it might compromise some components that belong to the whole system. Yikes 😱
This subsection states possible security threats relevant to the system and whether or not they are protected against.
General security considerations for a base VPLS (as part of L2VPNs) are referred to in [RFC4665]. The following is the threat analysis list that is inherent to multicast VPLS.
(a) Attack by a huge amount of multicast control packets.
There is a threat that a CE joins too many multicast groups and causes Denial of Service (DoS). This is caused by sending a large number of join/prune messages in a short time and/or putting a large variety of group addresses in join/prune messages. This attack will waste PE's control resources (e.g., CPU, memory) that examine customer control messages (for solving Issue A in Section 3.2), and it will not continue expected services for other trusted customers.
(b) Attack by invalid/malformed multicast control packets.
There is a threat that a CE sends invalid or malformed control packets that might corrupt a PE, which will cause a DoS attack. In particular, a CE might be spoofing legitimate source/group IP multicast addresses in such control packets (in PIM, IGMP, etc.) and source/destination MAC addresses as Layer-2 frames.
(c) Attack by rapid state change of multicast.
If a malicious CE changes multicast state by sending control packets in an extremely short period, this might affect the PE's control resources (e.g., CPU, memory) as it tries to follow such state changes. Besides, it might also affect the PE/P's control resources if an MDTunnel inside the core is dynamically created in conjunction with the customer's multicast group.
(d) Attack by high volume of multicast/broadcast data traffic.
A malicious CE might send a very high volume of multicast and/or broadcast data to a PE. If that PE does not provide any safeguards, it will cause excessive replication in the SP network, and the bandwidth resources for other trusted customers might be exhausted. 💀
(e) Attack by high volume of unknown destination unicast data traffic.
A malicious CE can send a high volume of unknown unicast to a PE. Generally, according to VPLS architecture, that PE must flood such unknown traffic to all corresponding PEs in the same VPN. A variety of unknown destinations and a huge amount of such frames might cause excess traffic in the SP network unless an appropriate safeguard is provided.
6.6.2. Security Requirements
okay so, the last subsection was all about the threats 😭 now we get the actual security requirements from the SP's point of view 💅 Based on that analysis, here's what the SP side needs:
An SP network MUST be invulnerable to malformed or maliciously constructed customer traffic 🛡️ This applies to both multicast data packets and multicast control packets.
Moreover, because multicast, broadcast, and unknown-unicast need more resources than unicast 📦 an SP network MUST have safeguards against unwanted or malicious multicast traffic. This applies to both multicast data packets and multicast control packets.
Specifically, a multicast VPLS solution SHOULD have mechanisms to protect an SP network from:
- (1) invalid multicast MAC addresses
- (2) invalid multicast IP addresses
- (3) malformed Ethernet multicast control protocol frames
- (4) malformed IP multicast control protocol packets
- (5) high volumes of
- valid/invalid customer control packets
- valid/invalid customer data packets (broadcast/multicast/unknown-unicast)
Depending on how a solution actually tackles Issue A, or B, or both (see Section 3.2.), some of those items matter more than others 🧐 First off, protection against (3) and (4) becomes significantly important if a solution supports solving Issue A, and PEs are processing customer's Ethernet/IP multicast control messages from CE. Moreover, protection against (2) should also get a lot of focus, because PIM/IGMP snooping will usually require that PE's data forwarding be based on IP addresses. By contrast, though, if a solution is solving only Issue B, not A, then PEs might never process the customer's multicast control messages at all 🙈 they do not perform IP address-based forwarding, but they do perform native Ethernet forwarding. If so, there is relatively less danger about (2), (3), and (4) compared to the first case.
Here are a few extra guidelines, in detail 📝
For protecting against threat (a), a solution SHOULD support imposing some bounds on the quantity of state used by a VPN to be imposed in order to prevent state resource exhaustion (i.e., lack of memory, CPU etc.) 🧠 In this case, the bounds MUST be configurable per VPN basis, not the total of various VPNs, so that SP can isolate the resource waste that is caused by any malicious customer.
For protecting against threat (d) and (e), a solution SHOULD support performing traffic policing to limit the unwanted data traffic shown above 🚦 In this case, while policing MAY be configurable to the sum of unicast, multicast, broadcast, and unknown unicast traffic, it SHOULD also be configurable to each such type of traffic individually, in order to prevent physical resource exhaustion (i.e., lack of bandwidth and degradation of throughput). If the policing limit is configured on total traffic only, there will be a concern that one customer's huge multicast might close other irrelevant unicast traffic 😤 If it can be configured individually, this concern will be avoided. Moreover, such a policing mechanism MUST be configurable per VPN basis, not the total of various VPNs, to isolate a malicious customer's traffic from others.
For protecting against threat (c), a solution SHOULD be able to limit frequent changes of group membership by customers 🔄 For example, PEs might support a dampening mechanism that throttles their multicast state changes if the customers are changing too excessively. Also, if MDTunnel is provided being tightly coupled to dynamic changes of customer's multicast domain, it is also effective to delay building the tunnel when customer's state is changed frequently.
Protecting against threat (b) might not be an easy task 😬 Generally, checking the legitimacy of a customer's IP multicast control packets will eventually require the authentication between PE and CE in Layer-3. However, L2VPN (including VPLS) by its nature does not usually assume a Layer-3-based security mechanism supported at the PE-CE level.
The ramification of this fact is that there remains a possibility that a PE's control plane might be badly affected by corrupted multicast control packets that the PE is examining 💀 Hence, each PE implementation will need to make an effort to minimize this impact from malicious customers and isolate it from other trusted customers as much as possible.
Nevertheless, it is possible to mitigate this threat to some degree 🫶 For example, a PE MAY support a filter mechanism about MAC and IP addresses in a Layer-2/Layer-3 header, and a filter mechanism about source/group addresses in the multicast join/prune messages. This will help a PE validate customers' control messages, to a certain extent.
6.7. Hierarchical VPLS support
A VPLS multicast solution SHOULD allow a hierarchical VPLS (H-VPLS) [RFC4762] service model 🌸 In other words, a solution is expected to operate seamlessly with existing hub and spoke PW connectivity.
Note that it is also important to take into account the case of redundant spoke connections between U-PEs and N-PEs ✨
6.8. L2VPN Wholesale
A solution MUST allow a situation where one SP is offering L2VPN services to another SP 👑 One example here is a wholesale model, where one VPLS interconnects other SPs' VPLS or 802.1D network islands. For customer SPs, their multicast forwarding can be optimized by making use of multicast VPLS in the wholesaler SP 🧚
7. Security Considerations
Security concerns and requirements for a base VPLS solution are described in [RFC4665] 🔐
In addition, there are security considerations specific to multicast VPLS. Thus, a set of security issues has been identified that MUST be addressed when considering the design and deployment of multicast VPLS 🚨 Such issues have been described in Sections 5.5 and 6.6.
In particular, security requirements from the view of customers are shown in Section 5.5. Security requirements from the view of providers are shown in Section 6.6. Section 6.6.1 conducts security threat analysis about the provider's whole system. Section 6.6.2 explains how each threat can be addressed or mitigated. This part is serious business, bestie 🫡
8. Acknowledgments
The authors thank the contributors of [RFC4834], since the structure and content of this document were, for some sections, largely inspired by [RFC4834] 🙌
The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach Kompella, Shane Amante, Ben Niven-Jenkins, and Venu Hemige for their valuable reviews and feedback 💖
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.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006.9.2. Informative References
[802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC)
Bridges", 2004.
[802.1ag] IEEE Std 802.1ag-2007, "Virtual Bridged Local Area
Networks - Amendment 5: Connectivity Fault Management",
2007.
[802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area
Networks - Amendment 3: Multiple Spanning Trees", 2002.
[CGMP] Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997,
<ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt>.
[LDP-P2MP] Minei, I., Ed., Kompella, K., Wijnands, I., and B.
Thomas, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", Work in Progress, May 2008.
[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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[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.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN
Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4834, April 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.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.Authors' Addresses ✨
okay bestie, this is the crew list 🫶 the people who wrote the spec, with where to find them and how to email them. five legends, no cap 👑
Our editor, Yuji, is up first 💅
Yuji Kamite (editor)
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
EMail: y.kamite@ntt.comNext up is Yuichiro, from NTT 🎀
Yuichiro Wada
NTT
3-9-11 Midori-cho
Musashino-shi
Tokyo 180-8585
Japan
EMail: wada.yuichiro@lab.ntt.co.jpThen Yetik, from AT&T Labs in Austin 🦋
Yetik Serbest
AT&T Labs
9505 Arboretum Blvd.
Austin, TX 78759
USA
EMail: yetik_serbest@labs.att.comThomas is next, from France Telecom R&D 🥖✨
Thomas Morin
France Telecom R&D
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: thomas.morin@francetelecom.comAnd last but absolutely not least, Luyuan from Cisco Systems 🌈💜
Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: lufang@cisco.comiconic team, periodt 🫶
📦 where this page comes from
- ietf: rfc5501 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms