l3vpn Working Group T. Morin, Ed. Internet-Draft France Telecom R&D Expires: July 22, 2006 January 18, 2006 Requirements for Multicast in L3 Provider-Provisioned VPNs draft-ietf-l3vpn-ppvpn-mcast-reqts-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 22, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within 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. Working group Morin Expires July 22, 2006 [Page 1] Internet-Draft L3VPN Mcast Reqs January 2006 This document is a product of the IETF's Layer 3 Virtual Private Network (l3vpn) working group. Comments should be addressed to WG's mailing list at . The charter for l3vpn may be found at Contributors 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@francetelecom.com [3] 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 [4] o Jean-Louis Le Roux France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France Morin Expires July 22, 2006 [Page 2] Internet-Draft L3VPN Mcast Reqs January 2006 Email: jeanlouis.leroux@francetelecom.com [5] o Nicolai Leymann T-Systems International GmbH Engineering Networks, Products & Services Goslarer Ufer 35 10589 Berlin, Germany Email: nicolai.leymann@t-systems.com [6] o Renaud Moignard France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: renaud.moignard@francetelecom.com [7] o Thomas Morin France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: thomas.morin@francetelecom.com [8] Morin Expires July 22, 2006 [Page 3] Internet-Draft L3VPN Mcast Reqs January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 7 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. General Requirements . . . . . . . . . . . . . . . . . . . 9 3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 9 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Live content broadcast . . . . . . . . . . . . . . . . 11 4.1.2. Symmetric applications . . . . . . . . . . . . . . . . 12 4.1.3. Data distribution . . . . . . . . . . . . . . . . . . 13 4.1.4. Generic multicast VPN offer . . . . . . . . . . . . . 13 4.2. Scalability orders of magnitude . . . . . . . . . . . . . 14 4.2.1. Number of VPNs with multicast enabled . . . . . . . . 14 4.2.2. Number of multicast VPNs per PE . . . . . . . . . . . 14 4.2.3. Number of CEs per multicast VPN per PE . . . . . . . . 14 4.2.4. PEs per multicast VPN . . . . . . . . . . . . . . . . 14 4.2.5. PEs with multicast VRFs . . . . . . . . . . . . . . . 15 4.2.6. Number of streams sourced . . . . . . . . . . . . . . 15 5. Requirements for supporting IP multicast within L3 PPVPNs . . 16 5.1. End user/customer standpoint . . . . . . . . . . . . . . . 16 5.1.1. Service definition . . . . . . . . . . . . . . . . . . 16 5.1.2. CE-PE Multicast routing and management protocols . . . 16 5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 17 5.1.4. SLA parameters measurement . . . . . . . . . . . . . . 18 5.1.5. Security Requirements . . . . . . . . . . . . . . . . 18 5.1.6. Monitoring and Troubleshooting . . . . . . . . . . . . 19 5.1.7. Extranet . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.8. Internet Multicast . . . . . . . . . . . . . . . . . . 20 5.1.9. Carrier's carrier . . . . . . . . . . . . . . . . . . 20 5.1.10. Multi-homing, load balancing and resiliency . . . . . 21 5.1.11. RP Engineering . . . . . . . . . . . . . . . . . . . . 21 5.1.12. Addressing . . . . . . . . . . . . . . . . . . . . . . 21 5.1.13. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 22 5.2. Service provider standpoint . . . . . . . . . . . . . . . 22 5.2.1. General requirement . . . . . . . . . . . . . . . . . 22 5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 22 5.2.3. Resource optimization . . . . . . . . . . . . . . . . 24 5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 25 5.2.5. Control mechanisms . . . . . . . . . . . . . . . . . . 26 5.2.6. Support of Inter-AS, inter-provider deployments . . . 27 5.2.7. Quality of Service Differentiation . . . . . . . . . . 27 5.2.8. Infrastructure security . . . . . . . . . . . . . . . 28 5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 29 Morin Expires July 22, 2006 [Page 4] Internet-Draft L3VPN Mcast Reqs January 2006 5.2.10. Management tools, OAM . . . . . . . . . . . . . . . . 29 5.2.11. Compatibility and migration issues . . . . . . . . . . 30 5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative references . . . . . . . . . . . . . . . . . . . 35 9.2. Informative references . . . . . . . . . . . . . . . . . . 35 Appendix A. Requirements summary . . . . . . . . . . . . . . . . 40 A.1. General Requirements (Section 3) . . . . . . . . . . . . . 40 A.2. Scalability orders of magnitude (Section 4.2) . . . . . . 40 A.3. Requirements from mutlicast VPN customer standpoint (Section 5.1) . . . . . . . . . . . . . . . . . . . . . . 41 A.4. Requirements from provider standpoint . . . . . . . . . . 44 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 49 B.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 49 B.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 49 B.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 50 B.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 52 Morin Expires July 22, 2006 [Page 5] Internet-Draft L3VPN Mcast Reqs January 2006 1. Introduction 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 done in standardization bodies which has led, in particular, to the definition of the PIM and IGMP protocols. 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 to either specify solution-specific details in this document 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 Expires July 22, 2006 [Page 6] Internet-Draft L3VPN Mcast Reqs January 2006 2. Conventions used in this document 2.1. Terminology Although the reader is assumed to be familiar with the terminology defined in [RFC4031], [RFC2547bis], [PIM-SM], PIM-SSM [I-D.ietf-ssm- arch] the following glossary of terms may be worthwhile. Moreover 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 suscribes to a multicast group to receive data sent to the group by any source. Multicast-enabled VPN, or multicast VPN: a VPN which 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 this phrase, 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 [RFC2547bis], and "VR" to "Virtual Router" as defined in [VRs] terminology. MD Tunnel: 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 bi-directional tunnels. G: Denotes a multicast group Multicast channel: (S,G) in the SSM model Morin Expires July 22, 2006 [Page 7] Internet-Draft L3VPN Mcast Reqs January 2006 Participating device: Refers to any network device that not only participates in the deployment and the maintenance of the VPN infrastructure, but also in the establishment and the maintenance of the MD Tunnel (see above). S: Denotes a multicast source 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: Rendez-vous point ([PIM-SM]) 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 prefered for readability. Please refer to [RFC4026] for details about terminology specifically relevant to VPN aspects, and to [RFC2432] for multicast performance or 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 Expires July 22, 2006 [Page 8] Internet-Draft L3VPN Mcast Reqs January 2006 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 in using point- to-point tunnels across the provider network and requiring the PEs (Provider's 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 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. monitoring of performances), 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, [RFC2547bis] or [VRs]) and retain consistency with those, although this is not a core requirement. 3.3. Scaling vs. Optimizing Resource Utilization When transporting multicast VPN traffic over a service provider network, there intrinsically is tension between scalability and Morin Expires July 22, 2006 [Page 9] Internet-Draft L3VPN Mcast Reqs January 2006 resource optimization, since the latter is likely to require maintaining multicast state in the core network. Consequently, any deployment will require a trade-off to be made and this document will express some requirements related to this trade- off. Morin Expires July 22, 2006 [Page 10] Internet-Draft L3VPN Mcast Reqs January 2006 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 were such high expectations were expressed in only a few answers. 4.1. Scenarios We don't provide here an exhaustive set of scenarios that a multicast VPN solution is expected to support - no solution should restrict the scope of multicast applications and deployments that can be done over a multicast VPN. Hence, we only give here a short list of scenarios that are expected to have a large impact on the design of a multicast VPN solution. 4.1.1. Live content broadcast Under this label, we group all applications that distribute content (audio, video, or other content) with the property that this content is expected to be consulted at once ("live") by the receiver. Typical applications are broadcast TV, production studios connectivity, 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 Morin Expires July 22, 2006 [Page 11] Internet-Draft L3VPN Mcast Reqs January 2006 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 number of provider equipments deployed close to VPN customers 4.1.2. Symmetric applications Some use cases exposed by the survey can be grouped under this label, and include many-to-many applications such as conferencing, server clusters monitoring. They are characterised 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. Because of: Morin Expires July 22, 2006 [Page 12] Internet-Draft L3VPN Mcast Reqs January 2006 o small groups, and low predictability of the location of participants ("sparse groups") o possibly significantly high bandwidth (a few Mb/s per participant) ...optimizing bandwidth may require introducing dedicated states in the core network (typically as much as the number of groups). Lastly, some of these applications may involve realtime interactions, and will be highly sensitive to packet loss, jitter and delay. 4.1.3. Data distribution Some applications which are expected to be deployed on multicast VPNs are non-realtime 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 bandwidth and to be robust to packet loss, jitter and delay. One important property is that such applications may involve higher bandwidths (hundreds of Mb/s). 4.1.4. Generic multicast VPN offer This ISP scenario is a deployment scenario where IP-Multicast connectivity is proposed for every VPN: if a customer requests a VPN, then this VPN will support IP-Multicast by default. In this case the number of multicast VPNs equals the number of VPNs. This implies a quite important scalability requirement (e.g. hundreds of PEs, hundreds of VPNs per PE, with a potential increase by one order of magnitude in the future). The per mVPN traffic behavior is not predictable because it's completely up to the customer how the service is used. 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 a such 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. Morin Expires July 22, 2006 [Page 13] Internet-Draft L3VPN Mcast Reqs January 2006 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 -tens of VPNs- (7 answers) or in the higher range of hundreds or thousands of VPNs (2 + 4 answers). A solution SHOULD support a number of multicast VPNs ranging from one to several thousands. A solution SHOULD NOT limit the proportion of multicast VPNs among all (unicast) VPNs. 4.2.2. Number of multicast VPNs per PE The majority of survey answers express a number of multicast VPNs per PE of around tens (8 responses between 5 and 50); a significant number of them (4) expect deployments with hundreds or thousands (1 response) of multicast VPNs per PE. A solution SHOULD support a number of multicast VPNs per PE of several hundreds, and may have to scale up to thousands of VPNs per PE. 4.2.3. Number of CEs per multicast VPN per PE Survey responses span from 1 to 2000 CEs per multicast VPN per PE. Most typical responses are between tens (6 answers) and hundreds (4 responses). A solution SHOULD support a number of CEs per multicast VPN per PE going up to several hundreds (and may target the support of thousands of CEs). 4.2.4. PEs per multicast VPN People who answered the survey typically expect deployments with number of PEs per multicast VPN in the range of hundreds of PEs (6 Morin Expires July 22, 2006 [Page 14] Internet-Draft L3VPN Mcast Reqs January 2006 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 of tens of source-connected-PEs (6 responses), or hundreds (4 responses). One respondent expected a higher number of several thousands. A solution SHOULD support hundreds of source-connected-PEs per VPN, and some deployment scenarios involving many-to-many applications, may require supporting a number of source-connected-PEs equal to the number of PEs (hundreds or thousands). 4.2.4.2. ... with receivers The survey showed that the number of PEs with receivers is expected to be of the same order of magnitude as the number of PEs in a multicast VPN. This is consistent with the intrinsic nature of most multicast applications, which have few source only participants. 4.2.5. PEs with multicast VRFs A solution SHOULD scale up to thousands of PEs having multicast service enabled. 4.2.6. Number of streams sourced Survey responses led us to retain the following orders of magnitude for the number of streams that a solution SHOULD support: per VPN: hundreds or thousands of streams per PE: hundreds of streams Morin Expires July 22, 2006 [Page 15] Internet-Draft L3VPN Mcast Reqs January 2006 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 feature compared to those required for multicast in a non-VPN context. Enabling a VPN for multicast support SHOULD be possible with no (or very limited impact) on existing multicast protocols possibly already deployed on the CE devices. 5.1.2. CE-PE Multicast routing and 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 SHOULD include: [PIM-SM], bidirectional PIM [I-D.ietf- pim-bidir], PIM-DM [RFC3973], and IGMPv3 [RFC3376] (this version implicitely supports hosts that only implements IGMPv1 [RFC1112] or IGMPv2 [RFC2236]). Among those protocols, the support of PIM-SM (version 2, revised, which includes SSM model) and either IGMP v.3 (for IPv4 solutions) and / or MLDv.2 [RFC3810] (for IPv6 solutions) are REQUIRED. Bidir- PIM Support at the PE-CE interface is RECOMMENDED. And considering deployments, PIM-DM is considered as 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 MLD v.2, and PIM-SM IPv6 specific procedures. Morin Expires July 22, 2006 [Page 16] Internet-Draft L3VPN Mcast Reqs January 2006 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(SLA). 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 same 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. Morin Expires July 22, 2006 [Page 17] Internet-Draft L3VPN Mcast Reqs January 2006 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 have also 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. SLA parameters measurement As Service Level Agreement (SLA) parameters are part of the service that is sold, they are often monitored. The monitoring is used for technical reasons by the service provider and is often sold to the customer for end-to-end service purposes. The solution MUST support SLA monitoring capabilities, which MAY rely upon techniques similar to those used for the unicast service for the same monitoring purposes. Multicast specific characteristics that may be monitored are, for instance, multicast statistics per stream, end-to-end delay and group join delay (time to start receiving a multicast group traffic across the VPN, as defined in [RFC2432] section 3). A generic discussion of SLAs is provided in [RFC3809]. 5.1.5. Security Requirements Security is a key point for a customer who uses subscribes to a VPN service. The [RFC2547bis] 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 Morin Expires July 22, 2006 [Page 18] Internet-Draft L3VPN Mcast Reqs January 2006 multicast traffic of a client group to a larger set of PE routers that may include PEs which 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. Monitoring and Troubleshooting A service provider and its customers MUST be able to manage the capabilities and characteristics of their multicast VPN services. Automated operations and interoperability with standard management platforms SHOULD be supported. Service management should also include the "FCAPS" functionalities: Fault management, Configuration, Accounting, Performance, and Security. The monitoring of multicast specific parameters and statistics MUST include multicast traffic statistics: total traffic conveyed, incoming, outgoing, dropped, etc., by period of time ; and 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. Apart from statistics on multicast traffic, customers of a multicast VPN will need information concerning the status of their multicast resource usage (state 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 and produced at a client site, and so a multicast VPN solution SHOULD allow customers to find out their current resource usage (state 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 via the ISP customer support, needs further discussion. 5.1.7. Extranet In current PP L3VPN models, a customer site may be setup to be part of multiple VPNs and this should still be possible when a VPN is multicast-enabled. In practice it means a VRF or VR will be part of more than one VPN. A multicast VPN solution MUST support such deployments. More precisely this means that a multicast VPN solution MUST offer Morin Expires July 22, 2006 [Page 19] Internet-Draft L3VPN Mcast Reqs January 2006 means so that: o receivers behind attached CEs can receive multicast traffic sourced in any of the VPNs (if security policy permits) o sources behind attached CEs can reach multicast traffic receivers located in any of the VPNs o multicast can be independently enabled for the different VPNs (and multicast reception and emission can also be independently enabled) Moreover, a solution MUST allow to control an extranet multicast connectivity independently from the extranet unicast connectivity. Proper support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link, whether it is a physical or logical link. 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. 5.1.8. Internet Multicast Connectivity with Internet Multicast (as a source or receiver) is a particular case of the previous section. It should be considered OPTIONAL given the additional considerations, such as security, needed to fulfill the requirements for providing Internet Multicast. 5.1.9. Carrier's carrier Many L3 PPVPN solutions, such as [RFC2547bis] and [VRs] define the "Carrier's Carrier" model, where a "carrier's carrier" service provider supports one or more customer ISP, 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. Morin Expires July 22, 2006 [Page 20] Internet-Draft L3VPN Mcast Reqs January 2006 In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs [RFC2547bis], 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.10. 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 failover. 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 failover. On the other hand, it is also necessary to care about failover mechanisms that are unique to multicast routing control. For instance, if the customer uses some control mechanism for RP redundancy on PIM-SM (e.g. BSR), it SHOULD work transparently through that VPN. 5.1.11. RP Engineering When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer side, the location of the RP has to be chosen. In some cases this engineering problem is not trivial: for instance, 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 is obviously not ideal. A multicast VPN solution SHOULD propose a way to help on solving this RP engineering issue. Moreover, some service providers offer to manage customer's multicast protocol operation on behalf of them. This implies that it is necessary to consider cases where the customer's RPs are outsourced (e.g., on PEs). 5.1.12. 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 Morin Expires July 22, 2006 [Page 21] Internet-Draft L3VPN Mcast Reqs January 2006 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 which are to be used only inside the VPN, and of or SSM-range addresses (232/8 as defined by [I-D.ietf-ssm- arch]) or globally assigned group addresses (e.g. GLOP [RFC3180], 233/8) for services for which traffic may be transmitted outside the VPN . 5.1.13. Minimum MTU For customers, it is often a serious issue whether transmitted packets will be fragmented or not. 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 let customers' devices be free of any fragmentation or reassembly activity. A committed minimum path MTU size SHOULD be provided to customers. Moreover, since Ethernet LAN segments are often located at first and last hops, a minimum 1500 bytes IP MTU SHOULD be provided. It SHOULD also be compatible with Path MTU discovery mechanisms, such as those defined in [RFC1191] or [I-D.savola-mtufrag-network- tunneling]. 5.2. Service provider standpoint Note: please remember that, 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 possibly existing deployments of multicast 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 [RFC2547bis] and [VRs] [I-D.ietf-l3vpn-vpn-vr] models, a P router Morin Expires July 22, 2006 [Page 22] Internet-Draft L3VPN Mcast Reqs January 2006 sees a number of MPLS tunnels that is only linked to the number of PEs and not to the number of VPNs, or customers' 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 the number of any of the following: o the number of PEs o the number of customers 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 to add or remove a customer site (or a customer from a multicast session) Morin Expires July 22, 2006 [Page 23] Internet-Draft L3VPN Mcast Reqs January 2006 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 impacts 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 in VPNs 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 same data travels twice or more on a same 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 the service providers appropriate configuration settings that let them tune the trade-off according to their peculiar constraints (network topology, platforms, customer applications, level of service offered Morin Expires July 22, 2006 [Page 24] Internet-Draft L3VPN Mcast Reqs January 2006 etc.). As an illustration here are some example bounds of the trade-off space: Bandwidth optimization: setting up somehow optimal core MDTunnels whose topology (PIM or P2MP LSP trees, etc.) precisely follows customer's multicast routing changes. This requires managing an important quantity of states 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 bad 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 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 a 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 Morin Expires July 22, 2006 [Page 25] Internet-Draft L3VPN Mcast Reqs January 2006 the forwarding plane, a multicast VPN solution SHOULD be designed so that control and forwarding planes are not inter-dependent: the control plane SHALL NOT depend on which forwarding plane is used (and vice versa), and the choice of forwarding plane SHOULD NOT be limited by the design of the solution. The solution SHOULD also 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 privileged: 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 (multicast distribution tunnels, the means used to carry VPNs' multicast traffic over the provider network), a solution SHOULD be able to use a range of tunneling technologies, including point-to-point and point-to-multipoint, such as GRE [RFC2784] (including GRE in multicast IP trees), MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP extensions to RSVP [I-D.ietf-mpls-rsvp-te-p2mp] or LDP [I-D.leroux- mpls-mp-ldp-reqs][I-D.minei-wijnands-mpls-ldp-p2mp]), L2TP (including L2TP for multicast [RFC4045]), IPsec [RFC4031], IP-in-IP [RFC2003], etc. Naturally, it is RECOMMENDED that a solution is built so that it can use the point to multipoint variants of these techniques, that allow for packet replications to happen along a tree in the provider core network, and may help improve bandwidth efficiency in our 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 tell MTU with signaling, etc.) so that: o fragmentation inside the MDTunnel -even when allowed by the tunneling technology used- does not happen o proper troubleshooting can be done if packets too big for the MDTunnel happen to be encapsulated in the MDTunnel 5.2.5. Control mechanisms The solution MUST provide some mechanisms to control the sources within a VPN. This control includes the number of sources that are entitled to send traffic on the VPN, and/or the total bit rate of all Morin Expires July 22, 2006 [Page 26] Internet-Draft L3VPN Mcast Reqs January 2006 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 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 RFC2547bis [I-D.ietf-l3vpn-rfc2547bis]) 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 co-ordination to setup such a tunnel is minimized Moreover such support SHOULD be possible without compromising other requirements expressed in this requirement document, and SHALL NOT incur penalty on scalability and bandwidth usage. 5.2.7. Quality of Service Differentiation A multicast VPN solution SHOULD give a VPN service provider the Morin Expires July 22, 2006 [Page 27] Internet-Draft L3VPN Mcast Reqs January 2006 ability to offer, guarantee and enforce differentiated levels of QoS for its different customers. 5.2.8. Infrastructure security The solution shall provide the same level of security for the service provider as what currently exist for unicast VPNs. For instance, that means that the intrinsic protection against DOS and DDOS attacks of the BGP/MPLS VPN solution must be equally 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 the 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. Unwanted multicast traffic (e.g. multicast traffic that may be sent by a source located somewhere in the Internet and for which there is no interested receiver connected to a given VPN infrastructure) MUST NOT be propagated within a multicast-enabled VPN. Security considerations are particularly important for inter-AS and inter-provider deployments. In a such perspective, it is RECOMMENDED that a multicast VPN solution support means to ensure the integrity and authenticity of multicast-related exchanges across inter-ASes 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 Systems Border Routers) or a subset of them, and optionally BGP Route Reflectors (or a subset of them). Last, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view. Morin Expires July 22, 2006 [Page 28] Internet-Draft L3VPN Mcast Reqs January 2006 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 setup MDTunnels. In such a case, the PIM RP might be a single point of failure. Such a solution should thus be compatible with a solution implementing RP resiliency, such as anycast-RP [I-D.ietf-pim-anycast-rp] or BSR [I-D.ietf-pim-sm-bsr] . 5.2.10. Management tools, OAM The operation of a multicast VPN solution SHALL be as light as possible and providing automatic configuration and discovery SHOULD be prioritized. Particularly the operational cost of setting up multicast on a PE 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 unicast VPN, the balance between their advantage and operation burden should be examined thoroughly. Moreover, monitoring of multicast specific parameters and statistics SHOULD be offered to the service provider. Most notably the provider SHOULD have access to: o Multicast traffic statistics (total traffic conveyed, incoming, outgoing, dropped, etc., by period of time) - Information about client multicast resource usage (state and throughput) 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 Alarms when limits are reached on such resources - 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 Morin Expires July 22, 2006 [Page 29] Internet-Draft L3VPN Mcast Reqs January 2006 All or part of this information SHOULD be made available through standardized SNMP ([RFC1441], [RFC3411]) MIBs (Management Information Bases). 5.2.11. Compatibility and migration issues It is a requirement that unicast and multicast services MUST be able to co-exist within the same VPN. Likewise, the introduction of IP multicast VPN capabilities in devices that participate to the deployment and the maintenance of a multicast VPN SHOULD be as smooth as possible, i.e. without affecting the overall quality provided with the services that are already supported by the underlying infrastructure. A multicast VPN solution SHOULD prevent compatibility and migration issues, for instance by prioritizing mechanisms facilitating forward compatibility. Most notably a solution supporting only a subset of those requirements SHOULD be designed to be compatible with future enhanced revisions. It SHOULD be an aim of any multicast VPN solution to offer as much backward compatibility as possible. Ideally a solution would have be the ability to offer multicast VPN services across a network containing some legacy routers not supporting 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 such and such 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 usefully provide some mechanism letting network operators check that all VPN sites that advertised interest in a particular customer multicast stream are properly associated with the corresponding MDTunnel. Providing the operators with means to check the proper setup and operation of MDTunnels MAY also be Morin Expires July 22, 2006 [Page 30] Internet-Draft L3VPN Mcast Reqs January 2006 provided (e.g. when MPLS is used for MDTunnels, integrating mechanisms such as LSPPing[I-D.ietf-mpls-lsp-ping][I-D.ietf-mpls- p2mp-lsp-ping] into the L3VPN troubleshooting functionalities will be desirable). Depending on the implementation such verification could be initiated by source-PE or receiver-PE. Morin Expires July 22, 2006 [Page 31] Internet-Draft L3VPN Mcast Reqs January 2006 6. Security Considerations This document does not by itself raise any particular security issue. A set of security issues have been identified that MUST be addressed when considering the design and deployment of multicast-enabled VPN networks. Such issues have been described in Section 5.1.5 and Section 5.2.8. Morin Expires July 22, 2006 [Page 32] Internet-Draft L3VPN Mcast Reqs January 2006 7. IANA Considerations This document has no actions for IANA. Morin Expires July 22, 2006 [Page 33] Internet-Draft L3VPN Mcast Reqs January 2006 8. Acknowledgments The authors would like to thank, by rough chronological order, Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka Savola, Benjamin Niven-Jenkins, 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. Morin Expires July 22, 2006 [Page 34] Internet-Draft L3VPN Mcast Reqs January 2006 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. [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [I-D.ietf-pim-sm-v2-new] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11 (work in progress), October 2004. 9.2. Informative references [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [I-D.ietf-l3vpn-rfc2547bis] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 (work in progress), October 2004. [I-D.ietf-l3vpn-vpn-vr] Morin Expires July 22, 2006 [Page 35] Internet-Draft L3VPN Mcast Reqs January 2006 Knight, P., Ould-Brahim, H., and B. Gleeson, "Network based IP VPN Architecture using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02 (work in progress), April 2004. [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-07 (work in progress), October 2005. [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. [I-D.ietf-mpls-rsvp-te-p2mp] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-03 (work in progress), October 2005. [I-D.ietf-pim-sm-bsr] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", draft-ietf-pim-sm-bsr-06 (work in progress), October 2005. [I-D.ietf-pim-anycast-rp] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", draft-ietf-pim-anycast-rp-04 (work in progress), August 2005. [I-D.minei-wijnands-mpls-ldp-p2mp] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00 (work in progress), October 2005. [I-D.leroux-mpls-mp-ldp-reqs] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs-02 (work in progress), October 2005. [I-D.ietf-pim-bidir] Morin Expires July 22, 2006 [Page 36] Internet-Draft L3VPN Mcast Reqs January 2006 Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (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. [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. [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. [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. [RFC1441] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to version 2 of the Internet-standard Network Management Framework", RFC 1441, April 1993. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Morin Expires July 22, 2006 [Page 37] Internet-Draft L3VPN Mcast Reqs January 2006 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [I-D.ietf-mpls-lsp-ping] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping-13 (work in progress), January 2006. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [I-D.ietf-mpls-p2mp-lsp-ping] Yasukawa, S., "Detecting Data Plane Failures in Point-to- Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-00 (work in progress), September 2005. [I-D.savola-mtufrag-network-tunneling] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", draft-savola-mtufrag-network-tunneling-05 (work in progress), October 2005. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Morin Expires July 22, 2006 [Page 38] Internet-Draft L3VPN Mcast Reqs January 2006 URIs [3] [4] [5] [6] [7] [8] Morin Expires July 22, 2006 [Page 39] Internet-Draft L3VPN Mcast Reqs January 2006 Appendix A. Requirements summary This section is a summary of all requirements expressed as MUST or SHOULD, proposed for quick reference. Please keep in mind that the full text of corresponding sections is the one reference, and refer to it to uncover any ambiguity in the summaries below. A.1. General Requirements (Section 3) o SHOULD satisfy requirements documented in RFC4031 "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)" o MUST interoperate seamlessly with current unicast solutions A.2. Scalability orders of magnitude (Section 4.2) A multicast VPN solution... o SHOULD support a number of multicast VPNs ranging from one to several thousands o SHOULD support a number of multicast VPNs per PE of several hundreds, and may have to scale up to thousands VPNs per PE o 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) o SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands o 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) o SHOULD scale up to thousands of PEs having multicast service enabled o SHOULD support hundreds or even thousands of streams sourced per VPN o SHOULD support hundreds of streams sourced per PE Morin Expires July 22, 2006 [Page 40] Internet-Draft L3VPN Mcast Reqs January 2006 A.3. Requirements from mutlicast VPN customer standpoint (Section 5.1) o Service definition * the multicast service MUST be provider provisioned and SHALL NOT require customer devices (CEs) to support any extra feature compared to those required for multicast in a non-VPN context o CE-PE Protocols * CEs and PEs SHOULD employ existing multicast protocols * the support of PIM-SM (including SSM model) and IGMP is REQUIRED * Bidir-PIM support is RECOMMENDED * when IPv6 is supported by a VPN solution, relevant IPv6 corresponding protocols SHOULD also be supported / MLD support is REQUIRED for IPv6 implementations o QoS Requirements * the level of availability for the multicast service SHOULD be on par with what exists for unicast traffic * same traffic protection mechanisms SHOULD be available for customer multicast traffic when it is carried over the service provider's network. * DiffServ mechanisms that include multicast traffic identification, classification and marking capabilities, as well as multicast traffic policing, scheduling and conditioning capabilities, MUST be supported * it is RECOMMENDED that a multicast VPN solution be designed appropriately with regards to group join delay performance * it SHOULD be possible to tune the multicast routing or group management protocol used on the PE-CE adjacency to reduce the group leave delay to the minimum * a multicast VPN solution SHOULD as much as possible ensure that client multicast packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network Morin Expires July 22, 2006 [Page 41] Internet-Draft L3VPN Mcast Reqs January 2006 * packet loss issues 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 o SLA Parameters measurements * a multicast VPN solution MUST support SLA monitoring capabilities o Security Requirements * a multicast VPN solution MUST provide an architecture with the same level of security for both unicast and multicast traffic * the activation of multicast features SHOULD be possible: + with a VRF or VR granularity + with a CE granularity (when multiple CE of a same VPN are connected to a common VRF) + with a distinction between multicast reception and emission + with a multicast group and/or channel granularity o Monitoring and troubleshooting * a service provider and its customers MUST be able to manage the capabilities and characteristics of their multicast VPN services * automated operations and interoperability with standard management platforms SHOULD be supported * the monitoring of multicast specific parameters and statistics MUST include multicast traffic statistics: total traffic conveyed, incoming, outgoing, dropped, etc., by period of time * a multicast VPN solution SHOULD allow customers to find out their current resource usage and to receive some kind of feedback if their usage exceed bounds o Extranet * a multicast VPN solution MUST support deployments where VRFs or VR are part of more than one multicast VPN Morin Expires July 22, 2006 [Page 42] Internet-Draft L3VPN Mcast Reqs January 2006 * a multicast VPN solution MUST offer means so that: + receivers behind attached CEs can receive multicast traffic sourced in any of the VPNs + sources behind attached CEs can reach multicast traffic receivers located in any of the VPNs + multicast can be independently enabled for the different VPNs * support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link o Carrier's carrier * A multicast VPN solution SHOULD support the carrier's carrier model in a scalable and efficient manner * the protocols that may be used at the PE-CE level SHOULD NOT be restricted to protocols required as per Section 5.1.2 (CE-PE Multicast routing and management protocols) and SHOULD include some of the protocols listed in Section 5.2.3 (Tunneling Requirements) * in the context of MPLS-based L3VPN deployments, some MPLS label distribution SHOULD happen at the PE-CE level o Multihoming * a multicast VPN solution SHOULD be able to offer multi-homing, CE-PE link load balancing and failover * a multicast VPN solution SHOULD support redundant topology of CE-PE links * a multicast VPN solution SHOULD minimize multicast traffic disruption and failover * if the customer uses some control mechanism for RP redundancy on PIM-SM (e.g. BSR), it SHOULD work transparently through that VPN o RP Engineering * a multicast VPN solution SHOULD propose a way to help in solving the RP engineering issue in a VPN context Morin Expires July 22, 2006 [Page 43] Internet-Draft L3VPN Mcast Reqs January 2006 o Addressing * a multicast VPN solution SHOULD NOT impose restrictions on multicast group addresses used by VPN customers * 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 o Minimum MTU * a multicast VPN solution SHOULD let customers' devices be free of any fragmentation or reassembly activity * a committed minimum path MTU size SHOULD be provided to customers * a minimum 1500 bytes IP MTU SHOULD be provided * a multicast VPN solution SHOULD also be compatible with Path MTU discovery mechanisms A.4. Requirements from provider standpoint o Scalability * solutions MUST be designed to scale well with an increase in the number of any of the following: + the number of PEs + the number of customers VPNs (total and per PE) + the number of PEs and sites in any VPN + the number of client multicast channels (groups or source- groups) * scalability of both performance and operation MUST be considered * key considerations SHOULD include: + the processing resources required by the control plane (neighborhood or session maintenance messages, keep-alives, Morin Expires July 22, 2006 [Page 44] Internet-Draft L3VPN Mcast Reqs January 2006 timers, etc.) + the memory resources needed for the control plane + the amount of protocol information transmitted to manage a multicast VPN (e.g. signaling throughput) + the amount of control plane processing required on PE and P to add remove a customer site (or a customer from a multicast session) + the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel) + other particular elements inherent to each solution that impacts 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) * solutions SHOULD offer the possibility of sharing core resources between different multicast streams o Resource optimization * a multicast VPN solution SHOULD offer the service providers appropriate configuration settings that let them tune the bandwidth/state trade-off according to their peculiar constraints o Traffic Engineering * a multicast VPN solution supporting TE for unicast traffic SHOULD also be able to provide traffic engineering features for the MDTunnels * a solution SHOULD offer means to support key TE objectives as defined in RFC3272 "Overview and Principles of Internet Traffic Engineering" o Tunneling * a multicast VPN solution SHOULD be designed so that control and forwarding planes are not inter-dependent * the control plane SHALL NOT depend on which forwarding plane is used (and vice versa) Morin Expires July 22, 2006 [Page 45] Internet-Draft L3VPN Mcast Reqs January 2006 * the choice of forwarding plane SHOULD NOT be limited by the design of the solution * solution SHOULD also NOT be tied to a specific tunneling technology * a multicast VPN solution extending a unicast L3 PPVPN solution, consistency in the tunneling technology has to be privileged: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast * a solution SHOULD be able to use a range of tunneling technologies for MDTunnels, including point-to-point and point- to-multipoint, such as [please refer to section Section 5.2.4] * it is RECOMMENDED that a solution is built so that it can use the point to multipoint variants of these techniques * a solution SHOULD support a method that provides the minimum path MTU of the MDTunnel o Control mechanisms * a solution MUST provide some mechanisms to control the sources within a VPN * a solution MUST 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 o Inter-As, inter-provider * a multicast VPN solution MUST support inter-AS VPNs * a multicast VPN solution SHOULD support inter-provider VPNs * a multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers * 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 Morin Expires July 22, 2006 [Page 46] Internet-Draft L3VPN Mcast Reqs January 2006 * 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 co-ordination to setup such a tunnel is minimized * such support SHOULD be possible without compromising other requirements expressed in this requirement document, and SHALL NOT incur penalty on scalability and bandwidth usage o QoS differentiation * a multicast VPN solution SHOULD give a provider the ability to offer, guarantee and enforce differentiated levels of QoS for different customers. o Infrastructure security * some mechanism SHOULD be proposed so that the frequency of changes in the way client traffic is carried over the core can be bounded * a multicast VPN solution SHOULD either avoid single points of failures or propose some technical solution making possible to implement a failover mechanism * it is RECOMMENDED that a multicast VPN solution support means to ensure the integrity and authenticity of multicast-related exchanges across inter-ASes or inter-provider borders o Robustness * a multicast VPN solution SHOULD whether avoid single points of failures or propose some technical solution making possible to implement a failover mechanism o Management tools, OAM * automatic configuration and discovery SHOULD be prioritized * monitoring of multicast specific parameters and statistics SHOULD be offered to the service provider * the provider SHOULD have access to: + multicast traffic statistics + IP Performance Metrics-related information that is relevant to the multicast traffic usage Morin Expires July 22, 2006 [Page 47] Internet-Draft L3VPN Mcast Reqs January 2006 + alarms when limits are reached + statistics on parameters that could help the provider to evaluate its optimality/state trade-off * this information SHOULD be made available through standardized SNMP o Compatibility and migration issues * unicast and multicast services MUST be able to co-exist within the same VPN * the introduction of IP multicast VPN capabilities in devices that participate to the deployment and the maintenance of a multicast VPN SHOULD be as smooth as possible * a multicast VPN solution SHOULD prevent compatibility and migration issues * it SHOULD be an aim of any multicast VPN solution to offer as much backward compatibility as possible * a solution SHOULD state a migration policy from possibly existing deployments o Troubleshooting * a multicast VPN solution SHOULD provide monitoring information describing how client traffic is carried over the network Morin Expires July 22, 2006 [Page 48] Internet-Draft L3VPN Mcast Reqs January 2006 Appendix B. Changelog This section lists changes made to this document (minor or editorial changes excepted) between major revisions. It shall be removed before publication as an RFC. B.1. Changes between -00 and -01 o integrated comments made on L3VPN WG mailing list after -00 submission o completed Carrier's carrier section (5.1.9) o updates in sections 5.1 and 5.2 about minimum MTU o added a section about "Quality of Service Differentiation" as ISP requirement (section 5.2.5) o added P2MP LDP extensions as possible MDTunnels techniques (section 5.2.3.1) o started to build section 4 "Use Case" o detailed section 5.1.3 "QoS", most notably about group join and leave delays o additions to section 5.2.12 "Inter-AS, inter-provider" o added MDTunnel verification requirement to section 5.2.11 o moved "Architectural Considerations" section o moved contributors to top of document o made draft content agnostic to unicast L3VPN solutions o added two appendixes: "Changelog" and "Requirement summary" o conversion to XML [RFC2629] with the help of some scripting and Bill Fenner's xml2rfc XMLMind plugin o lot's of editorial changes B.2. Changes between -01 and -02 Morin Expires July 22, 2006 [Page 49] Internet-Draft L3VPN Mcast Reqs January 2006 o based on survey results: * restructure use case scenario section * fill in Scalability orders of magnitude section * better detail requirements for protocols at the PE-CE level * add considerations about PEs with scarce connectivity to section 5.2.3.3 * step up requirement level for Extranet (Section 5.1.7) o some editorial changes o use capitalized wording for some requirements o fill in requirements summary (Appendix A) B.3. Changes between -02 and -03 o made inter-AS a MUST (and moved the whole section up) o add a requirement about security of multicast-related exchanges across providers/ASes, in Section 5.2.8 o some editorial changes and fixed typos B.4. Changes between -03 and -04 o FIXME [integrated comments from Yakov, Marshall, Pekka, and Benjaminh ] o Removed institutions and company names from the long acknoledgments section. Morin Expires July 22, 2006 [Page 50] Internet-Draft L3VPN Mcast Reqs January 2006 Author's Address Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France Email: thomas.morin@rd.francetelecom.com Morin Expires July 22, 2006 [Page 51] Internet-Draft L3VPN Mcast Reqs January 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Morin Expires July 22, 2006 [Page 52]