From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4834.txt | 2075 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2075 insertions(+) create mode 100644 doc/rfc/rfc4834.txt (limited to 'doc/rfc/rfc4834.txt') diff --git a/doc/rfc/rfc4834.txt b/doc/rfc/rfc4834.txt new file mode 100644 index 0000000..51d91fe --- /dev/null +++ b/doc/rfc/rfc4834.txt @@ -0,0 +1,2075 @@ + + + + + + +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). + +Abstract + + This 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. + + + + + + + + + + + + + + + + + + + + + + + + +Morin Informational [Page 1] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7 + 3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8 + 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9 + 4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10 + 4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10 + 4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11 + 4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11 + 4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11 + 4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12 + 4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12 + 4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12 + 4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13 + 4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13 + 5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13 + 5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13 + 5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13 + 5.1.2. CE-PE Multicast Routing and Group Management + Protocols . . . . . . . . . . . . . . . . . . . . . . 14 + 5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14 + 5.1.4. Operations and Management . . . . . . . . . . . . . . 15 + 5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16 + 5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18 + 5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18 + 5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19 + 5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19 + 5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20 + 5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20 + 5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21 + 5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21 + 5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21 + 5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23 + 5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24 + 5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26 + 5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26 + 5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27 + 5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27 + 5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28 + + + +Morin Informational [Page 2] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morin Informational [Page 3] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +1. Introduction + + Virtual Private Network (VPN) services satisfying the requirements + defined in [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. + + + + + + + + + + +Morin Informational [Page 4] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +2. Conventions Used in This Document + +2.1. Terminology + + Although the reader is assumed to be familiar with the terminology + defined in [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. + + + + + + + +Morin Informational [Page 5] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +2.2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + +Morin Informational [Page 6] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +3. Problem Statement + +3.1. Motivations + + More and more L3VPN customers use IP multicast services within their + private infrastructures. Naturally, they want to extend these + multicast services to remote sites that are connected via a VPN. + + For instance, the customer could be a national TV channel with + several geographical locations that wants to broadcast a TV program + from a central point to several regional locations within its VPN. + + A solution to support multicast traffic could consist of point-to- + point tunnels across the provider network and requires the PEs + (Provider Edge routers) to replicate traffic. This would obviously + be sub-optimal as it would place the replication burden on the PE and + hence would have very poor scaling characteristics. It would also + probably waste bandwidth and control plane resources in the + provider's network. + + Thus, to provide multicast services for L3VPN networks in an + efficient manner (that is, with a scalable impact on signaling and + protocol state as well as bandwidth usage), in a large-scale + environment, new mechanisms are required to enhance existing L3VPN + solutions for proper support of multicast-based services. + +3.2. General Requirements + + This document sets out requirements for L3 provider-provisioned VPN + solutions designed to carry customers' multicast traffic. The main + requirement is that a solution SHOULD first satisfy the requirements + documented in [RFC4031]: as far as possible, a multicast service + should have the same characteristics as 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. + + + + + +Morin Informational [Page 7] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +3.3. Scaling vs. Optimizing Resource Utilization + + When transporting multicast VPN traffic over a service provider + network, there intrinsically is tension between scalability and + resource optimization, since the latter is likely to require the + maintenance of control plane states related to replication trees in + the core network [RFC3353]. + + Consequently, any deployment will require a trade-off to be made. + This document will express some requirements related to this trade- + off. + +4. Use Cases + + The goal of this section is to highlight how different applications + and network contexts may have a different impact on how a multicast + VPN solution is designed, deployed, and tuned. For this purpose, we + describe some typical use case scenarios and express expectations in + terms of deployment orders of magnitude. + + Most of the content of these sections originates from a survey done + in summer 2005, among institutions and providers that expect to + deploy such solutions. The full survey text and raw results (13 + responses) were published separately, and we only present here the + most relevant facts and expectations that the survey exposed. + + For scalability figures, we considered that it was relevant to + highlight the highest expectations, those that are expected to have + the greatest impact on solution design. For balance, we do also + mention cases where such high expectations were expressed in only a + few answers. + +4.1. Scenarios + + We don't provide here an exhaustive set of scenarios that a multicast + VPN solution is expected to support -- no solution should restrict + the scope of multicast applications and deployments that can be done + over a multicast VPN. + + Hence, we only give here a short list of scenarios that are expected + to have a large impact on the design of a multicast VPN solution. + + + + + + + + + + +Morin Informational [Page 8] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +4.1.1. Live Content Broadcast + + Under this label, we group all applications that distribute content + (audio, video, or other content) with the property that this content + is expected to be consulted at once ("live") by the receiver. + Typical applications are broadcast TV, production studio + connectivity, and distribution of market data feeds. + + The characteristics of such applications are the following: + + o one or few sources to many receivers + + o sources are often in known locations; receivers are in less + predictable locations (this latter point may depend on + applications) + + o in some cases, it is expected that the regularity of audience + patterns may help improve how the bandwidth/state trade-off is + handled + + o the number of streams can be as high as hundreds, or even + thousands, of streams + + o bandwidth will depend on the application, but may vary between a + few tens/hundreds of Kb/s (e.g., audio or low-quality video media) + and tens of Mb/s (high-quality video), with some demanding + professional applications requiring as much as hundreds of Mb/s. + + o QoS requirements include, in many cases, a low multicast group + join delay + + o QoS of these applications is likely to be impacted by packet loss + (some applications may be robust to low packet loss) and to have + low robustness against jitter + + o delay sensitivity will depend on the application: some + applications are not so delay sensitive (e.g., broadcast TV), + whereas others may require very low delay (professional studio + applications) + + o some of these applications may involve rapid changes in customer + multicast memberships as seen by the PE, but this will depend on + audience patterns and on the amount of provider equipments + deployed close to VPN customers + + + + + + + +Morin Informational [Page 9] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +4.1.2. Symmetric Applications + + Some use cases exposed by the survey can be grouped under this label, + and include many-to-many applications such as conferencing and server + cluster monitoring. + + They are characterized by the relatively high number of streams that + they can produce, which has a direct impact on scalability + expectations. + + A sub-case of this scenario is the case of symmetric applications + with small groups, when the number of receivers is low compared to + the number of sites in the VPNs (e.g., video conferencing and + e-learning applications). + + This latter case is expected to be an important input to solution + design, since it may significantly impact how the bandwidth/state is + managed. + + Optimizing bandwidth may require introducing dedicated states in the + core network (typically as much as the number of groups) for the + following reasons: + + o small groups, and low predictability of the location of + participants ("sparse groups") + + o possibly significantly high bandwidth (a few Mb/s per participant) + + Lastly, some of these applications may involve real-time interactions + and will be highly sensitive to packet loss, jitter, and delay. + +4.1.3. Data Distribution + + Some applications that are expected to be deployed on multicast VPNs + are non-real-time applications aimed at distributing data from few + sources to many receivers. + + Such applications may be considered to have lower expectations than + their counterparts proposed in this document, since they would not + necessarily involve more data streams and are more likely to adapt to + the available bandwidth and to be robust to packet loss, jitter, and + delay. + + One important property is that such applications may involve higher + bandwidths (hundreds of Mb/s). + + + + + + +Morin Informational [Page 10] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +4.1.4. Generic Multicast VPN Offer + + This ISP scenario is a deployment scenario where IP-multicast + connectivity is proposed for every VPN: if a customer requests a VPN, + then this VPN will support IP multicast by default. In this case, + the number of multicast VPNs equals the number of VPNs. This implies + a quite important scalability requirement (e.g., hundreds of PEs, + hundreds of VPNs per PE, with a potential increase by one order of + magnitude in the future). + + The per-mVPN traffic behavior is not predictable because how the + service is used is completely up to the customer. This results in a + traffic mix of the scenarios mentioned in Section 4.1. QoS + requirements are similar to typical unicast scenarios, with the need + for different classes. Also, in such a context, a reasonably large + range of protocols should be made available to the customer for use + at the PE-CE level. + + Also, in such a scenario, customers may want to deploy multicast + connectivity between two or more multicast VPNs as well as access to + Internet Multicast. + +4.2. Scalability Orders of Magnitude + + This section proposes orders of magnitude for different scalability + metrics relevant for multicast VPN issues. It should be noted that + the scalability figures proposed here relate to scalability + expectations of future deployments of multicast VPN solutions, as the + authors chose to not restrict the scope to only currently known + deployments. + +4.2.1. Number of VPNs with Multicast Enabled + + From the survey results, we see a broad range of expectations. There + are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), + but more typical answers are split between the low range of tens of + VPNs (7 answers) and the higher range of hundreds or thousands of + VPNs (2 + 4 answers). + + A solution SHOULD support a number of multicast VPNs ranging from one + to several thousands. + + A solution SHOULD NOT limit the proportion of multicast VPNs among + all (unicast) VPNs. + + + + + + + +Morin Informational [Page 11] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +4.2.2. Number of Multicast VPNs per PE + + The majority of survey answers express a number of multicast VPNs per + PE of around tens (8 responses between 5 and 50); a significant + number of them (4) expect deployments with hundreds or thousands (1 + response) of multicast VPNs per PE. + + A solution SHOULD support a number of multicast VPNs per PE of + several hundreds, and may have to scale up to thousands of VPNs per + PE. + +4.2.3. Number of CEs per Multicast VPN per PE + + Survey responses span from 1 to 2000 CEs per multicast VPN per PE. + Most typical responses are between tens (6 answers) and hundreds (4 + responses). + + A solution SHOULD support a number of CEs per multicast VPN per PE + going up to several hundreds (and may target the support of thousands + of CEs). + +4.2.4. PEs per Multicast VPN + + People who answered the survey typically expect deployments with the + number of PEs per multicast VPN in the range of hundreds of PEs (6 + responses) or tens of PEs (4 responses). Two responses were in the + range of thousands (one mentioned a 10k figure). + + A multicast VPN solution SHOULD support several hundreds of PEs per + multicast VPN, and MAY usefully scale up to thousands. + +4.2.4.1. ... with Sources + + The number of PEs (per VPN) that would be connected to sources seems + to be significantly lower than the number of PEs per VPN. This is + obviously related to the fact that many respondents mentioned + deployments related to content broadcast applications (one to many). + + Typical numbers are tens (6 responses) or hundreds (4 responses) of + source-connected PEs. One respondent expected a higher number of + several thousands. + + A solution SHOULD support hundreds of source-connected PEs per VPN, + and some deployment scenarios involving many-to-many applications may + require supporting a number of source-connected PEs equal to the + number of PEs (hundreds or thousands). + + + + + +Morin Informational [Page 12] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +4.2.4.2. ... with Receivers + + The survey showed that the number of PEs with receivers is expected + to be of the same order of magnitude as the number of PEs in a + multicast VPN. This is consistent with the intrinsic nature of most + multicast applications, which have few source-only participants. + +4.2.5. PEs with Multicast VRFs + + A solution SHOULD scale up to thousands of PEs having multicast + service enabled. + +4.2.6. Number of Streams Sourced + + Survey responses led us to retain the following orders of magnitude + for the number of streams that a solution SHOULD support: + + per VPN: hundreds or thousands of streams + + per PE: hundreds of streams + +5. Requirements for Supporting IP Multicast within L3 PPVPNs + + Again, the aim of this document is not to specify solutions but to + give requirements for supporting IP multicast within L3 PPVPNs. + + In order to list these requirements, we have taken the standpoint of + two different important entities: the end user (the customer using + the VPN) and the service provider. + + In the rest of the document, by "a solution" or "a multicast VPN + solution", we mean a solution that allows multicast in an L3 + provider-provisioned VPN, and which addresses the requirements listed + in this document. + +5.1. End User/Customer Standpoint + +5.1.1. Service Definition + + As for unicast, the multicast service MUST be provider provisioned + and SHALL NOT require customer devices (CEs) to support any extra + features compared to those required for multicast in a non-VPN + context. Enabling a VPN for multicast support SHOULD be possible + with no impact (or very limited impact) on existing multicast + protocols possibly already deployed on the CE devices. + + + + + + +Morin Informational [Page 13] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +5.1.2. CE-PE Multicast Routing and Group Management Protocols + + Consequently to 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. + +5.1.3. Quality of Service (QoS) + + Firstly, general considerations regarding QoS in L3VPNs expressed in + 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 + + + +Morin Informational [Page 14] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.1.4. Operations and Management + + The requirements and definitions for operations and management (OAM) + of L3VPNs that are defined in [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. + + + + +Morin Informational [Page 15] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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). + +5.1.5. Security Requirements + + Security is a key point for a customer who uses a VPN service. For + instance, the [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. + + + +Morin Informational [Page 16] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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). + +5.1.6. Extranet + + In current PP L3VPN models, a customer site may be set up to be part + of multiple VPNs, and this should still be possible when a VPN is + multicast-enabled. In practice, it means that a VRF or VR can be + part of more than one VPN. + + A multicast VPN solution MUST support such deployments. + + For instance, it must be possible to configure a VRF so that an + enterprise site participating in a BGP/MPLS multicast-enabled VPN and + connected to that VRF can receive a multicast stream from (or + originate a multicast stream towards) another VPN that would be + associated to that VRF. + + This means that a multicast VPN solution MUST offer means for a VRF + to be configured so that multicast connectivity can be set up for a + chosen set of extranet VPNs. More precisely, it MUST be possible to + configure a VRF so that: + + o receivers behind attached CEs can receive multicast traffic + sourced in the configured set of extranet VPNs + + o sources behind attached CEs can reach multicast traffic receivers + located in the configured set of extranet VPNs + + o multicast reception and emission can be independently enabled for + each of the extranet VPNs + + + +Morin Informational [Page 17] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.1.7. Internet Multicast + + Connectivity with Internet Multicast is a particular case of the + previous section, where sites attached to a VR/VRF would need to + receive/send multicast traffic from/to the Internet. + + This should be considered OPTIONAL given the additional + considerations, such as security, needed to fulfill the requirements + for providing Internet Multicast. + +5.1.8. Carrier's Carrier + + Many L3 PPVPN solutions, such as [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. + + + + +Morin Informational [Page 18] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.1.9. Multi-Homing, Load Balancing, and Resiliency + + A multicast VPN solution SHOULD be compatible with current solutions + that aim at improving the service robustness for customers such as + multi-homing, CE-PE link load balancing, and fail-over. A multicast + VPN solution SHOULD also be able to offer those same features for + multicast traffic. + + Any solution SHOULD support redundant topology of CE-PE links. It + SHOULD minimize multicast traffic disruption and fail-over. + +5.1.10. RP Engineering + + When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer + side, the RP function (or RP-address in the case of bidir-PIM) has to + be associated to a node running PIM, and configured on this node. + +5.1.10.1. RP Outsourcing + + In the case of PIM-SM in ASM mode, engineering of the RP function + requires the deployment of specific protocols and associated + configurations. A service provider may offer to manage customers' + multicast protocol operation on their behalf. This implies that it + is necessary to consider cases where a customer's RPs are outsourced + (e.g., on PEs). Consequently, a VPN solution MAY support the hosting + of the RP function in a VR or VRF. + +5.1.10.2. RP Availability + + Availability of the RP function (or address) is required for proper + operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity + to the RP from a receiver or source will impact the multicast + service. For this reason, different mechanisms exist, such as BSR + [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)- + based [RFC3446] or PIM-based [RFC4610]). + + These protocols and procedures SHOULD work transparently through a + multicast VPN, and MAY if relevant, be implemented in a VRF/VR. + + Moreover, a multicast VPN solution MAY improve the robustness of the + ASM multicast service regarding loss of connectivity to the RP, by + providing specific features that help: + + + + +Morin Informational [Page 19] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + a) maintain ASM multicast service among all the sites within an MVPN + that maintain connectivity among themselves, even when the site(s) + hosting the RP lose their connectivity to the MVPN + + b) maintain ASM multicast service within any site that loses + connectivity to the service provider + +5.1.10.3. RP Location + + In the case of PIM-SM, when a source starts to emit traffic toward a + group (in ASM mode), if sources and receivers are located in VPN + sites that are different than that of the RP, then traffic may + transiently flow twice through the SP network and the CE-PE link of + the RP (from source to RP, and then from RP to receivers). This + traffic peak, even short, may not be convenient depending on the + traffic and link bandwidth. + + Thus, a VPN solution MAY provide features that solve or help mitigate + this potential issue. + +5.1.11. Addressing + + A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions + on multicast group addresses used by VPN customers. + + In particular, like unicast traffic, an overlap of multicast group + address sets used by different VPN customers MUST be supported. + + The use of globally unique means of multicast-based service + identification at the scale of the domain where such services are + provided SHOULD be recommended. For IPv4 multicast, this implies the + use of the multicast administratively scoped range (239/8 as defined + by [RFC2365]) for services that are to be used only inside the VPN, + and of either SSM-range addresses (232/8 as defined by [RFC4607]) or + globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for + services for which traffic may be transmitted outside the VPN. + +5.1.12. Minimum MTU + + For customers, it is often a serious issue whether or not transmitted + packets will be fragmented. In particular, some multicast + applications might have different requirements than those that make + use of unicast, and they may expect services that guarantee available + packet length not to be fragmented. + + Therefore, a multicast VPN solution SHOULD be designed with these + considerations in mind. In practice: + + + + +Morin Informational [Page 20] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.2. Service Provider Standpoint + + Note: To avoid repetition and confusion with terms used in solution + specifications, we introduced in Section 2.1 the term MDTunnel (for + Multicast Distribution Tunnel), which designates the data plane means + used by the service provider to forward customer multicast traffic + over the core network. + +5.2.1. General Requirement + + The deployment of a multicast VPN solution SHOULD be possible with no + (or very limited) impact on existing deployments of standardized + multicast-related protocols on P and PE routers. + +5.2.2. Scalability + + Some currently standardized and deployed L3VPN solutions have the + major advantage of being scalable in the core regarding the number of + customers and the number of customer routes. For instance, in the + [RFC4364] and Virtual Router [VRs] models, a P router sees a number + of MPLS tunnels that is only linked to the number of PEs and not to + the number of VPNs, or customer sites. + + As far as possible, this independence in the core, with respect to + the number of customers and to customer activity, is recommended. + Yet, it 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. + + + + +Morin Informational [Page 21] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + + + +Morin Informational [Page 22] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + These considerations naturally lead us to believe that proposed + solutions SHOULD offer the possibility of sharing such resources + between different multicast streams (between different VPNs, between + different multicast streams of the same or of different VPNs). This + means, for instance, if MDTunnels are trees, being able to share an + MDTunnel between several customers. + + Those scalability issues are expected to be more significant on P + routers, but a multicast VPN solution SHOULD address both P and PE + routers as far as scalability is concerned. + +5.2.3. Resource Optimization + +5.2.3.1. General Goals + + One of the aims of the use of multicast instead of unicast is + resource optimization in the network. + + The two obvious suboptimal behaviors that a multicast VPN solution + would want to avoid are needless duplication (when the same data + travels twice or more on a link, e.g., when doing ingress PE + replication) and needless reception (e.g., a PE receiving traffic + that it does not need because there are no downstream receivers). + +5.2.3.2. Trade-off and Tuning + + As previously stated in this document, designing a scalable solution + that makes an optimal use of resources is considered difficult. + Thus, what is expected from a multicast VPN solution is that it + addresses the resource optimization issue while taking into account + the fact that some trade-off has to be made. + + Moreover, it seems that a "one size fits all" trade-off probably does + not exist either. Thus, a multicast VPN solution SHOULD offer + service providers appropriate configuration settings that let them + tune the trade-off according to their particular constraints (network + topology, platforms, customer applications, level of service offered + etc.). + + As an illustration, here are some example bounds of the trade-off + space: + + + + + + + + + + +Morin Informational [Page 23] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + Bandwidth optimization: setting up optimized core MDTunnels whose + topology (PIM or P2MP LSP trees, etc.) precisely follows a + customer's multicast routing changes. This requires managing a + large amount of state in the core, and also quick reactions of the + core to customer multicast routing changes. This approach can be + advantageous in terms of bandwidth, but it is poor in terms of + state management. + + State optimization: setting up MDTunnels that aggregate multiple + customer multicast streams (all or some of them, across different + VPNs or not). This will have better scalability properties, but + at the expense of bandwidth since some MDTunnel leaves will very + likely receive traffic they don't need, and because increased + constraints will make it harder to find optimal MDTunnels. + +5.2.3.3. Traffic Engineering + + If the VPN service provides traffic engineering (TE) features for the + connection used between PEs for unicast traffic in the VPN service, + the solution SHOULD provide equivalent features for multicast + traffic. + + A solution SHOULD offer means to support key TE objectives as defined + in [RFC3272], for the multicast service. + + A solution MAY also usefully support means to address multicast- + specific traffic engineering issues: it is known that bandwidth + resource optimization in the point-to-multipoint case is an NP-hard + problem, and that techniques used for unicast TE may not be + applicable to multicast traffic. + + Also, it has been identified that managing the trade-off between + resource usage and scalability may incur uselessly sending traffic to + some PEs participating in a multicast VPN. For this reason, a + multicast VPN solution MAY permit that the bandwidth/state tuning + take into account the relative cost or availability of bandwidth + toward each PE. + +5.2.4. Tunneling Requirements + +5.2.4.1. Tunneling Technologies + + Following the principle of separation between the control plane and + the forwarding plane, a multicast VPN solution SHOULD be designed so + that control and forwarding planes are not interdependent: the + control plane SHALL NOT depend on which forwarding plane is used (and + vice versa), and the choice of forwarding plane SHOULD NOT be limited + + + + +Morin Informational [Page 24] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.2.4.2. MTU and Fragmentation + + A solution SHOULD support a method that provides the minimum MTU of + the MDTunnel (e.g., to discover MTU, to communicate MTU via + signaling, etc.) so that: + + o fragmentation inside the MDTunnel does not happen, even when + allowed by the underlying tunneling technology + + o proper troubleshooting can be performed if packets that are too + big for the MDTunnel happen to be encapsulated in the MDTunnel + + + + + +Morin Informational [Page 25] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +5.2.5. Control Mechanisms + + The solution MUST provide some mechanisms to control the sources + within a VPN. This control includes the number of sources that are + entitled to send traffic on the VPN, and/or the total bit rate of all + the sources. + + At the reception level, the solution MUST also provide mechanisms to + control the number of multicast groups or channels VPN users are + entitled to subscribe to and/or the total bit rate represented by the + corresponding multicast traffic. + + All these mechanisms MUST be configurable by the service provider in + order to control the amount of multicast traffic and state within a + VPN. + + Moreover, it MAY be desirable to be able to impose some bound on the + quantity of state used by a VPN in the core network for its multicast + traffic, whether on each P or PE router, or globally. The motivation + is that it may be needed to avoid out-of-resources situations (e.g., + out of memory to maintain PIM state if IP multicast is used in the + core for multicast VPN traffic, or out of memory to maintain RSVP + state if MPLS P2MP is used, etc.). + +5.2.6. Support of Inter-AS, Inter-Provider Deployments + + A solution MUST support inter-AS (Autonomous System) multicast VPNs, + and SHOULD support inter-provider multicast VPNs. Considerations + about coexistence with unicast inter-AS VPN Options A, B, and C (as + described in Section 10 of [RFC4364]) are strongly encouraged. + + A multicast VPN solution SHOULD provide inter-AS mechanisms requiring + the least possible coordination between providers, and keep the need + for detailed knowledge of providers' networks to a minimum -- all + this being in comparison with corresponding unicast VPN options. + + 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 + + + + + + +Morin Informational [Page 26] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.2.7. Quality-of-Service Differentiation + + A multicast VPN solution SHOULD give a VPN service provider the + ability to offer, guarantee and enforce differentiated levels of QoS + for its different customers. + +5.2.8. Infrastructure security + + The solution SHOULD provide the same level of security for the + service provider as what currently exists for unicast VPNs (for + instance, as developed in the Security sections of [RFC4364] and + [VRs]). For instance, traffic segregation and intrinsic protection + against DoS (Denial of Service) and DDoS (Distributed Denial of + Service) attacks of the BGP/MPLS VPN solution must be supported by + the multicast solution. + + 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 + + + +Morin Informational [Page 27] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.2.9. Robustness + + Resiliency is also crucial to infrastructure security; thus, a + multicast VPN solution SHOULD either avoid single points of failures + or propose some technical solution making it possible to implement a + fail-over mechanism. + + As an illustration, one can consider the case of a solution that + would use PIM-SM as a means to set up MDTunnels. In such a case, the + PIM RP might be a single point of failure. Such a solution SHOULD be + compatible with a solution implementing RP resiliency, such as + anycast-RP [RFC4610] or BSR [PIM-BSR]. + +5.2.10. Operation, Administration, and Maintenance + + The operation of a multicast VPN solution SHALL be as light as + possible, and providing automatic configuration and discovery SHOULD + be a priority when designing a multicast VPN solution. Particularly, + the operational burden of setting up multicast on a PE or for a VR/ + VRF SHOULD be as low as possible. + + Also, as far as possible, the design of a solution SHOULD carefully + consider the number of protocols within the core network: if any + additional protocols are introduced compared with the unicast VPN + service, the balance between their advantage and operational burden + SHOULD be examined thoroughly. + + Moreover, monitoring of multicast-specific parameters and statistics + SHOULD be offered to the service provider, following the requirements + expressed in [RFC4176]. + + Most notably, the provider SHOULD have access to: + + 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) + + + + +Morin Informational [Page 28] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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). + +5.2.11. Compatibility and Migration Issues + + It is a requirement that unicast and multicast services MUST be able + to coexist within the same VPN. + + Likewise, a multicast VPN solution SHOULD be designed so that its + activation in devices that participate in the deployment and + maintenance of a multicast VPN SHOULD be as smooth as possible, i.e., + without affecting the overall quality of the services that are + already supported by the underlying infrastructure. + + A multicast VPN solution SHOULD prevent compatibility and migration + issues, for instance, by focusing on providing mechanisms + + + +Morin Informational [Page 29] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + 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. + +5.2.12. Troubleshooting + + A multicast VPN solution that dynamically adapts the way some client + multicast traffic is carried over the provider's network may incur + the disadvantage of being hard to troubleshoot. In such a case, to + help diagnose multicast network issues, a multicast VPN solution + SHOULD provide monitoring information describing how client traffic + is carried over the network (e.g., if a solution uses multicast-based + MDTunnels, which provider multicast group is used for a given client + multicast stream). A solution MAY also provide configuration options + to avoid any dynamic changes, for multicast traffic of a particular + VPN or a particular multicast stream. + + Moreover, a solution MAY provide mechanisms that allow network + operators to check that all VPN sites that advertised interest in a + particular customer multicast stream are properly associated with the + corresponding MDTunnel. Providing operators with means to check the + proper setup and operation of MDTunnels MAY also be provided (e.g., + when P2MP MPLS is used for MDTunnels, troubleshooting functionalities + SHOULD integrate mechanisms compliant with [RFC4687], such as LSP + Ping [RFC4379][LSP-PING]). Depending on the implementation, such + verification could be initiated by a source-PE or a receiver-PE. + +6. Security Considerations + + This document does not by itself raise any particular security issue. + + A set of security issues has been identified that MUST be addressed + when considering the design and deployment of multicast-enabled L3 + PPVPNs. Such issues have been described in Section 5.1.5 and + Section 5.2.8. + + + + + + +Morin Informational [Page 30] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +7. Contributors + + The main contributors to this document are listed below, in + alphabetical order: + + o Christian Jacquenet + France Telecom + 3, avenue Francois Chateau + CS 36901 35069 RENNES Cedex, France + Email: christian.jacquenet@orange-ftgroup.com + + o Yuji Kamite + NTT Communications Corporation + Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku + Tokyo 163-1421, Japan + Email: y.kamite@ntt.com + + o Jean-Louis Le Roux + France Telecom R&D + 2, avenue Pierre-Marzin + 22307 Lannion Cedex, France + Email: jeanlouis.leroux@orange-ftgroup.com + + o Nicolai Leymann + Deutsch Telecom + Engineering Networks, Products & Services + Goslarer Ufer 3510589 Berlin, Germany + Email: nicolai.leymann@t-systems.com + + o Renaud Moignard + France Telecom R&D + 2, avenue Pierre-Marzin + 22307 Lannion Cedex, France + Email: renaud.moignard@orange-ftgroup.com + + o Thomas Morin + France Telecom R&D + 2, avenue Pierre-Marzin + 22307 Lannion Cedex, France + Email: thomas.morin@orange-ftgroup.com + +8. Acknowledgments + + The authors would like to thank, in rough chronological order, + Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, + Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel + King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, + Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka + + + +Morin Informational [Page 31] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, + valuable input, and feedback. + + We also thank the people who kindly answered the survey, and Daniel + King, who took care of gathering and anonymizing its results. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for + Layer 3 Provider-Provisioned Virtual Private + Networks (PPVPNs)", RFC 4031, April 2005. + + [RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned + Virtual Private Network (VPN) Terminology", + RFC 4026, March 2005. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. + Kouvelas, "Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification (Revised)", + RFC 4601, August 2006. + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast + for IP", RFC 4607, August 2006. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and + A. Thyagarajan, "Internet Group Management Protocol, + Version 3", RFC 3376, October 2002. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., + and A. Gonguet, "Framework for Layer 3 Virtual + Private Networks (L3VPN) Operations and Management", + RFC 4176, October 2005. + + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): + Protocol Specification (Revised)", RFC 3973, + January 2005. + + + + + + +Morin Informational [Page 32] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +9.2. Informative References + + [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. + + + + + + +Morin Informational [Page 33] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + [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. + + + + + + + +Morin Informational [Page 34] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + [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. + + + + + + +Morin Informational [Page 35] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi- + Protocol Label Switched (MPLS) Data Plane Failures", + RFC 4379, February 2006. + + [LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane + Failures in Point-to-Multipoint Multiprotocol", + Work in Progress, September 2006. + + [RFC4459] Savola, P., "MTU and Fragmentation Issues with In- + the-Network Tunneling", RFC 4459, April 2006. + +Author's Address + + Thomas Morin (editor) + France Telecom R&D + 2, avenue Pierre Marzin + Lannion 22307 + France + + EMail: thomas.morin@orange-ftgroup.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morin Informational [Page 36] + +RFC 4834 L3VPN Mcast Reqs April 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Morin Informational [Page 37] + -- cgit v1.2.3