idnits 2.17.1 draft-ietf-l3vpn-ppvpn-mcast-reqts-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1766. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2006) is 6532 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PIM-SM' is mentioned on line 268, but not defined == Missing Reference: 'VRs' is mentioned on line 962, but not defined == Unused Reference: 'RFC2362' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ssm-arch' is defined on line 1449, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-mp-ldp-reqs' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: 'RFC3353' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-p2mp-lsp-ping' is defined on line 1586, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4031 ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Experimental RFC: RFC 3973 ** Downref: Normative reference to an Informational RFC: RFC 4176 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-05 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-08 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-00 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-08 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-21 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 l3vpn Working Group T. Morin, Ed. 3 Internet-Draft France Telecom R&D 4 Expires: November 30, 2006 May 29, 2006 6 Requirements for Multicast in L3 Provider-Provisioned VPNs 7 draft-ietf-l3vpn-ppvpn-mcast-reqts-08 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 30, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document presents a set of functional requirements for network 41 solutions that allow the deployment of IP multicast within L3 42 Provider Provisioned virtual private networks (PPVPNs). It specifies 43 requirements both from the end user and service provider standpoints. 44 It is intended that potential solutions specifying the support of IP 45 multicast within such VPNs will use these requirements as guidelines. 47 Working group 48 This document is a product of the IETF's Layer 3 Virtual Private 49 Network (l3vpn) working group. Comments should be addressed to WG's 50 mailing list at . The charter for l3vpn may 51 be found at 53 Contributors 55 Main contributors to this document are listed below, in alphabetical 56 order: 58 o Christian Jacquenet 59 France Telecom 60 3, avenue Francois Chateau 61 CS 36901 35069 RENNES Cedex, France 62 Email: christian.jacquenet@francetelecom.com 64 o Yuji Kamite 65 NTT Communications Corporation 66 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 67 Tokyo 163-1421, Japan 68 Email: y.kamite@ntt.com 70 o Jean-Louis Le Roux 71 France Telecom R & D 72 2, avenue Pierre-Marzin 73 22307 Lannion Cedex, France 74 Email: jeanlouis.leroux@francetelecom.com 76 o Nicolai Leymann 77 T-Systems International GmbH 78 Engineering Networks, Products & Services 79 Goslarer Ufer 3510589 Berlin, Germany 80 Email: nicolai.leymann@t-systems.com 82 o Renaud Moignard 83 France Telecom R & D 84 2, avenue Pierre-Marzin 85 22307 Lannion Cedex, France 86 Email: renaud.moignard@francetelecom.com 88 o Thomas Morin 89 France Telecom R & D 90 2, avenue Pierre-Marzin 91 22307 Lannion Cedex, France 92 Email: thomas.morin@francetelecom.com 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 97 2. Conventions used in this document . . . . . . . . . . . . . . 6 98 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 99 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 100 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 101 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 8 102 3.2. General Requirements . . . . . . . . . . . . . . . . . . . 8 103 3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 9 104 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 105 4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 10 106 4.1.1. Live content broadcast . . . . . . . . . . . . . . . . 10 107 4.1.2. Symmetric applications . . . . . . . . . . . . . . . . 11 108 4.1.3. Data distribution . . . . . . . . . . . . . . . . . . 12 109 4.1.4. Generic multicast VPN offer . . . . . . . . . . . . . 12 110 4.2. Scalability orders of magnitude . . . . . . . . . . . . . 13 111 4.2.1. Number of VPNs with multicast enabled . . . . . . . . 13 112 4.2.2. Number of multicast VPNs per PE . . . . . . . . . . . 13 113 4.2.3. Number of CEs per multicast VPN per PE . . . . . . . . 13 114 4.2.4. PEs per multicast VPN . . . . . . . . . . . . . . . . 13 115 4.2.5. PEs with multicast VRFs . . . . . . . . . . . . . . . 14 116 4.2.6. Number of streams sourced . . . . . . . . . . . . . . 14 117 5. Requirements for supporting IP multicast within L3 PPVPNs . . 15 118 5.1. End user/customer standpoint . . . . . . . . . . . . . . . 15 119 5.1.1. Service definition . . . . . . . . . . . . . . . . . . 15 120 5.1.2. CE-PE Multicast routing and group management 121 protocols . . . . . . . . . . . . . . . . . . . . . . 15 122 5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 16 123 5.1.4. Operations and Management . . . . . . . . . . . . . . 17 124 5.1.5. Security Requirements . . . . . . . . . . . . . . . . 18 125 5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 18 126 5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 19 127 5.1.8. Carrier's carrier . . . . . . . . . . . . . . . . . . 20 128 5.1.9. Multi-homing, load balancing and resiliency . . . . . 20 129 5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 20 130 5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 21 131 5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 22 132 5.2. Service provider standpoint . . . . . . . . . . . . . . . 22 133 5.2.1. General requirement . . . . . . . . . . . . . . . . . 22 134 5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 22 135 5.2.3. Resource optimization . . . . . . . . . . . . . . . . 24 136 5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 25 137 5.2.5. Control mechanisms . . . . . . . . . . . . . . . . . . 26 138 5.2.6. Support of Inter-AS, inter-provider deployments . . . 27 139 5.2.7. Quality of Service Differentiation . . . . . . . . . . 27 140 5.2.8. Infrastructure security . . . . . . . . . . . . . . . 28 141 5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 29 142 5.2.10. Operation, Administration and Maintenance . . . . . . 29 143 5.2.11. Compatibility and migration issues . . . . . . . . . . 30 144 5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 31 145 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 146 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 147 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 148 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 149 9.1. Normative references . . . . . . . . . . . . . . . . . . . 35 150 9.2. Informative references . . . . . . . . . . . . . . . . . . 35 151 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 40 152 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 40 153 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 40 154 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 41 155 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 41 156 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 42 157 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 42 158 A.7. Changes between -06 and -08 . . . . . . . . . . . . . . . 42 159 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 160 Intellectual Property and Copyright Statements . . . . . . . . . . 44 162 1. Introduction 164 VPN services satisfying the requirements defined in [RFC4031] are now 165 being offered by many service providers throughout the world. VPN 166 services are popular because customers need not be aware of the VPN 167 technologies deployed in the provider network. They scale well for 168 the following reasons: 170 o because P routers (Provider Routers) need not be aware of VPN 171 service details 173 o because the addition of a new VPN member requires only limited 174 configuration effort 176 There is also a growing need for support of IP multicast-based 177 services. Efforts to provide efficient IP multicast routing 178 protocols and multicast group management have been done in 179 standardization bodies which has led, in particular, to the 180 definition of the PIM and IGMP protocols. 182 However, multicast traffic is not natively supported within existing 183 L3 PPVPN solutions. Deploying multicast over an L3VPN today, with 184 only currently standardized solutions, requires designing customized 185 solutions which will be inherently limited in terms of scalability, 186 operational efficiency and bandwidth usage. 188 This document complements the generic L3VPN requirements [RFC4031] 189 document, by specifying additional requirements specific to the 190 deployment within PPVPNs of services based on IP multicast. It 191 clarifies the needs of both VPN clients and providers and formulates 192 the problems that should be addressed by technical solutions with the 193 key objective being to remain solution agnostic. There is no intent 194 to either specify solution-specific details in this document or 195 application-specific requirements. Also this document does NOT aim 196 at expressing multicast-related requirements that are not specific to 197 L3 PPVPNs. 199 It is expected that solutions that specify procedures and protocol 200 extensions for multicast in L3 PPVPNs SHOULD satisfy these 201 requirements. 203 2. Conventions used in this document 205 2.1. Terminology 207 Although the reader is assumed to be familiar with the terminology 208 defined in [RFC4031], [RFC4364], [PIM-SM], PIM-SSM [I-D.ietf-ssm- 209 arch] the following glossary of terms may be worthwhile. 211 Moreover we also propose here generic terms for concepts that 212 naturally appear when multicast in VPNs is discussed. 214 ASM: 215 Any Source Multicast. One of the two multicast service models, in 216 which a terminal subscribes to a multicast group to receive data 217 sent to the group by any source. 219 Multicast-enabled VPN, or multicast VPN: 220 a VPN which supports IP multicast capabilities, i.e. for which 221 some PE devices (if not all) are multicast-enabled and whose core 222 architecture supports multicast VPN routing and forwarding 224 PPVPN: 225 Provider-Provisioned Virtual Private Network 227 PE/CE: 228 "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As 229 suggested in [RFC4026], we will use these notations to refer to 230 the equipments/routers/devices themselves. Thus, "PE" will refer 231 to the router on the provider's edge, which faces the "CE", the 232 router on the customer's edge. 234 VRF or VR: 235 By this phrase, we refer to the entity defined in a PE dedicated 236 to a specific VPN instance. "VRF" refers to "VPN Routing and 237 Forwarding table" as defined in [RFC4364], and "VR" to "Virtual 238 Router" as defined in [VRs] terminology. 240 MD Tunnel: 241 Multicast Distribution Tunnel, the means by which the customer's 242 multicast traffic will be transported across the SP network. This 243 is meant in a generic way: such tunnels can be either point-to- 244 point or point-to-multipoint. Although this definition may seem 245 to assume that distribution tunnels are unidirectional, the 246 wording also encompasses bi-directional tunnels. 248 G: 249 Denotes a multicast group 251 Multicast channel: 252 In the multicast SSM model, "multicast channel" designate traffic 253 from a specific source S to a multicast group G. Also denominated 254 as (S,G). 256 S: 257 Denotes a multicast source 259 SP: 260 Service provider 262 SSM: 263 Source Specific Multicast. One of the two multicast service 264 models, where a terminal subscribes to a multicast group to 265 receive data sent to the group by a specific source. 267 RP: 268 Rendez-vous point ([PIM-SM]) 270 P2MP, MP2MP: Designate "Point to multipoint" and "Multipoint to 271 multipoint" replication trees. 273 L3VPN, VPN: 274 Throughout this document, "L3VPN" or even just "VPN" will refer to 275 "Provider-Provisioned Layer 3 Virtual Private Network" (PP 276 L3VPNs), and will be preferred for readability. 278 Please refer to [RFC4026] for details about terminology specifically 279 relevant to VPN aspects, and to [RFC2432] for multicast performance 280 or QoS related terms. 282 2.2. Conventions 284 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 285 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 286 document are to be interpreted as described in [RFC2119]. 288 3. Problem Statement 290 3.1. Motivations 292 More and more L3VPN customers use IP multicast services within their 293 private infrastructures. Naturally, they want to extend these 294 multicast services to remote sites that are connected via a VPN. 296 For instance, the customer could be a national TV channel with 297 several geographical locations that wants to broadcast a TV program 298 from a central point to several regional locations within its VPN. 300 A solution to support multicast traffic could consist of point-to- 301 point tunnels across the provider network and requires the PEs 302 (Provider's Edge routers) to replicate traffic. This would obviously 303 be sub-optimal as it would place the replication burden on the PE and 304 hence would have very poor scaling characteristics. It would also 305 probably waste bandwidth and control plane resources in the 306 provider's network. 308 Thus, to provide multicast services for L3VPN networks in an 309 efficient manner (that is, with a scalable impact on signaling and 310 protocol state as well as bandwidth usage), in a large scale 311 environment, new mechanisms are required to enhance existing L3VPN 312 solutions for proper support of multicast-based services. 314 3.2. General Requirements 316 This document sets out requirements for L3 provider-provisioned VPN 317 solutions designed to carry customers' multicast traffic. The main 318 requirement is that a solution SHOULD first satisfy the requirements 319 documented in [RFC4031]: as far as possible, a multicast service 320 should have the same characteristics as the unicast equivalent, 321 including the same simplicity (technology unaware), the same quality 322 of service (if any), the same management (e.g. monitoring of 323 performances), etc. 325 Moreover, it also has to be clear that a multicast VPN solution MUST 326 interoperate seamlessly with current unicast VPN solutions. It would 327 also make sense that multicast VPN solutions define themselves as 328 extensions to existing L3 provider-provisioned VPN solutions (such as 329 for instance, [RFC4364] or [VRs]) and retain consistency with those, 330 although this is not a core requirement. 332 The requirements in this document are equally applicable to IPv4 and 333 IPv6, for both customer and provider related matters. 335 3.3. Scaling vs. Optimizing Resource Utilization 337 When transporting multicast VPN traffic over a service provider 338 network, there intrinsically is tension between scalability and 339 resource optimization, since the latter is likely to require the 340 maintenance of control plane states related to replication trees in 341 the core network. 343 Consequently, any deployment will require a trade-off to be made and 344 this document will express some requirements related to this trade- 345 off. 347 4. Use cases 349 The goal of this section is to highlight how different applications 350 and network contexts may have a different impact on how a multicast 351 VPN solution is designed, deployed and tuned. For this purpose we 352 describe some typical use case scenarios and express expectations in 353 terms of deployment orders of magnitude. 355 Most of the content of these sections originates from a survey done 356 in summer 2005, among institutions and providers that expect to 357 deploy such solutions. The full survey text, and raw results (13 358 responses) were published separately and we only present here the 359 most relevant facts and expectations that the survey exposed. 361 For scalability figures, we considered that it was relevant to 362 highlight the highest expectations, those that are expected to have 363 the greatest impact on solution design ; for balance, we do also 364 mention cases where such high expectations were expressed in only a 365 few answers. 367 4.1. Scenarios 369 We don't provide here an exhaustive set of scenarios that a multicast 370 VPN solution is expected to support - no solution should restrict the 371 scope of multicast applications and deployments that can be done over 372 a multicast VPN. 374 Hence, we only give here a short list of scenarios that are expected 375 to have a large impact on the design of a multicast VPN solution. 377 4.1.1. Live content broadcast 379 Under this label, we group all applications that distribute content 380 (audio, video, or other content) with the property that this content 381 is expected to be consulted at once ("live") by the receiver. 382 Typical applications are broadcast TV, production studios 383 connectivity, distribution of market data feeds. 385 The characteristics of such applications are the following: 387 o one or few sources to many receivers 389 o sources are often in known locations, receivers are in less 390 predictable locations (this latter point may depend on 391 applications) 393 o in some cases, it is expected that the regularity of audience 394 patterns may help improve how the bandwidth/state trade-off is 395 handled 397 o the number of streams can be as high as hundreds, or even 398 thousands of streams 400 o bandwidth will depend on the application, but may vary between a 401 few tens/hundreds of Kb/s (e.g audio or low quality video media) 402 and tens of Mb/s (high quality video), with some demanding 403 professional applications requiring as much as hundreds of Mb/s. 405 o QoS requirements include, in many cases, a low multicast group 406 join delay 408 o QoS of these applications is likely to be impacted by packet loss 409 (some applications may be robust to low packet loss), and to have 410 low robustness against jitter 412 o delay sensitivity will depend on the application: some 413 applications are not so delay sensitive (e.g. broadcast TV), 414 whereas others may require very low delay (professional studio 415 applications) 417 o some of these applications may involve rapid changes in customer 418 multicast memberships as seen by the PE, but this will depend on 419 audience patterns and on the number of provider equipments 420 deployed close to VPN customers 422 4.1.2. Symmetric applications 424 Some use cases exposed by the survey can be grouped under this label, 425 and include many-to-many applications such as conferencing, server 426 clusters monitoring. 428 They are characterized by the relatively high number of streams that 429 they can produce, which has a direct impact on scalability 430 expectations. 432 A sub-case of this scenario is the case of symmetric applications 433 with small groups, when the number of receivers is low compared to 434 the number of sites in the VPNs (e.g.: video conferencing and 435 e-learning applications). 437 This latter case is expected to be an important input to solution 438 design, since it may significantly impact how the bandwidth/state is 439 managed. 441 Because of: 443 o small groups, and low predictability of the location of 444 participants ("sparse groups") 446 o possibly significantly high bandwidth (a few Mb/s per participant) 448 ...optimizing bandwidth may require introducing dedicated states in 449 the core network (typically as much as the number of groups). 451 Lastly, some of these applications may involve realtime interactions, 452 and will be highly sensitive to packet loss, jitter and delay. 454 4.1.3. Data distribution 456 Some applications which are expected to be deployed on multicast VPNs 457 are non-realtime applications aimed at distributing data from few 458 sources to many receivers. 460 Such applications may be considered to have lower expectations than 461 their counterparts proposed in this document, since they would not 462 necessarily involve more data streams and are more likely to adapt to 463 the available bandwidth and to be robust to packet loss, jitter and 464 delay. 466 One important property is that such applications may involve higher 467 bandwidths (hundreds of Mb/s). 469 4.1.4. Generic multicast VPN offer 471 This ISP scenario is a deployment scenario where IP-Multicast 472 connectivity is proposed for every VPN: if a customer requests a VPN, 473 then this VPN will support IP-Multicast by default. In this case the 474 number of multicast VPNs equals the number of VPNs. This implies a 475 quite important scalability requirement (e.g. hundreds of PEs, 476 hundreds of VPNs per PE, with a potential increase by one order of 477 magnitude in the future). 479 The per mVPN traffic behavior is not predictable because it's 480 completely up to the customer how the service is used. This results 481 in a traffic mix of the scenarios mentioned in section 4.1. QoS 482 requirements are similar to typical unicast scenarios, with the need 483 for different classes. Also in such a context, a reasonably large 484 range of protocols should be made available to the customer for use 485 at the PE-CE level. 487 Also, in such a scenario, customers may want to deploy multicast 488 connectivity between two or more multicast VPNs as well as access to 489 Internet Multicast. 491 4.2. Scalability orders of magnitude 493 This section proposes orders of magnitude for different scalability 494 metrics relevant for multicast VPN issues. It should be noted that 495 the scalability figures proposed here relate to scalability 496 expectations of future deployments of multicast VPN solutions, as the 497 authors chose to not restrict the scope to only currently known 498 deployments. 500 4.2.1. Number of VPNs with multicast enabled 502 From the survey results, we see a broad range of expectations. There 503 are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), 504 but more typical answers are split between the low range -tens of 505 VPNs- (7 answers) or in the higher range of hundreds or thousands of 506 VPNs (2 + 4 answers). 508 A solution SHOULD support a number of multicast VPNs ranging from one 509 to several thousands. 511 A solution SHOULD NOT limit the proportion of multicast VPNs among 512 all (unicast) VPNs. 514 4.2.2. Number of multicast VPNs per PE 516 The majority of survey answers express a number of multicast VPNs per 517 PE of around tens (8 responses between 5 and 50); a significant 518 number of them (4) expect deployments with hundreds or thousands (1 519 response) of multicast VPNs per PE. 521 A solution SHOULD support a number of multicast VPNs per PE of 522 several hundreds, and may have to scale up to thousands of VPNs per 523 PE. 525 4.2.3. Number of CEs per multicast VPN per PE 527 Survey responses span from 1 to 2000 CEs per multicast VPN per PE. 528 Most typical responses are between tens (6 answers) and hundreds (4 529 responses). 531 A solution SHOULD support a number of CEs per multicast VPN per PE 532 going up to several hundreds (and may target the support of thousands 533 of CEs). 535 4.2.4. PEs per multicast VPN 537 People who answered the survey typically expect deployments with 538 number of PEs per multicast VPN in the range of hundreds of PEs (6 539 responses) or tens of PEs (4 responses). Two responses were in the 540 range of thousands (one mentioned a 10k figure). 542 A multicast VPN solution SHOULD support several hundreds of PEs per 543 multicast VPN, and MAY usefully scale up to thousands. 545 4.2.4.1. ... with sources 547 The number of PEs, per VPN, that would be connected to sources, seems 548 to be significantly lower than the number of PEs per VPN. This is 549 obviously related to the fact that many respondents mentioned 550 deployments related to content broadcast applications (one to many). 552 Typical numbers are of tens of source-connected-PEs (6 responses), or 553 hundreds (4 responses). One respondent expected a higher number of 554 several thousands. 556 A solution SHOULD support hundreds of source-connected-PEs per VPN, 557 and some deployment scenarios involving many-to-many applications, 558 may require supporting a number of source-connected-PEs equal to the 559 number of PEs (hundreds or thousands). 561 4.2.4.2. ... with receivers 563 The survey showed that the number of PEs with receivers is expected 564 to be of the same order of magnitude as the number of PEs in a 565 multicast VPN. This is consistent with the intrinsic nature of most 566 multicast applications, which have few source only participants. 568 4.2.5. PEs with multicast VRFs 570 A solution SHOULD scale up to thousands of PEs having multicast 571 service enabled. 573 4.2.6. Number of streams sourced 575 Survey responses led us to retain the following orders of magnitude 576 for the number of streams that a solution SHOULD support: 578 per VPN: hundreds or thousands of streams 580 per PE: hundreds of streams 582 5. Requirements for supporting IP multicast within L3 PPVPNs 584 Again, the aim of this document is not to specify solutions but to 585 give requirements for supporting IP multicast within L3 PPVPNs. 587 In order to list these requirements we have taken the standpoint of 588 two different important entities: the end user (the customer using 589 the VPN) and the service provider. 591 In the rest of the document, by "a solution" or "a multicast VPN 592 solution", we mean a solution that allows multicast in an L3 593 provider-provisioned VPN, and which addresses the requirements listed 594 in this document. 596 5.1. End user/customer standpoint 598 5.1.1. Service definition 600 As for unicast, the multicast service MUST be provider provisioned 601 and SHALL NOT require customer devices (CEs) to support any extra 602 feature compared to those required for multicast in a non-VPN 603 context. Enabling a VPN for multicast support SHOULD be possible 604 with no (or very limited impact) on existing multicast protocols 605 possibly already deployed on the CE devices. 607 5.1.2. CE-PE Multicast routing and group management protocols 609 Consequently to Section 5.1.1, multicast-related protocol exchanges 610 between a CE and its directly connected PE SHOULD happen via existing 611 multicast protocols. 613 Such protocols include: PIM-SM [I-D.ietf-pim-sm-v2-new], 614 bidirectional-PIM [I-D.ietf-pim-bidir], PIM-DM [RFC3973], and IGMPv3 615 [RFC3376] (this version implicitly supports hosts that only 616 implements IGMPv1 [RFC1112] or IGMPv2 [RFC2236]). 618 Among those protocols, the support of PIM-SM (version 2, revised, 619 which includes SSM model) and either IGMP v.3 (for IPv4 solutions) 620 and / or MLDv.2 [RFC3810] (for IPv6 solutions) are REQUIRED. Bidir- 621 PIM Support at the PE-CE interface is RECOMMENDED. And considering 622 deployments, PIM-DM is considered as OPTIONAL. 624 When a multicast VPN solution is built on a VPN solution supporting 625 IPv6 unicast, it MUST also support v6 variants of the above 626 protocols, including MLD v.2, and PIM-SM IPv6 specific procedures. 627 For a multicast VPN solution built on a unicast VPN solution 628 supporting only IPv4, it is RECOMMENDED that the design favors the 629 definition of procedures and encodings that will provide an easy 630 adaptation to IPv6. 632 5.1.3. Quality of Service (QoS) 634 Firstly, general considerations regarding QoS in L3VPNs expressed in 635 section 5.5 of [RFC4031] are also relevant to this section. 637 QoS is measured in terms of delay, jitter, packet loss, and 638 availability. These metrics are already defined for the current 639 unicast PPVPN services, and are included in Service Level 640 Agreements(SLA). In some cases, the agreed SLA may be different 641 between unicast and multicast, and that will require differentiation 642 mechanisms in order to monitor both SLAs. 644 The level of availability for the multicast service SHOULD be on par 645 with what exists for unicast traffic. For instance same traffic 646 protection mechanisms SHOULD be available for customer multicast 647 traffic when it is carried over the service provider's network. 649 A multicast VPN solution SHALL allow a service provider to define at 650 least the same level of quality of service as exists for unicast, and 651 as exists for multicast in a non-VPN context. From this perspective, 652 the deployment of multicast-based services within an L3VPN 653 environment SHALL benefit from DiffServ [RFC2475] mechanisms that 654 include multicast traffic identification, classification and marking 655 capabilities, as well as multicast traffic policing, scheduling and 656 conditioning capabilities. Such capabilities MUST therefore be 657 supported by any participating device in the establishment and the 658 maintenance of the multicast distribution tunnel within the VPN. 660 As multicast is often used to deliver high quality services such as 661 TV broadcast, a multicast VPN solution MAY provide additional 662 features to support high QoS such as bandwidth reservation and 663 admission control. 665 Also, considering that multicast reception is receiver-triggered, 666 group join delay (as defined in [RFC2432]) is also considered one 667 important QoS parameter. It is thus RECOMMENDED that a multicast VPN 668 solution be designed appropriately in this regard. 670 The group leave delay (as defined in [RFC2432]) may also be important 671 on the CE-PE link for some usage scenarios: in cases where the 672 typical bandwidth of multicast streams is close to the bandwidth of a 673 PE-CE link, it will be important to have the ability to stop the 674 emission of a stream on the PE-CE link as soon as it stops being 675 requested by the CE, to allow for fast switching between two 676 different high throughput multicast streams. This implies that it 677 SHOULD be possible to tune the multicast routing or group management 678 protocols (e.g. IGMP/MLD or PIM) used on the PE-CE adjacency to 679 reduce the group leave delay to the minimum. 681 Lastly, a multicast VPN solution SHOULD as much as possible ensure 682 that client multicast traffic packets are neither lost nor 683 duplicated, even when changes occur in the way a client multicast 684 data stream is carried over the provider network. Packet loss issues 685 have also to be considered when a new source starts to send traffic 686 to a group: any receiver interested in receiving such traffic SHOULD 687 be serviced accordingly. 689 5.1.4. Operations and Management 691 The requirements and definitions for operations and management of 692 L3VPNs that are defined in [RFC4176] equally apply to multicast, and 693 are not extensively repeated in this document. This sub-section 694 mention most important guidelines and details points of particular 695 relevance in the context of multicast in L3VPNs. 697 A multicast VPN solution SHOULD allow a multicast VPN customer to 698 manage the capabilities and characteristics of their multicast VPN 699 services. 701 A multicast VPN solution MUST support SLA monitoring capabilities, 702 which SHOULD rely upon techniques similar to those used for the 703 unicast service for the same monitoring purposes. Multicast SLA- 704 related metrics SHOULD be available through similar means that the 705 ones already used for unicast-related monitoring, such as for 706 instance SNMP[RFC1441] or IPFIX[I-D.ietf-ipfix-protocol]. 708 Multicast specific characteristics that may be monitored are, for 709 instance, multicast statistics per stream, end-to-end delay, group 710 join/leave delay (time to start/stop receiving a multicast group 711 traffic across the VPN, as defined in [RFC2432], Section 3). 713 The monitoring of multicast specific parameters and statistics MUST 714 include multicast traffic statistics: total/incoming/outgoing/dropped 715 traffic, by period of time ; and MAY include IP Performance Metrics 716 related information (IPPM, [RFC2330]) that is relevant to the 717 multicast traffic usage: such information includes the one-way packet 718 delay, the inter-packet delay variation, etc. 720 A generic discussion of SLAs is provided in [RFC3809]. 722 Apart from statistics on multicast traffic, customers of a multicast 723 VPN will need information concerning the status of their multicast 724 resource usage (multicast routing states and bandwidth). Indeed, as 725 mentioned in Section 5.2.5, for scalability purposes, a service 726 provider may limit the number (and/or throughput) of multicast 727 streams that are received /sent to/from a client site. In such a 728 case, a multicast VPN solution SHOULD allow customers to find out 729 their current resource usage (multicast routing states and 730 throughput), and to receive some kind of feedback if their usage 731 exceeds the agreed bounds. Whether this issue will be better handled 732 at the protocol level at the PE-CE interface or at the Service 733 Management Level interface [RFC4176], is left for further discussion. 735 5.1.5. Security Requirements 737 Security is a key point for a customer who uses subscribes to a VPN 738 service. For instance, the [RFC4364] model offers some guarantees 739 concerning the security level of data transmission within the VPN. 741 A multicast VPN solution MUST provide an architecture with the same 742 level of security for both unicast and multicast traffic. 744 Moreover, the activation of multicast features SHOULD be possible: 746 o per VRF / per VR 748 o per CE interface (when multiple CEs of a VPN are connected to a 749 common VRF/VR) 751 o per multicast group and/or per channel 753 o with a distinction between multicast reception and emission 755 A multicast VPN solution may choose to make the optimality/ 756 scalability trade-off stated in Section 3.3 by sometimes distributing 757 multicast traffic of a client group to a larger set of PE routers 758 that may include PEs which are not part of the VPN. From a security 759 standpoint, this may be a problem for some VPN customers, thus a 760 multicast VPN solution using such a scheme MAY offer ways to avoid 761 this for specific customers (and/or specific customer multicast 762 streams). 764 5.1.6. Extranet 766 In current PP L3VPN models, a customer site may be setup to be part 767 of multiple VPNs and this should still be possible when a VPN is 768 multicast-enabled. In practice it means that a VRF or VR can be part 769 of more than one VPN. 771 A multicast VPN solution MUST support such deployments. 773 For instance, it must be possible to configure a VRF so that an 774 enterprise site participating in a BGP/MPLS multicast-enabled VPN and 775 connected to that VRF, can receive a multicast stream from, [or 776 originate a multicast stream towards], another VPN that would be 777 associated to that VRF. 779 More precisely this means that a multicast VPN solution MUST offer 780 means so that: 782 o receivers behind attached CEs can receive multicast traffic 783 sourced in any of the VPNs (if security policy permits) 785 o sources behind attached CEs can reach multicast traffic receivers 786 located in any of the VPNs 788 o multicast can be independently enabled for the different VPNs (and 789 multicast reception and emission can also be independently 790 enabled) 792 Moreover, a solution MUST allow service providers to control an 793 extranet's multicast connectivity independently from the extranet's 794 unicast connectivity. More specifically: 796 o enabling unicast connectivity to another VPN MUST be possible 797 without activating multicast connectivity with this VPN 799 o enabling multicast connectivity with another VPN SHOULD NOT 800 require more than the strict minimal unicast routing : sending 801 multicast to a VPN does SHOULD NOT require having unicast routes 802 to this VPN, receiving multicast from a VPN SHOULD be possible 803 with nothing more than unicast routes to the relevant multicast 804 sources of this VPN 806 o when unicast routes from another VPN are imported into a VR/VRF, 807 for multicast RPF resolution, this SHOULD be possible without 808 making those routes available for unicast routing 810 Proper support for this feature SHOULD NOT require replicating 811 multicast traffic on a PE-CE link, whether it is a physical or 812 logical link. 814 5.1.7. Internet Multicast 816 Connectivity with Internet Multicast is a particular case of the 817 previous section, where sites attached to a VR/VRF would need to 818 receive/send multicast traffic from/to the Internet. 820 This should be considered OPTIONAL given the additional 821 considerations, such as security, needed to fulfill the requirements 822 for providing Internet Multicast. 824 5.1.8. Carrier's carrier 826 Many L3 PPVPN solutions, such as [RFC4364] and [VRs] define the 827 "Carrier's Carrier" model, where a "carrier's carrier" service 828 provider supports one or more customer ISP, or "sub-carriers". A 829 multicast VPN solution SHOULD support the carrier's carrier model in 830 a scalable and efficient manner. 832 Ideally the range of tunneling protocols available for the sub- 833 carrier ISP should be the same as those available for the carrier's 834 carrier ISP. This implies that the protocols that may be used at the 835 PE-CE level SHOULD NOT be restricted to protocols required as per 836 Section 5.1.2 and SHOULD include some of the protocols listed in 837 Section 5.2.4, such as for instance P2MP MPLS signaling protocols. 839 In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs 840 [RFC4364], this means that MPLS label distribution SHOULD happen at 841 the PE-CE level, giving the ability to the sub-carrier to use 842 multipoint LSPs as a tunneling mechanism. 844 5.1.9. Multi-homing, load balancing and resiliency 846 A multicast VPN solution SHOULD be compatible with current solutions 847 that aim at improving the service robustness for customers such as 848 multi-homing, CE-PE link load balancing and fail-over. A multicast 849 VPN solution SHOULD also be able to offer those same features for 850 multicast traffic. 852 Any solution SHOULD support redundant topology of CE-PE links. It 853 SHOULD minimize multicast traffic disruption and fail-over. 855 5.1.10. RP Engineering 857 When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer 858 side, the RP function (or RP-address in the case of bidir-PIM) has to 859 be associated to a node running PIM, and configured on this node. 861 5.1.10.1. RP Outsourcing 863 In the case of PIM-SM in ASM mode, engineering of the RP function 864 requires the deployment of specific protocols and associated 865 configurations. Some service provider may offer to manage customer's 866 multicast protocol operation on their behalf. This implies that it 867 is necessary to consider cases where the customer's RPs are out- 868 sourced (e.g., on PEs). Consequently, a VPN solution MAY support the 869 hosting of the RP function in a VR or VRF. 871 5.1.10.2. RP Availability 873 Availability of the RP function (or address) is required for proper 874 operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity 875 to the RP from a receiver or source will impact the multicast 876 service. For this reason different mechanisms exist, such as BSR 877 [I-D.ietf-pim-sm-bsr] or anycast-RP (MSDP based [RFC3446] or PIM 878 based [I-D.ietf-pim-anycast-rp]). 880 These protocols and procedures SHOULD work transparently through a 881 multicast VPN, and MAY, if relevant, be implemented in a VRF/VR. 883 Moreover, a multicast VPN solution MAY improve the robustness of the 884 ASM multicast service regarding loss of connectivity to the RP, by 885 providing specific features that help : 887 a) maintain ASM multicast service among all the sites within an MVPN 888 that maintain connectivity among themselves, even when the site(s) 889 hosting the RP lose their connectivity to the MVPN 891 b) maintain ASM multicast service within any site that loses 892 connectivity to the service provider 894 5.1.10.3. RP Location 896 In the case of PIM-SM, when a source starts to emit traffic toward a 897 group (in ASM mode), if sources and receivers are located in VPN 898 sites that are different than that of the RP, then traffic may 899 transiently flow twice through the SP network and the CE-PE link of 900 the RP (from source to RP, and then from RP to receivers). This 901 traffic peak, even short, may not be convenient depending on the 902 traffic and link bandwidth. 904 Thus, a VPN solution MAY provide features that solve or help mitigate 905 this potential issue. 907 5.1.11. Addressing 909 A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions 910 on multicast group addresses used by VPN customers. 912 In particular, like unicast traffic, an overlap of multicast group 913 address sets used by different VPN customers MUST be supported. 915 The use of globally unique means of multicast-based service 916 identification at the scale of the domain where such services are 917 provided SHOULD be recommended. For IPv4 multicast, this implies the 918 use of the multicast administratively scoped range, (239/8 as defined 919 by [RFC2365]) for services which are to be used only inside the VPN, 920 and of either SSM-range addresses (232/8 as defined by [I-D.ietf-ssm- 921 arch]) or globally assigned group addresses (e.g. GLOP [RFC3180], 922 233/8) for services for which traffic may be transmitted outside the 923 VPN . 925 5.1.12. Minimum MTU 927 For customers, it is often a serious issue whether transmitted 928 packets will be fragmented or not. In particular, some multicast 929 applications might have different requirements than those that make 930 use of unicast, and they may expect services that guarantee available 931 packet length not to be fragmented. 933 Therefore, a multicast VPN solution SHOULD let customers' devices be 934 free of any fragmentation or reassembly activity. 936 A committed minimum path MTU size SHOULD be provided to customers. 937 Moreover, since Ethernet LAN segments are often located at first and 938 last hops, a minimum 1500 bytes IP MTU SHOULD be provided. 940 It SHOULD also be compatible with Path MTU discovery mechanisms, such 941 as those defined in [RFC1191] or [RFC4459]. 943 5.2. Service provider standpoint 945 Note: please remember that, to avoid repetition and confusion with 946 terms used in solution specifications, we introduced in Section 2.1 947 the term MDTunnel (for Multicast Distribution Tunnel), which 948 designates the data plane means used by the service provider to 949 forward customer multicast traffic over the core network. 951 5.2.1. General requirement 953 The deployment of a multicast VPN solution SHOULD be possible with no 954 (or very limited) impact on existing deployments of standardized 955 multicast related protocols on P and PE routers. 957 5.2.2. Scalability 959 Some currently standardized and deployed L3VPN solutions have the 960 major advantage of being scalable in the core regarding the number of 961 customers and the number of customer routes. For instance, in the 962 [RFC4364] and [VRs] [I-D.ietf-l3vpn-vpn-vr] models, a P router sees a 963 number of MPLS tunnels that is only linked to the number of PEs and 964 not to the number of VPNs, or customers' sites. 966 As far as possible, this independence in the core, with respect to 967 the number of customers and to customer activity, is recommended. 968 Yet, it is recognized that in our context scalability and resource 969 usage optimality are competing goals, so this requirement may be 970 reduced to giving the possibility of bounding the quantity of states 971 that the service provider needs to maintain in the core for 972 MDTunnels, with a bound being independent of the multicast activity 973 of VPN customers. 975 It is expected that multicast VPN solutions will use some kind of 976 point-to-multipoint technology to efficiently carry multicast VPN 977 traffic, and because such technologies require maintaining state 978 information, this will use resources in the control plane of P and PE 979 routers (memory and processing, and possibly address space). 981 Scalability is a key requirement for multicast VPN solutions. 982 Solutions MUST be designed to scale well with an increase in the 983 number of any of the following: 985 o the number of PEs 987 o the number of customers VPNs (total and per PE) 989 o the number of PEs and sites in any VPN 991 o the number of client multicast channels (groups or source-groups) 993 Please consult section 4.2 for typical orders of magnitude up to 994 which a multicast VPN solution is expected to scale 996 Scalability of both performance and operation MUST be considered. 998 Key considerations SHOULD include: 1000 o the processing resources required by the control plane 1001 (neighborhood or session maintenance messages, keep-alives, 1002 timers, etc.) 1004 o the memory resources needed for the control plane 1006 o the amount of protocol information transmitted to manage a 1007 multicast VPN (e.g. signaling throughput) 1009 o the amount of control plane processing required on PE and P 1010 routers to add or remove a customer site (or a customer from a 1011 multicast session) 1013 o the number of multicast IP addresses used (if IP multicast in ASM 1014 mode is proposed as a multicast distribution tunnel) 1016 o other particular elements inherent to each solution that impacts 1017 scalability (e.g., if a solution uses some distribution tree 1018 inside the core, topology of the tree and number of leaf nodes may 1019 be some of them) 1021 It is expected that the applicability of each solution will be 1022 evaluated with regards to the aforementioned scalability criteria. 1024 These considerations naturally lead us to believe that proposed 1025 solutions SHOULD offer the possibility of sharing such resources 1026 between different multicast streams (between different VPNs, between 1027 different multicast streams of the same or of different VPNs). This 1028 means for instance, if MDTunnels are trees, being able to share an 1029 MDTunnel between several customers. 1031 Those scalability issues are expected to be more significant on P 1032 routers, but a multicast VPN solution SHOULD address both P and PE 1033 routers as far as scalability is concerned. 1035 5.2.3. Resource optimization 1037 5.2.3.1. General goals 1039 One of the aims of the use of multicast instead of unicast is 1040 resource optimization in the network. 1042 The two obvious suboptimal behaviors that a multicast VPN solution 1043 would want to avoid are needless duplication (when the same data 1044 travels twice or more on a same link, e.g. when doing ingress PE 1045 replication) and needless reception (e.g. a PE receiving traffic that 1046 it does not need because there are no downstream receivers). 1048 5.2.3.2. Trade-off and tuning 1050 As previously stated in this document, designing a scalable solution 1051 that makes an optimal use of resources is considered difficult. Thus 1052 what is expected from a multicast VPN solution is that it addresses 1053 the resource optimization issue while taking into account the fact 1054 that some trade-off has to be made. 1056 Moreover, it seems that a "one size fits all" trade-off probably does 1057 not exist either. Thus a multicast VPN solution SHOULD offer service 1058 providers appropriate configuration settings that let them tune the 1059 trade-off according to their particular constraints (network 1060 topology, platforms, customer applications, level of service offered 1061 etc.). 1063 As an illustration here are some example bounds of the trade-off 1064 space: 1066 Bandwidth optimization: setting up somehow optimal core MDTunnels 1067 whose topology (PIM or P2MP LSP trees, etc.) precisely follows 1068 customer's multicast routing changes. This requires managing an 1069 important quantity of states in the core, and also quick reactions 1070 of the core to customer multicast routing changes. This approach 1071 can be advantageous in terms of bandwidth, but it is bad in terms 1072 of state management. 1074 State optimization: setting up MDTunnels that aggregate multiple 1075 customer multicast streams (all or some of them, across different 1076 VPNs or not). This will have better scalability properties, but 1077 at the expense of bandwidth since some MDTunnel leaves will very 1078 likely receive traffic they don't need, and because increased 1079 constraints will make it harder to find optimal MDTunnels. 1081 5.2.3.3. Traffic engineering 1083 If the VPN service provides traffic engineering features for the 1084 connection used between PEs for unicast traffic in the VPN service, 1085 the solution SHOULD provide equivalent features for multicast 1086 traffic. 1088 A solution SHOULD offer means to support key TE objectives as defined 1089 in [RFC3272], for the multicast service. 1091 A solution MAY also usefully support means to address multicast- 1092 specific traffic engineering issues: it is known that bandwidth 1093 resource optimization in the point-to-multipoint case is an NP-hard 1094 problem, and that techniques used for unicast TE may not be 1095 applicable to multicast traffic. 1097 Also, it has been identified that managing the trade-off between 1098 resource usage and scalability may incur uselessly sending traffic to 1099 some PEs participating in a multicast VPN. For this reason, a 1100 multicast VPN solution MAY permit that the bandwidth/state tuning 1101 take into account the relative cost or availability of bandwidth 1102 toward each PE. 1104 5.2.4. Tunneling Requirements 1106 5.2.4.1. Tunneling technologies 1108 Following the principle of separation between the control plane and 1109 the forwarding plane, a multicast VPN solution SHOULD be designed so 1110 that control and forwarding planes are not interdependent: the 1111 control plane SHALL NOT depend on which forwarding plane is used (and 1112 vice versa), and the choice of forwarding plane SHOULD NOT be limited 1113 by the design of the solution. The solution SHOULD also NOT be tied 1114 to a specific tunneling technology. 1116 In a multicast VPN solution extending a unicast L3 PPVPN solution, 1117 consistency in the tunneling technology has to be favored: such a 1118 solution SHOULD allow the use of the same tunneling technology for 1119 multicast as for unicast. Deployment consistency, ease of operation 1120 and potential migrations are the main motivations behind this 1121 requirement. 1123 For MDTunnels (multicast distribution tunnels, the means used to 1124 carry VPNs' multicast traffic over the provider network), a solution 1125 SHOULD be able to use a range of tunneling technologies, including 1126 point-to-point and point-to-multipoint, such as GRE [RFC2784] 1127 (including GRE in multicast IP trees), MPLS [RFC3031] (including P2P 1128 or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP 1129 extensions to RSVP [I-D.ietf-mpls-rsvp-te-p2mp] or LDP [I-D.ietf- 1130 mpls-mp-ldp-reqs][I-D.ietf-mpls-ldp-p2mp]), L2TP (including L2TP for 1131 multicast [RFC4045]), IPsec [RFC4031], IP-in-IP [RFC2003], etc. 1133 Naturally, it is RECOMMENDED that a solution is built so that it can 1134 leverage the point to multipoint variants of these techniques, that 1135 allow for packet replications to happen along a tree in the provider 1136 core network, and may help improve bandwidth efficiency in a 1137 multicast VPN context. 1139 5.2.4.2. MTU and Fragmentation 1141 A solution SHOULD support a method that provides the minimum MTU of 1142 the MDTunnel (e.g., to discover MTU, to communicate MTU via 1143 signaling, etc.) so that: 1145 o fragmentation inside the MDTunnel does not happen, even when 1146 allowed by the underlying tunneling technology 1148 o proper troubleshooting can be done if packets that are too big for 1149 the MDTunnel happen to be encapsulated in the MDTunnel 1151 5.2.5. Control mechanisms 1153 The solution MUST provide some mechanisms to control the sources 1154 within a VPN. This control includes the number of sources that are 1155 entitled to send traffic on the VPN, and/or the total bit rate of all 1156 the sources. 1158 At the reception level, the solution MUST also provide mechanisms to 1159 control the number of multicast groups or channels VPN users are 1160 entitled to subscribe to and/or the total bit rate represented by the 1161 corresponding multicast traffic. 1163 All these mechanisms MUST be configurable by the service provider in 1164 order to control the amount of multicast traffic and state within a 1165 VPN. 1167 Moreover it MAY be desirable to be able to impose some bound on the 1168 quantity of state used by a VPN in the core network for its multicast 1169 traffic, whether on each P or PE router, or globally. The motivation 1170 is that it may be needed to avoid out-of-resources situations (e.g. 1171 out of memory to maintain PIM state if IP multicast is used in the 1172 core for multicast VPN traffic, or out of memory to maintain RSVP 1173 state if MPLS P2MP is used, etc.). 1175 5.2.6. Support of Inter-AS, inter-provider deployments 1177 A solution MUST support inter-AS multicast VPNs, and SHOULD support 1178 inter-provider multicast VPNs. Considerations about coexistence with 1179 unicast inter-AS VPN Options A, B and C (as described in section 10 1180 of [RFC4364]) are strongly encouraged. 1182 A multicast VPN solution SHOULD provide inter-AS mechanisms requiring 1183 the least possible coordination between providers, and keep the need 1184 for detailed knowledge of providers networks to a minimum - all this 1185 being in comparison with corresponding unicast VPN options. 1187 o Within each service provider the service provider SHOULD be able 1188 on its own to pick the most appropriate tunneling mechanism to 1189 carry (multicast) traffic among PEs (just like what is done today 1190 for unicast) 1192 o If a solution does require a single tunnel to span P routers in 1193 multiple ASs, the solution SHOULD provide mechanisms to ensure 1194 that the inter-provider co-ordination to setup such a tunnel is 1195 minimized 1197 Moreover such support SHOULD be possible without compromising other 1198 requirements expressed in this requirement document, and SHALL NOT 1199 incur penalties on scalability and bandwidth-related efficiency. 1201 5.2.7. Quality of Service Differentiation 1203 A multicast VPN solution SHOULD give a VPN service provider the 1204 ability to offer, guarantee and enforce differentiated levels of QoS 1205 for its different customers. 1207 5.2.8. Infrastructure security 1209 The solution shall provide the same level of security for the service 1210 provider as what currently exist for unicast VPNs (for instance, as 1211 developed in Security sections of [RFC4364] and 1212 [I-D.ietf-l3vpn-vpn-vr]). For instance, that means that traffic 1213 segregation and intrinsic protection against DOS and DDOS attacks of 1214 the BGP/MPLS VPN solution must be equally supported by the multicast 1215 solution. 1217 Moreover, since multicast traffic and routing are intrinsically 1218 dynamic (receiver-initiated), some mechanism SHOULD be proposed so 1219 that the frequency of changes in the way client traffic is carried 1220 over the core can be bounded and not tightly coupled to dynamic 1221 changes of multicast traffic in the customer network. For example, 1222 multicast route dampening functions would be one possible mechanism. 1224 Network devices that participate in the deployment and the 1225 maintenance of a given L3VPN MAY represent a superset of the 1226 participating devices that are also involved in the establishment and 1227 the maintenance of the multicast distribution tunnels. As such the 1228 activation of IP multicast capabilities within a VPN SHOULD be 1229 device-specific, not only to make sure that only the relevant devices 1230 will be multicast-enabled, but also to make sure that multicast 1231 (routing) information will be disseminated to the multicast-enabled 1232 devices only, hence limiting the risk of multicast-inferred DOS 1233 attacks. 1235 Traffic of a multicast channel for which there are no members in a 1236 given multicast VPN MUST NOT be propagated within this multicast VPN, 1237 most particularly if this traffic comes from another VPN or from the 1238 Internet. 1240 Security considerations are particularly important for inter-AS and 1241 inter-provider deployments. In such cases, it is RECOMMENDED that a 1242 multicast VPN solution support means to ensure the integrity and 1243 authenticity of multicast-related exchanges across inter-ASes or 1244 inter-provider borders. It is RECOMMENDED that corresponding 1245 procedures require the least possible coordination between providers; 1246 more precisely, when specific configurations or cryptographic keys 1247 have to be deployed, this shall be limited to ASBRs (Autonomous 1248 Systems Border Routers) or a subset of them, and optionally BGP Route 1249 Reflectors (or a subset of them). 1251 Lastly, control mechanisms described in Section 5.2.5 are also to be 1252 considered from this infrastructure security point of view. 1254 5.2.9. Robustness 1256 Resiliency is also crucial to infrastructure security, thus a 1257 multicast VPN solution SHOULD either avoid single points of failures 1258 or propose some technical solution making it possible to implement a 1259 fail-over mechanism. 1261 As an illustration, one can consider the case of a solution that 1262 would use PIM-SM as a means to setup MDTunnels. In such a case, the 1263 PIM RP might be a single point of failure. Such a solution SHOULD 1264 thus be compatible with a solution implementing RP resiliency, such 1265 as anycast-RP [I-D.ietf-pim-anycast-rp] or BSR [I-D.ietf-pim-sm-bsr]. 1267 5.2.10. Operation, Administration and Maintenance 1269 The operation of a multicast VPN solution SHALL be as light as 1270 possible and providing automatic configuration and discovery SHOULD 1271 be a priority while designing a multicast VPN solution. Particularly 1272 the operational burden of setting up multicast on a PE or for a VR/ 1273 VRF SHOULD be as low as possible. 1275 Also, as far as possible, the design of a solution SHOULD carefully 1276 consider the number of protocols within the core network: if any 1277 additional protocols are introduced compared with the unicast VPN 1278 service, the balance between their advantage and operational burden 1279 SHOULD be examined thoroughly. 1281 Moreover, monitoring of multicast specific parameters and statistics 1282 SHOULD be offered to the service provider, following requirements 1283 expressed in [RFC4176]. 1285 Most notably the provider SHOULD have access to: 1287 o Multicast traffic statistics (incoming/outgoing/dropped/total 1288 traffic conveyed, by period of time) 1290 o Information about client multicast resource usage (multicast 1291 routing states and bandwidth usage) 1293 o Alarms when limits are reached on such resources 1295 o The IPPM (IP Performance Metrics [RFC2330]) -related information 1296 that is relevant to the multicast traffic usage: such information 1297 includes the one-way packet delay, the inter-packet delay 1298 variation, etc. 1300 o Statistics on decisions related to how client traffic is carried 1301 on distribution tunnels (e.g. "traffic switched onto a multicast 1302 tree dedicated to such groups or channels") 1304 o Statistics on parameters that could help the provider to evaluate 1305 its optimality/state trade-off 1307 This information SHOULD be made available through standardized 1308 protocols such as SNMP ([RFC1441], [RFC3411]) MIBs (Management 1309 Information Bases) or IPFIX[RFC1441]. For instance, in the context 1310 of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs defined in 1311 [RFC4382] SHOULD be proposed, with proper articulation with 1312 [RFC3811], [RFC3812], [RFC3813] and [RFC3814] when applicable. 1314 Mechanisms similar to those described in Section 5.2.12 SHOULD also 1315 exist for proactive monitoring of the MDTunnels. 1317 Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be 1318 scalable with respects to parameters mentioned in Section 5.2.2. In 1319 particular, it is RECOMMENDED that particular attention is given to 1320 the impact of monitoring mechanisms on performances and QoS. 1322 5.2.11. Compatibility and migration issues 1324 It is a requirement that unicast and multicast services MUST be able 1325 to co-exist within the same VPN. 1327 Likewise, a multicast VPN solution SHOULD be designed so that its 1328 activation in devices that participate in the deployment and the 1329 maintenance of a multicast VPN SHOULD be as smooth as possible, i.e. 1330 without affecting the overall quality of the services that are 1331 already supported by the underlying infrastructure. 1333 A multicast VPN solution SHOULD prevent compatibility and migration 1334 issues, for instance by prioritizing mechanisms facilitating forward 1335 compatibility. Most notably a solution supporting only a subset of 1336 those requirements SHOULD be designed to be compatible with future 1337 enhanced revisions. 1339 It SHOULD be an aim of any multicast VPN solution to offer as much 1340 backward compatibility as possible. Ideally a solution would have be 1341 the ability to offer multicast VPN services across a network 1342 containing some legacy routers that do not support any multicast VPN 1343 specific features. 1345 In any case a solution SHOULD state a migration policy from possibly 1346 existing deployments. 1348 5.2.12. Troubleshooting 1350 A multicast VPN solution that dynamically adapts the way some client 1351 multicast traffic is carried over the provider's network may incur 1352 the disadvantage of being hard to troubleshoot. In such a case, to 1353 help diagnose multicast network issues, a multicast VPN solution 1354 SHOULD provide monitoring information describing how client traffic 1355 is carried over the network (e.g. if a solution uses multicast-based 1356 MDTunnels, which provider multicast group is used for such and such 1357 client multicast stream). A solution MAY also provide configuration 1358 options to avoid any dynamic changes, for multicast traffic of a 1359 particular VPN or a particular multicast stream. 1361 Moreover, a solution MAY usefully provide some mechanism that allow 1362 network operators to check that all VPN sites that advertised 1363 interest in a particular customer multicast stream are properly 1364 associated with the corresponding MDTunnel. Providing operators with 1365 means to check the proper setup and operation of MDTunnels MAY also 1366 be provided (e.g. when P2MP MPLS is used for MDTunnels, 1367 troubleshooting functionalities SHOULD integrate mechanisms compliant 1368 with [I-D.ietf-mpls-p2mp-oam-reqs], such as LSPPing[RFC4379][I- 1369 D.ietf-mpls-p2mp-lsp-ping]). Depending on the implementation such 1370 verification could be initiated by source-PE or receiver-PE. 1372 6. Security Considerations 1374 This document does not by itself raise any particular security issue. 1376 A set of security issues have been identified that MUST be addressed 1377 when considering the design and deployment of multicast-enabled L3 PP 1378 VPNs. Such issues have been described in Section 5.1.5 and 1379 Section 5.2.8. 1381 7. IANA Considerations 1383 This document has no actions for IANA. 1385 8. Acknowledgments 1387 The authors would like to thank, by rough chronological order, 1388 Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, 1389 Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel 1390 King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, 1391 Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka 1392 Savola, Benjamin Niven-Jenkins, Thomas Nadeau, for their review, 1393 valuable input and feedback. 1395 We also thank the people who kindly answered the survey, and Daniel 1396 King who took care of gathering and anonymizing its results. 1398 9. References 1400 9.1. Normative references 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, March 1997. 1405 [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 1406 3 Provider Provisioned Virtual Private Networks (PPVPNs)", 1407 RFC 4031, April 2005. 1409 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1410 Private Network (VPN) Terminology", RFC 4026, March 2005. 1412 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 1413 S., Handley, M., and V. Jacobson, "Protocol Independent 1414 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 1415 RFC 2362, June 1998. 1417 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1418 Thyagarajan, "Internet Group Management Protocol, Version 1419 3", RFC 3376, October 2002. 1421 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1422 Independent Multicast - Dense Mode (PIM-DM): Protocol 1423 Specification (Revised)", RFC 3973, January 2005. 1425 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1426 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1428 [I-D.ietf-pim-sm-v2-new] 1429 Fenner, B., "Protocol Independent Multicast - Sparse Mode 1430 (PIM-SM): Protocol Specification (Revised)", 1431 draft-ietf-pim-sm-v2-new-12 (work in progress), 1432 March 2006. 1434 [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and 1435 A. Gonguet, "Framework for Layer 3 Virtual Private 1436 Networks (L3VPN) Operations and Management", RFC 4176, 1437 October 2005. 1439 9.2. Informative references 1441 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1442 Networks (VPNs)", RFC 4364, February 2006. 1444 [I-D.ietf-l3vpn-vpn-vr] 1445 Ould-Brahim, H., "Network based IP VPN Architecture Using 1446 Virtual Routers", draft-ietf-l3vpn-vpn-vr-03 (work in 1447 progress), March 2006. 1449 [I-D.ietf-ssm-arch] 1450 Holbrook, H. and B. Cain, "Source-Specific Multicast for 1451 IP", draft-ietf-ssm-arch-07 (work in progress), 1452 October 2005. 1454 [RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", 1455 RFC 2432, October 1998. 1457 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1458 Label Switching Architecture", RFC 3031, January 2001. 1460 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1461 RFC 1112, August 1989. 1463 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1464 2", RFC 2236, November 1997. 1466 [I-D.ietf-mpls-rsvp-te-p2mp] 1467 Aggarwal, R., "Extensions to RSVP-TE for Point to 1468 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-05 (work 1469 in progress), May 2006. 1471 [I-D.ietf-pim-sm-bsr] 1472 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 1473 draft-ietf-pim-sm-bsr-08 (work in progress), May 2006. 1475 [I-D.ietf-pim-anycast-rp] 1476 Farinacci, D. and Y. Cai, "Anycast-RP using PIM", 1477 draft-ietf-pim-anycast-rp-07 (work in progress), 1478 February 2006. 1480 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 1481 Rendevous Point (RP) mechanism using Protocol Independent 1482 Multicast (PIM) and Multicast Source Discovery Protocol 1483 (MSDP)", RFC 3446, January 2003. 1485 [I-D.ietf-mpls-ldp-p2mp] 1486 Minei, I., "Label Distribution Protocol Extensions for 1487 Point-to-Multipoint and Multipoint-to-Multipoint Label 1488 Switched Paths", draft-ietf-mpls-ldp-p2mp-00 (work in 1489 progress), March 2006. 1491 [I-D.ietf-mpls-mp-ldp-reqs] 1492 Roux, J., "Requirements for point-to-multipoint extensions 1493 to the Label Distribution Protocol", 1494 draft-ietf-mpls-mp-ldp-reqs-00 (work in progress), 1495 May 2006. 1497 [I-D.ietf-mpls-p2mp-oam-reqs] 1498 Farrel, A., "OAM Requirements for Point-to-Multipoint MPLS 1499 Networks", draft-ietf-mpls-p2mp-oam-reqs-01 (work in 1500 progress), February 2006. 1502 [I-D.ietf-pim-bidir] 1503 Handley, M., "Bi-directional Protocol Independent 1504 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in 1505 progress), October 2005. 1507 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1508 October 1996. 1510 [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, 1511 F., and F. Ansari, "Overview of IP Multicast in a Multi- 1512 Protocol Label Switching (MPLS) Environment", RFC 3353, 1513 August 2002. 1515 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 1516 Xiao, "Overview and Principles of Internet Traffic 1517 Engineering", RFC 3272, May 2002. 1519 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1520 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1521 March 2000. 1523 [I-D.ietf-ipfix-protocol] 1524 Claise, B., "IPFIX Protocol Specification", 1525 draft-ietf-ipfix-protocol-21 (work in progress), 1526 April 2006. 1528 [RFC4045] Bourdon, G., "Extensions to Support Efficient Carrying of 1529 Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)", 1530 RFC 4045, April 2005. 1532 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 1533 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 1534 June 2004. 1536 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 1537 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 1538 Management", RFC 3811, June 2004. 1540 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1541 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1542 (TE) Management Information Base (MIB)", RFC 3812, 1543 June 2004. 1545 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1546 "Multiprotocol Label Switching (MPLS) Label Switching 1547 Router (LSR) Management Information Base (MIB)", RFC 3813, 1548 June 2004. 1550 [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, 1551 "Multiprotocol Label Switching (MPLS) Forwarding 1552 Equivalence Class To Next Hop Label Forwarding Entry (FEC- 1553 To-NHLFE) Management Information Base (MIB)", RFC 3814, 1554 June 2004. 1556 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1557 RFC 2365, July 1998. 1559 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1560 "Framework for IP Performance Metrics", RFC 2330, 1561 May 1998. 1563 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1564 and W. Weiss, "An Architecture for Differentiated 1565 Services", RFC 2475, December 1998. 1567 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 1568 BCP 53, RFC 3180, September 2001. 1570 [RFC1441] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1571 "Introduction to version 2 of the Internet-standard 1572 Network Management Framework", RFC 1441, April 1993. 1574 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1575 Architecture for Describing Simple Network Management 1576 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1577 December 2002. 1579 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1580 November 1990. 1582 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1583 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1584 February 2006. 1586 [I-D.ietf-mpls-p2mp-lsp-ping] 1587 Yasukawa, S., "Detecting Data Plane Failures in Point-to- 1588 Multipoint MPLS Traffic Engineering - Extensions to LSP 1589 Ping", draft-ietf-mpls-p2mp-lsp-ping-01 (work in 1590 progress), April 2006. 1592 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1593 Network Tunneling", RFC 4459, April 2006. 1595 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1596 June 1999. 1598 [RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual 1599 Private Network (VPN) Management Information Base", 1600 RFC 4382, February 2006. 1602 Appendix A. Changelog 1604 This section lists changes made to this document (minor or editorial 1605 changes excepted) between major revisions. 1607 It shall be removed before publication as an RFC. 1609 A.1. Changes between -00 and -01 1611 o integrated comments made on L3VPN WG mailing list after -00 1612 submission 1614 o completed Carrier's carrier section (5.1.9) 1616 o updates in sections 5.1 and 5.2 about minimum MTU 1618 o added a section about "Quality of Service Differentiation" as ISP 1619 requirement (section 5.2.5) 1621 o added P2MP LDP extensions as possible MDTunnels techniques 1622 (section 5.2.3.1) 1624 o started to build section 4 "Use Case" 1626 o detailed section 5.1.3 "QoS", most notably about group join and 1627 leave delays 1629 o additions to section 5.2.12 "Inter-AS, inter-provider" 1631 o added MDTunnel verification requirement to section 5.2.11 1633 o moved "Architectural Considerations" section 1635 o moved contributors to top of document 1637 o made draft content agnostic to unicast L3VPN solutions 1639 o added two appendixes: "Changelog" and "Requirement summary" 1641 o conversion to XML [RFC2629] with the help of some scripting and 1642 Bill Fenner's xml2rfc XMLMind plugin 1644 o lot's of editorial changes 1646 A.2. Changes between -01 and -02 1647 o based on survey results: 1649 * restructure use case scenario section 1651 * fill in Scalability orders of magnitude section 1653 * better detail requirements for protocols at the PE-CE level 1655 * add considerations about PEs with scarce connectivity to 1656 section 5.2.3.3 1658 * step up requirement level for Extranet (Section 5.1.6) 1660 o some editorial changes 1662 o use capitalized wording for some requirements 1664 o fill in requirements summary 1666 A.3. Changes between -02 and -03 1668 o made inter-AS a MUST (and moved the whole section up) 1670 o add a requirement about security of multicast-related exchanges 1671 across providers/ASes, in Section 5.2.8 1673 o some editorial changes and fixed typos 1675 A.4. Changes between -03 and -04 1677 o Integrated comments received during last call 1679 o Lots of editorial comments 1681 o Improved terminology section 1683 o Number of VPNs with multicast enabled: A solution SHOULD NOT limit 1684 the proportion of multicast VPNs among all (unicast) VPNs. 1686 o Customer-side service definition Enabling a VPN for multicast 1687 support SHOULD be possible with no (or very limited impact) on 1688 existing multicast protocols possibly already deployed on the CE 1689 devices 1691 o Extranet: a solution MUST allow to control an extranet multicast 1692 connectivity independently from the extranet unicast connectivity 1694 o Service provider standpoint, added a general statement: "The 1695 deployment of a multicast VPN solution SHOULD be possible with no 1696 (or very limited) impact on possibly existing deployments of 1697 multicast protocols on P and PE routers." 1699 o Removed institutions and company names from the already long 1700 acknowledgments section. 1702 A.5. Changes between -04 and -05 1704 o Follow up of mailing list comments integration 1706 o 2547bis is now 4364 1708 o CE-PE Multicast routing and management protocols: clarified IPv6 1709 related statements 1711 o More precisions in 5.1.7. "Extranet" 1713 o Revamped section 5.1.11 "RP Engineering" : separated text about 1714 different issues "RP Outsourcing", "RP Availability", "RP 1715 Location". Updated 5.1.10 accordingly. 1717 o Updated 5.2.10 about proactive monitoring of tunnels 1719 o Removed requirements summary 1721 o Lots of editorial changes 1723 A.6. Changes between -05 and -06 1725 o editorial changes 1727 o revamp OAM-related sections to integrate comments made on WG 1728 mailing-list 1730 A.7. Changes between -06 and -08 1732 o minor editorial changes 1734 Author's Address 1736 Thomas Morin (editor) 1737 France Telecom R&D 1738 2, avenue Pierre Marzin 1739 Lannion 22307 1740 France 1742 Email: thomas.morin@rd.francetelecom.com 1744 Intellectual Property Statement 1746 The IETF takes no position regarding the validity or scope of any 1747 Intellectual Property Rights or other rights that might be claimed to 1748 pertain to the implementation or use of the technology described in 1749 this document or the extent to which any license under such rights 1750 might or might not be available; nor does it represent that it has 1751 made any independent effort to identify any such rights. Information 1752 on the procedures with respect to rights in RFC documents can be 1753 found in BCP 78 and BCP 79. 1755 Copies of IPR disclosures made to the IETF Secretariat and any 1756 assurances of licenses to be made available, or the result of an 1757 attempt made to obtain a general license or permission for the use of 1758 such proprietary rights by implementers or users of this 1759 specification can be obtained from the IETF on-line IPR repository at 1760 http://www.ietf.org/ipr. 1762 The IETF invites any interested party to bring to its attention any 1763 copyrights, patents or patent applications, or other proprietary 1764 rights that may cover technology that may be required to implement 1765 this standard. Please address the information to the IETF at 1766 ietf-ipr@ietf.org. 1768 Disclaimer of Validity 1770 This document and the information contained herein are provided on an 1771 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1772 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1773 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1774 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1775 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1776 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1778 Copyright Statement 1780 Copyright (C) The Internet Society (2006). This document is subject 1781 to the rights, licenses and restrictions contained in BCP 78, and 1782 except as set forth therein, the authors retain all their rights. 1784 Acknowledgment 1786 Funding for the RFC Editor function is currently provided by the 1787 Internet Society.