Network Working Group T. Morin, Ed. Request for Comments: 4834 France Telecom R&D Category: Informational April 2007 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.
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 . . . . . . . . . . . . . . . . . . 33
RFC4031] are now being offered by many service providers throughout the world. VPN services are popular because customers need not be aware of the VPN technologies deployed in the provider network. They scale well for the following reasons: o because P routers (Provider Routers) need not be aware of VPN service details o because the addition of a new VPN member requires only limited configuration effort There is also a growing need for support of IP multicast-based services. Efforts to provide efficient IP multicast routing protocols and multicast group management have been made in standardization bodies which has led, in particular, to the definition of Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP). However, multicast traffic is not natively supported within existing L3 PPVPN solutions. Deploying multicast over an L3VPN today, with only currently standardized solutions, requires designing customized solutions which will be inherently limited in terms of scalability, operational efficiency, and bandwidth usage. This document complements the generic L3VPN requirements [RFC4031] document, by specifying additional requirements specific to the deployment within PPVPNs of services based on IP multicast. It clarifies the needs of both VPN clients and providers and formulates the problems that should be addressed by technical solutions with the key objective being to remain solution agnostic. There is no intent in this document to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim at expressing multicast-related requirements that are not specific to L3 PPVPNs. It is expected that solutions that specify procedures and protocol extensions for multicast in L3 PPVPNs SHOULD satisfy these requirements.
RFC4031], [RFC4364], [RFC4601], and [RFC4607], the following glossary of terms may be worthwhile. We also propose here generic terms for concepts that naturally appear when multicast in VPNs is discussed. ASM: Any Source Multicast. One of the two multicast service models, in which 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, i.e., for which some PE devices (if not all) are multicast-enabled and whose core architecture supports multicast VPN routing and forwarding. PPVPN: Provider-Provisioned Virtual Private Network. PE, CE: "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As suggested in [RFC4026], we will use these notations to refer to the equipments/routers/devices themselves. Thus, "PE" will refer to the router on the provider's edge, which faces the "CE", the router on the customer's edge. VRF or VR: By these terms, we refer to the entity defined in a PE dedicated to a specific VPN instance. "VRF" refers to "VPN Routing and Forwarding table" as defined in [RFC4364], and "VR" to "Virtual Router" as defined in [VRs] terminology. MDTunnel: Multicast Distribution Tunnel. The means by which the customer's multicast traffic will be transported across the SP network. This is meant in a generic way: such tunnels can be either point-to- point or point-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, the wording also encompasses bidirectional tunnels.
S: Denotes a multicast source. G: Denotes a multicast group. Multicast channel: In the multicast SSM model [RFC4607], a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(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 a specific source. RP: Rendezvous Point (Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]). P2MP, MP2MP: Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees. L3VPN, VPN: Throughout this document, "L3VPN" or even just "VPN" will refer to "Provider-Provisioned Layer 3 Virtual Private Network" (PP L3VPNs), and will be preferred for readability. Please refer to [RFC4026] for details about terminology specifically relevant to VPN aspects, and to [RFC2432] for multicast performance or quality of service (QoS)-related terms. RFC2119].
RFC4031]: as far as possible, a multicast service should have the same characteristics as the unicast equivalent, including the same simplicity (technology unaware), the same quality of service (if any), the same management (e.g., performance monitoring), etc. 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.
RFC3353]. Consequently, any deployment will require a trade-off to be made. This document will express some requirements related to this trade- off.
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.
Section 5.1.1, multicast-related protocol exchanges between a CE and its directly connected PE SHOULD happen via existing multicast protocols. Such protocols include: PIM-SM [RFC4601], bidirectional-PIM [BIDIR-PIM], PIM - Dense Mode (DM) [RFC3973], and IGMPv3 [RFC3376] (this version implicitly supports hosts that only implement IGMPv1 [RFC1112] or IGMPv2 [RFC2236]). Among those protocols, the support of 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 considering deployments, PIM-DM is considered OPTIONAL. When a multicast VPN solution is built on a VPN solution supporting IPv6 unicast, it MUST also support v6 variants of the above protocols, including MLDv2, and PIM-SM IPv6-specific procedures. For a multicast VPN solution built on a unicast VPN solution supporting only IPv4, it is RECOMMENDED that the design favors the definition of procedures and encodings that will provide an easy adaptation to IPv6. Section 5.5 of [RFC4031] are also relevant to this section. QoS is measured in terms of delay, jitter, packet loss, and availability. These metrics are already defined for the current unicast PPVPN services and are included in Service Level Agreements (SLAs). In some cases, the agreed SLA may be different between unicast and multicast, and that will require differentiation mechanisms in order to 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 is carried over the service provider's network. A multicast VPN solution SHALL allow a service provider to 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 this perspective, the deployment of multicast-based services within an L3VPN
environment SHALL benefit from Diffserv [RFC2475] mechanisms that include multicast traffic identification, classification, and marking capabilities, as well as multicast traffic policing, scheduling, and conditioning capabilities. Such capabilities MUST therefore be supported by any participating device in the establishment and the maintenance of the multicast distribution tunnel within the VPN. As multicast is often used to deliver high-quality services such as TV broadcast, a multicast VPN solution MAY provide additional features to support high QoS such as bandwidth reservation and admission control. Also, considering that multicast reception is receiver-triggered, group join delay (as defined in [RFC2432]) is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard. The group leave delay (as defined in [RFC2432]) may also be important on the CE-PE link for some usage scenarios: in cases where the typical bandwidth of multicast streams is close to the bandwidth of a PE-CE link, it will be important to have the ability to stop the emission of a stream on the PE-CE link as soon as it stops being requested by the CE, to allow for fast switching between two different high-throughput multicast streams. This implies 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 reduce the group leave delay to the minimum. Lastly, a multicast VPN solution SHOULD as much as possible ensure that client multicast traffic packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network. Packet loss issues also have to be considered when a new source starts to send traffic to a group: any receiver interested in receiving such traffic SHOULD be serviced accordingly. RFC4176] equally apply to multicast, and are not extensively repeated in this document. This sub-section mentions the most important guidelines and details points of particular relevance in the context of multicast in L3VPNs. A multicast VPN solution SHOULD allow a multicast VPN customer to manage the capabilities and characteristics of their multicast VPN services.
A multicast VPN solution MUST support SLA monitoring capabilities, which SHOULD rely upon techniques similar to those used for the unicast service for the same monitoring purposes. Multicast SLA- related metrics SHOULD be available through means similar to the ones already used for unicast-related monitoring, such as Simple Network Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT]. Multicast-specific characteristics that may be monitored include: multicast statistics per stream, end-to-end delay, and group join/ leave delay (time to start/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/dropped traffic, by period of time. It MAY include IP Performance Metrics related information (IPPM, [RFC2330]) that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. See [MULTIMETRICS]. A generic discussion of SLAs is provided in [RFC3809]. Apart from statistics on multicast traffic, customers of a multicast VPN will need information concerning the status of their multicast resource usage (multicast routing states and bandwidth). Indeed, as mentioned in Section 5.2.5, for scalability purposes, a service provider may limit the number (and/or throughput) of multicast streams that are received/sent to/from a client site. In such a case, a multicast VPN solution SHOULD allow customers to find out their current resource usage (multicast routing states and throughput), and to receive some kind of feedback if their usage exceeds the agreed bounds. Whether this issue will be better handled at the protocol level at the PE-CE interface or at the Service Management Level interface [RFC4176] is left for further discussion. 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). RFC4364] model offers some guarantees concerning 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.
Moreover, the activation of multicast features SHOULD be possible: o per VRF / per VR o per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR) o per multicast group and/or per channel o 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 are not part of the VPN. From a security standpoint, this may be a problem for some VPN customers; thus, a multicast VPN solution using such a scheme MAY offer ways to avoid this for specific customers (and/or specific customer multicast streams).
Moreover, a solution MUST allow service providers to control an extranet's multicast connectivity independently from the extranet's unicast connectivity. More specifically: o enabling unicast connectivity to another VPN MUST be possible without activating multicast connectivity with that VPN o 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 o 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 it is a physical or logical link. RFC4364] and [VRs], define the "Carrier's Carrier" model, where a "carrier's carrier" service provider supports one or more customer ISPs, or "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. This implies that the protocols that may be used at the PE-CE level SHOULD NOT be restricted to protocols required as per Section 5.1.2 and SHOULD include some of the protocols listed in Section 5.2.4, such as for instance 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, giving the ability to the sub-carrier to use multipoint LSPs as a tunneling mechanism. 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 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.
o 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 o a multicast VPN solution SHOULD enable the service provider to commit to a minimum path MTU usable by multicast VPN customers o 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. 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. 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 is 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: o the number of PEs o the number of customer VPNs (total and per PE) o the number of PEs and sites in any VPN o 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: o the processing resources required by the control plane (neighborhood or session maintenance messages, keep-alives, timers, etc.) o the memory resources needed for the control plane o the amount of protocol information transmitted to manage a multicast VPN (e.g., signaling throughput) o 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) o the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel) o 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.
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. 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. 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.
by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology. 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. For MDTunnels, a solution SHOULD be able to use a range of tunneling technologies, including point-to-point and point-to-multipoint, such as: o Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in multicast IP trees), o 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]), o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast [RFC4045]), o IPsec [RFC4031] o 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.
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. o 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) o 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. 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. 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. 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. 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. 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). Lastly, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view. RFC4610] or BSR [PIM-BSR]. RFC4176]. Most notably, the provider SHOULD have access to: o Multicast traffic statistics (incoming/outgoing/dropped/total traffic conveyed, by period of time) o Information about client multicast resource usage (multicast routing state and bandwidth usage)
o Alarms when limits are reached on such resources o 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. o 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") o 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 performances 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).
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. In any case, a solution SHOULD state a migration policy from possibly existing deployments. 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. Section 5.1.5 and Section 5.2.8.
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. [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.
[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.
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 email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.