idnits 2.17.1 draft-ietf-l3vpn-ppvpn-mcast-reqts-10.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1820. ** 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 issues found here. 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 (November 13, 2006) is 6367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'VRs' is mentioned on line 800, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-06 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-09 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-01 == 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-24 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-02 -- 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-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 10 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 Intended status: Informational November 13, 2006 5 Expires: May 17, 2007 7 Requirements for Multicast in L3 Provider-Provisioned VPNs 8 draft-ietf-l3vpn-ppvpn-mcast-reqts-10 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 17, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document presents a set of functional requirements for network 42 solutions that allow the deployment of IP multicast within L3 43 Provider Provisioned Virtual Private Networks (PPVPNs). It specifies 44 requirements both from the end user and service provider standpoints. 45 It is intended that potential solutions specifying the support of IP 46 multicast within such VPNs will use these requirements as guidelines. 48 Working group 50 This document is a product of the IETF's Layer 3 Virtual Private 51 Network (l3vpn) working group. Comments should be addressed to the 52 WG's mailing list at . The charter for l3vpn 53 may be found at 54 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Conventions used in this document . . . . . . . . . . . . . . 6 60 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. General Requirements . . . . . . . . . . . . . . . . . . . 8 65 3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 9 66 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.1.1. Live content broadcast . . . . . . . . . . . . . . . . 10 69 4.1.2. Symmetric applications . . . . . . . . . . . . . . . . 11 70 4.1.3. Data distribution . . . . . . . . . . . . . . . . . . 12 71 4.1.4. Generic multicast VPN offer . . . . . . . . . . . . . 12 72 4.2. Scalability orders of magnitude . . . . . . . . . . . . . 13 73 4.2.1. Number of VPNs with multicast enabled . . . . . . . . 13 74 4.2.2. Number of multicast VPNs per PE . . . . . . . . . . . 13 75 4.2.3. Number of CEs per multicast VPN per PE . . . . . . . . 13 76 4.2.4. PEs per multicast VPN . . . . . . . . . . . . . . . . 13 77 4.2.5. PEs with multicast VRFs . . . . . . . . . . . . . . . 14 78 4.2.6. Number of streams sourced . . . . . . . . . . . . . . 14 79 5. Requirements for supporting IP multicast within L3 PPVPNs . . 15 80 5.1. End user/customer standpoint . . . . . . . . . . . . . . . 15 81 5.1.1. Service definition . . . . . . . . . . . . . . . . . . 15 82 5.1.2. CE-PE Multicast routing and group management 83 protocols . . . . . . . . . . . . . . . . . . . . . . 15 84 5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 16 85 5.1.4. Operations and Management . . . . . . . . . . . . . . 17 86 5.1.5. Security Requirements . . . . . . . . . . . . . . . . 18 87 5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 20 89 5.1.8. Carrier's carrier . . . . . . . . . . . . . . . . . . 20 90 5.1.9. Multi-homing, load balancing and resiliency . . . . . 20 91 5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 20 92 5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 22 93 5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 22 94 5.2. Service provider standpoint . . . . . . . . . . . . . . . 22 95 5.2.1. General requirement . . . . . . . . . . . . . . . . . 23 96 5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 23 97 5.2.3. Resource optimization . . . . . . . . . . . . . . . . 24 98 5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 26 99 5.2.5. Control mechanisms . . . . . . . . . . . . . . . . . . 27 100 5.2.6. Support of Inter-AS, inter-provider deployments . . . 27 101 5.2.7. Quality of Service Differentiation . . . . . . . . . . 28 102 5.2.8. Infrastructure security . . . . . . . . . . . . . . . 28 103 5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 29 104 5.2.10. Operation, Administration and Maintenance . . . . . . 29 105 5.2.11. Compatibility and migration issues . . . . . . . . . . 30 106 5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 31 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 109 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 112 10.1. Normative references . . . . . . . . . . . . . . . . . . . 36 113 10.2. Informative references . . . . . . . . . . . . . . . . . . 36 114 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 40 115 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 40 116 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 41 117 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 41 118 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 41 119 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 42 120 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 42 121 A.7. Changes between -06 and -08 . . . . . . . . . . . . . . . 42 122 A.8. Changes between -08 and -09 . . . . . . . . . . . . . . . 42 123 A.9. Changes between -09 and -10 . . . . . . . . . . . . . . . 43 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 125 Intellectual Property and Copyright Statements . . . . . . . . . . 45 127 1. Introduction 129 VPN services satisfying the requirements defined in [RFC4031] are now 130 being offered by many service providers throughout the world. VPN 131 services are popular because customers need not be aware of the VPN 132 technologies deployed in the provider network. They scale well for 133 the following reasons: 135 o because P routers (Provider Routers) need not be aware of VPN 136 service details 138 o because the addition of a new VPN member requires only limited 139 configuration effort 141 There is also a growing need for support of IP multicast-based 142 services. Efforts to provide efficient IP multicast routing 143 protocols and multicast group management have been done in 144 standardization bodies which has led, in particular, to the 145 definition of the PIM and IGMP protocols. 147 However, multicast traffic is not natively supported within existing 148 L3 PPVPN solutions. Deploying multicast over an L3VPN today, with 149 only currently standardized solutions, requires designing customized 150 solutions which will be inherently limited in terms of scalability, 151 operational efficiency and bandwidth usage. 153 This document complements the generic L3VPN requirements [RFC4031] 154 document, by specifying additional requirements specific to the 155 deployment within PPVPNs of services based on IP multicast. It 156 clarifies the needs of both VPN clients and providers and formulates 157 the problems that should be addressed by technical solutions with the 158 key objective being to remain solution agnostic. There is no intent 159 to either specify solution-specific details in this document or 160 application-specific requirements. Also this document does NOT aim 161 at expressing multicast-related requirements that are not specific to 162 L3 PPVPNs. 164 It is expected that solutions that specify procedures and protocol 165 extensions for multicast in L3 PPVPNs SHOULD satisfy these 166 requirements. 168 2. Conventions used in this document 170 2.1. Terminology 172 Although the reader is assumed to be familiar with the terminology 173 defined in [RFC4031], [RFC4364], [RFC4601], [RFC4607] the following 174 glossary of terms may be worthwhile. 176 Moreover we also propose here generic terms for concepts that 177 naturally appear when multicast in VPNs is discussed. 179 ASM: 180 Any Source Multicast. One of the two multicast service models, in 181 which a terminal subscribes to a multicast group to receive data 182 sent to the group by any source. 184 Multicast-enabled VPN, multicast VPN, or mVPN: 185 a VPN which supports IP multicast capabilities, i.e. for which 186 some PE devices (if not all) are multicast-enabled and whose core 187 architecture supports multicast VPN routing and forwarding. 189 PPVPN: 190 Provider-Provisioned Virtual Private Network. 192 PE/CE: 193 "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As 194 suggested in [RFC4026], we will use these notations to refer to 195 the equipments/routers/devices themselves. Thus, "PE" will refer 196 to the router on the provider's edge, which faces the "CE", the 197 router on the customer's edge. 199 VRF or VR: 200 By this phrase, we refer to the entity defined in a PE dedicated 201 to a specific VPN instance. "VRF" refers to "VPN Routing and 202 Forwarding table" as defined in [RFC4364], and "VR" to "Virtual 203 Router" as defined in [I-D.ietf-l3vpn-vpn-vr] terminology. 205 MDTunnel: 206 Multicast Distribution Tunnel, the means by which the customer's 207 multicast traffic will be transported across the SP network. This 208 is meant in a generic way: such tunnels can be either point-to- 209 point or point-to-multipoint. Although this definition may seem 210 to assume that distribution tunnels are unidirectional, the 211 wording also encompasses bi-directional tunnels. 213 S: 214 Denotes a multicast source. 216 G: 217 Denotes a multicast group. 219 Multicast channel: 220 In the multicast SSM model[RFC4607], a "multicast channel" 221 designate traffic from a specific source S to a multicast group G. 222 Also denominated as "(S,G)". 224 SP: 225 Service provider. 227 SSM: 228 Source Specific Multicast. One of the two multicast service 229 models, where a terminal subscribes to a multicast group to 230 receive data sent to the group by a specific source. 232 RP: 233 Rendez-vous point (PIM-SM [RFC4601]). 235 P2MP, MP2MP: Designate "Point to multipoint" and "Multipoint to 236 multipoint" replication trees. 238 L3VPN, VPN: 239 Throughout this document, "L3VPN" or even just "VPN" will refer to 240 "Provider-Provisioned Layer 3 Virtual Private Network" (PP 241 L3VPNs), and will be preferred for readability. 243 Please refer to [RFC4026] for details about terminology specifically 244 relevant to VPN aspects, and to [RFC2432] for multicast performance 245 or QoS related terms. 247 2.2. Conventions 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119]. 253 3. Problem Statement 255 3.1. Motivations 257 More and more L3VPN customers use IP multicast services within their 258 private infrastructures. Naturally, they want to extend these 259 multicast services to remote sites that are connected via a VPN. 261 For instance, the customer could be a national TV channel with 262 several geographical locations that wants to broadcast a TV program 263 from a central point to several regional locations within its VPN. 265 A solution to support multicast traffic could consist of point-to- 266 point tunnels across the provider network and requires the PEs 267 (Provider Edge routers) to replicate traffic. This would obviously 268 be sub-optimal as it would place the replication burden on the PE and 269 hence would have very poor scaling characteristics. It would also 270 probably waste bandwidth and control plane resources in the 271 provider's network. 273 Thus, to provide multicast services for L3VPN networks in an 274 efficient manner (that is, with a scalable impact on signaling and 275 protocol state as well as bandwidth usage), in a large scale 276 environment, new mechanisms are required to enhance existing L3VPN 277 solutions for proper support of multicast-based services. 279 3.2. General Requirements 281 This document sets out requirements for L3 provider-provisioned VPN 282 solutions designed to carry customers' multicast traffic. The main 283 requirement is that a solution SHOULD first satisfy the requirements 284 documented in [RFC4031]: as far as possible, a multicast service 285 should have the same characteristics as the unicast equivalent, 286 including the same simplicity (technology unaware), the same quality 287 of service (if any), the same management (e.g. performance 288 monitoring), etc. 290 Moreover, it also has to be clear that a multicast VPN solution MUST 291 interoperate seamlessly with current unicast VPN solutions. It would 292 also make sense that multicast VPN solutions define themselves as 293 extensions to existing L3 provider-provisioned VPN solutions (such as 294 for instance, [RFC4364] or [VRs]) and retain consistency with those, 295 although this is not a core requirement. 297 The requirements in this document are equally applicable to IPv4 and 298 IPv6, for both customer and provider related matters. 300 3.3. Scaling vs. Optimizing Resource Utilization 302 When transporting multicast VPN traffic over a service provider 303 network, there intrinsically is tension between scalability and 304 resource optimization, since the latter is likely to require the 305 maintenance of control plane states related to replication trees in 306 the core network [RFC3353]. 308 Consequently, any deployment will require a trade-off to be made and 309 this document will express some requirements related to this trade- 310 off. 312 4. Use cases 314 The goal of this section is to highlight how different applications 315 and network contexts may have a different impact on how a multicast 316 VPN solution is designed, deployed and tuned. For this purpose we 317 describe some typical use case scenarios and express expectations in 318 terms of deployment orders of magnitude. 320 Most of the content of these sections originates from a survey done 321 in summer 2005, among institutions and providers that expect to 322 deploy such solutions. The full survey text, and raw results (13 323 responses) were published separately and we only present here the 324 most relevant facts and expectations that the survey exposed. 326 For scalability figures, we considered that it was relevant to 327 highlight the highest expectations, those that are expected to have 328 the greatest impact on solution design ; for balance, we do also 329 mention cases where such high expectations were expressed in only a 330 few answers. 332 4.1. Scenarios 334 We don't provide here an exhaustive set of scenarios that a multicast 335 VPN solution is expected to support - no solution should restrict the 336 scope of multicast applications and deployments that can be done over 337 a multicast VPN. 339 Hence, we only give here a short list of scenarios that are expected 340 to have a large impact on the design of a multicast VPN solution. 342 4.1.1. Live content broadcast 344 Under this label, we group all applications that distribute content 345 (audio, video, or other content) with the property that this content 346 is expected to be consulted at once ("live") by the receiver. 347 Typical applications are broadcast TV, production studios 348 connectivity, distribution of market data feeds. 350 The characteristics of such applications are the following: 352 o one or few sources to many receivers 354 o sources are often in known locations, receivers are in less 355 predictable locations (this latter point may depend on 356 applications) 358 o in some cases, it is expected that the regularity of audience 359 patterns may help improve how the bandwidth/state trade-off is 360 handled 362 o the number of streams can be as high as hundreds, or even 363 thousands of streams 365 o bandwidth will depend on the application, but may vary between a 366 few tens/hundreds of Kb/s (e.g audio or low quality video media) 367 and tens of Mb/s (high quality video), with some demanding 368 professional applications requiring as much as hundreds of Mb/s. 370 o QoS requirements include, in many cases, a low multicast group 371 join delay 373 o QoS of these applications is likely to be impacted by packet loss 374 (some applications may be robust to low packet loss), and to have 375 low robustness against jitter 377 o delay sensitivity will depend on the application: some 378 applications are not so delay sensitive (e.g. broadcast TV), 379 whereas others may require very low delay (professional studio 380 applications) 382 o some of these applications may involve rapid changes in customer 383 multicast memberships as seen by the PE, but this will depend on 384 audience patterns and on the amount of provider equipments 385 deployed close to VPN customers 387 4.1.2. Symmetric applications 389 Some use cases exposed by the survey can be grouped under this label, 390 and include many-to-many applications such as conferencing, server 391 clusters monitoring. 393 They are characterized by the relatively high number of streams that 394 they can produce, which has a direct impact on scalability 395 expectations. 397 A sub-case of this scenario is the case of symmetric applications 398 with small groups, when the number of receivers is low compared to 399 the number of sites in the VPNs (e.g.: video conferencing and 400 e-learning applications). 402 This latter case is expected to be an important input to solution 403 design, since it may significantly impact how the bandwidth/state is 404 managed. 406 Because of: 408 o small groups, and low predictability of the location of 409 participants ("sparse groups") 411 o possibly significantly high bandwidth (a few Mb/s per participant) 413 ...optimizing bandwidth may require introducing dedicated states in 414 the core network (typically as much as the number of groups). 416 Lastly, some of these applications may involve realtime interactions, 417 and will be highly sensitive to packet loss, jitter and delay. 419 4.1.3. Data distribution 421 Some applications which are expected to be deployed on multicast VPNs 422 are non-realtime applications aimed at distributing data from few 423 sources to many receivers. 425 Such applications may be considered to have lower expectations than 426 their counterparts proposed in this document, since they would not 427 necessarily involve more data streams and are more likely to adapt to 428 the available bandwidth and to be robust to packet loss, jitter and 429 delay. 431 One important property is that such applications may involve higher 432 bandwidths (hundreds of Mb/s). 434 4.1.4. Generic multicast VPN offer 436 This ISP scenario is a deployment scenario where IP-Multicast 437 connectivity is proposed for every VPN: if a customer requests a VPN, 438 then this VPN will support IP-Multicast by default. In this case the 439 number of multicast VPNs equals the number of VPNs. This implies a 440 quite important scalability requirement (e.g. hundreds of PEs, 441 hundreds of VPNs per PE, with a potential increase by one order of 442 magnitude in the future). 444 The per mVPN traffic behavior is not predictable because how the 445 service is used is completely up to the customer. This results in a 446 traffic mix of the scenarios mentioned in section 4.1. QoS 447 requirements are similar to typical unicast scenarios, with the need 448 for different classes. Also in such a context, a reasonably large 449 range of protocols should be made available to the customer for use 450 at the PE-CE level. 452 Also, in such a scenario, customers may want to deploy multicast 453 connectivity between two or more multicast VPNs as well as access to 454 Internet Multicast. 456 4.2. Scalability orders of magnitude 458 This section proposes orders of magnitude for different scalability 459 metrics relevant for multicast VPN issues. It should be noted that 460 the scalability figures proposed here relate to scalability 461 expectations of future deployments of multicast VPN solutions, as the 462 authors chose to not restrict the scope to only currently known 463 deployments. 465 4.2.1. Number of VPNs with multicast enabled 467 From the survey results, we see a broad range of expectations. There 468 are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), 469 but more typical answers are split between the low range -tens of 470 VPNs- (7 answers) or in the higher range of hundreds or thousands of 471 VPNs (2 + 4 answers). 473 A solution SHOULD support a number of multicast VPNs ranging from one 474 to several thousands. 476 A solution SHOULD NOT limit the proportion of multicast VPNs among 477 all (unicast) VPNs. 479 4.2.2. Number of multicast VPNs per PE 481 The majority of survey answers express a number of multicast VPNs per 482 PE of around tens (8 responses between 5 and 50); a significant 483 number of them (4) expect deployments with hundreds or thousands (1 484 response) of multicast VPNs per PE. 486 A solution SHOULD support a number of multicast VPNs per PE of 487 several hundreds, and may have to scale up to thousands of VPNs per 488 PE. 490 4.2.3. Number of CEs per multicast VPN per PE 492 Survey responses span from 1 to 2000 CEs per multicast VPN per PE. 493 Most typical responses are between tens (6 answers) and hundreds (4 494 responses). 496 A solution SHOULD support a number of CEs per multicast VPN per PE 497 going up to several hundreds (and may target the support of thousands 498 of CEs). 500 4.2.4. PEs per multicast VPN 502 People who answered the survey typically expect deployments with 503 number of PEs per multicast VPN in the range of hundreds of PEs (6 504 responses) or tens of PEs (4 responses). Two responses were in the 505 range of thousands (one mentioned a 10k figure). 507 A multicast VPN solution SHOULD support several hundreds of PEs per 508 multicast VPN, and MAY usefully scale up to thousands. 510 4.2.4.1. ... with sources 512 The number of PEs, per VPN, that would be connected to sources, seems 513 to be significantly lower than the number of PEs per VPN. This is 514 obviously related to the fact that many respondents mentioned 515 deployments related to content broadcast applications (one to many). 517 Typical numbers are of tens of source-connected-PEs (6 responses), or 518 hundreds (4 responses). One respondent expected a higher number of 519 several thousands. 521 A solution SHOULD support hundreds of source-connected-PEs per VPN, 522 and some deployment scenarios involving many-to-many applications, 523 may require supporting a number of source-connected-PEs equal to the 524 number of PEs (hundreds or thousands). 526 4.2.4.2. ... with receivers 528 The survey showed that the number of PEs with receivers is expected 529 to be of the same order of magnitude as the number of PEs in a 530 multicast VPN. This is consistent with the intrinsic nature of most 531 multicast applications, which have few source only participants. 533 4.2.5. PEs with multicast VRFs 535 A solution SHOULD scale up to thousands of PEs having multicast 536 service enabled. 538 4.2.6. Number of streams sourced 540 Survey responses led us to retain the following orders of magnitude 541 for the number of streams that a solution SHOULD support: 543 per VPN: hundreds or thousands of streams 545 per PE: hundreds of streams 547 5. Requirements for supporting IP multicast within L3 PPVPNs 549 Again, the aim of this document is not to specify solutions but to 550 give requirements for supporting IP multicast within L3 PPVPNs. 552 In order to list these requirements we have taken the standpoint of 553 two different important entities: the end user (the customer using 554 the VPN) and the service provider. 556 In the rest of the document, by "a solution" or "a multicast VPN 557 solution", we mean a solution that allows multicast in an L3 558 provider-provisioned VPN, and which addresses the requirements listed 559 in this document. 561 5.1. End user/customer standpoint 563 5.1.1. Service definition 565 As for unicast, the multicast service MUST be provider provisioned 566 and SHALL NOT require customer devices (CEs) to support any extra 567 features compared to those required for multicast in a non-VPN 568 context. Enabling a VPN for multicast support SHOULD be possible 569 with no (or very limited impact) on existing multicast protocols 570 possibly already deployed on the CE devices. 572 5.1.2. CE-PE Multicast routing and group management protocols 574 Consequently to Section 5.1.1, multicast-related protocol exchanges 575 between a CE and its directly connected PE SHOULD happen via existing 576 multicast protocols. 578 Such protocols include: PIM-SM [RFC4601], bidirectional-PIM 579 [I-D.ietf-pim-bidir], PIM-DM [RFC3973], and IGMPv3 [RFC3376] (this 580 version implicitly supports hosts that only implements IGMPv1 581 [RFC1112] or IGMPv2 [RFC2236]). 583 Among those protocols, the support of PIM-SM (which includes the SSM 584 model) and either IGMPv3 (for IPv4 solutions) and / or MLDv2 585 [RFC3810] (for IPv6 solutions) is REQUIRED. Bidir-PIM Support at the 586 PE-CE interface is RECOMMENDED. And considering deployments, PIM-DM 587 is considered as OPTIONAL. 589 When a multicast VPN solution is built on a VPN solution supporting 590 IPv6 unicast, it MUST also support v6 variants of the above 591 protocols, including MLDv2, and PIM-SM IPv6 specific procedures. For 592 a multicast VPN solution built on a unicast VPN solution supporting 593 only IPv4, it is RECOMMENDED that the design favors the definition of 594 procedures and encodings that will provide an easy adaptation to 595 IPv6. 597 5.1.3. Quality of Service (QoS) 599 Firstly, general considerations regarding QoS in L3VPNs expressed in 600 section 5.5 of [RFC4031] are also relevant to this section. 602 QoS is measured in terms of delay, jitter, packet loss, and 603 availability. These metrics are already defined for the current 604 unicast PPVPN services, and are included in Service Level Agreements 605 (SLAs). In some cases, the agreed SLA may be different between 606 unicast and multicast, and that will require differentiation 607 mechanisms in order to monitor both SLAs. 609 The level of availability for the multicast service SHOULD be on par 610 with what exists for unicast traffic. For instance comparable 611 traffic protection mechanisms SHOULD be available for customer 612 multicast traffic when it is carried over the service provider's 613 network. 615 A multicast VPN solution SHALL allow a service provider to define at 616 least the same level of quality of service as exists for unicast, and 617 as exists for multicast in a non-VPN context. From this perspective, 618 the deployment of multicast-based services within an L3VPN 619 environment SHALL benefit from DiffServ [RFC2475] mechanisms that 620 include multicast traffic identification, classification and marking 621 capabilities, as well as multicast traffic policing, scheduling and 622 conditioning capabilities. Such capabilities MUST therefore be 623 supported by any participating device in the establishment and the 624 maintenance of the multicast distribution tunnel within the VPN. 626 As multicast is often used to deliver high quality services such as 627 TV broadcast, a multicast VPN solution MAY provide additional 628 features to support high QoS such as bandwidth reservation and 629 admission control. 631 Also, considering that multicast reception is receiver-triggered, 632 group join delay (as defined in [RFC2432]) is also considered one 633 important QoS parameter. It is thus RECOMMENDED that a multicast VPN 634 solution be designed appropriately in this regard. 636 The group leave delay (as defined in [RFC2432]) may also be important 637 on the CE-PE link for some usage scenarios: in cases where the 638 typical bandwidth of multicast streams is close to the bandwidth of a 639 PE-CE link, it will be important to have the ability to stop the 640 emission of a stream on the PE-CE link as soon as it stops being 641 requested by the CE, to allow for fast switching between two 642 different high throughput multicast streams. This implies that it 643 SHOULD be possible to tune the multicast routing or group management 644 protocols (e.g. IGMP/MLD or PIM) used on the PE-CE adjacency to 645 reduce the group leave delay to the minimum. 647 Lastly, a multicast VPN solution SHOULD as much as possible ensure 648 that client multicast traffic packets are neither lost nor 649 duplicated, even when changes occur in the way a client multicast 650 data stream is carried over the provider network. Packet loss issues 651 have also to be considered when a new source starts to send traffic 652 to a group: any receiver interested in receiving such traffic SHOULD 653 be serviced accordingly. 655 5.1.4. Operations and Management 657 The requirements and definitions for operations and management of 658 L3VPNs that are defined in [RFC4176] equally apply to multicast, and 659 are not extensively repeated in this document. This sub-section 660 mentions the most important guidelines and details points of 661 particular relevance in the context of multicast in L3VPNs. 663 A multicast VPN solution SHOULD allow a multicast VPN customer to 664 manage the capabilities and characteristics of their multicast VPN 665 services. 667 A multicast VPN solution MUST support SLA monitoring capabilities, 668 which SHOULD rely upon techniques similar to those used for the 669 unicast service for the same monitoring purposes. Multicast SLA- 670 related metrics SHOULD be available through means similar to the ones 671 already used for unicast-related monitoring, such as SNMP[RFC3411] or 672 IPFIX[I-D.ietf-ipfix-protocol]. 674 Multicast specific characteristics that may be monitored include: 675 multicast statistics per stream, end-to-end delay, group join/leave 676 delay (time to start/stop receiving a multicast group's traffic 677 across the VPN, as defined in [RFC2432], Section 3). 679 The monitoring of multicast specific parameters and statistics MUST 680 include multicast traffic statistics: total/incoming/outgoing/dropped 681 traffic, by period of time ; and MAY include IP Performance Metrics 682 related information (IPPM, [RFC2330]) that is relevant to the 683 multicast traffic usage: such information includes the one-way packet 684 delay, the inter-packet delay variation, etc 685 ([I-D.ietf-ippm-multimetrics]). 687 A generic discussion of SLAs is provided in [RFC3809]. 689 Apart from statistics on multicast traffic, customers of a multicast 690 VPN will need information concerning the status of their multicast 691 resource usage (multicast routing states and bandwidth). Indeed, as 692 mentioned in Section 5.2.5, for scalability purposes, a service 693 provider may limit the number (and/or throughput) of multicast 694 streams that are received/sent to/from a client site. In such a 695 case, a multicast VPN solution SHOULD allow customers to find out 696 their current resource usage (multicast routing states and 697 throughput), and to receive some kind of feedback if their usage 698 exceeds the agreed bounds. Whether this issue will be better handled 699 at the protocol level at the PE-CE interface or at the Service 700 Management Level interface [RFC4176], is left for further discussion. 702 It is RECOMMENDED that any OAM mechanism designed to trigger alarms 703 in relation to performance or resource usage metrics, integrate the 704 ability to limit the rate at which such alarms are generated (e.g. 705 some form of an hysteresis mecanism based on low/high thresholds 706 defined for the metrics). 708 5.1.5. Security Requirements 710 Security is a key point for a customer who uses subscribes to a VPN 711 service. For instance, the [RFC4364] model offers some guarantees 712 concerning the security level of data transmission within the VPN. 714 A multicast VPN solution MUST provide an architecture with the same 715 level of security for both unicast and multicast traffic. 717 Moreover, the activation of multicast features SHOULD be possible: 719 o per VRF / per VR 721 o per CE interface (when multiple CEs of a VPN are connected to a 722 common VRF/VR) 724 o per multicast group and/or per channel 726 o with a distinction between multicast reception and emission 728 A multicast VPN solution may choose to make the optimality/ 729 scalability trade-off stated in Section 3.3 by sometimes distributing 730 multicast traffic of a client group to a larger set of PE routers 731 that may include PEs which are not part of the VPN. From a security 732 standpoint, this may be a problem for some VPN customers, thus a 733 multicast VPN solution using such a scheme MAY offer ways to avoid 734 this for specific customers (and/or specific customer multicast 735 streams). 737 5.1.6. Extranet 739 In current PP L3VPN models, a customer site may be setup to be part 740 of multiple VPNs and this should still be possible when a VPN is 741 multicast-enabled. In practice it means that a VRF or VR can be part 742 of more than one VPN. 744 A multicast VPN solution MUST support such deployments. 746 For instance, it must be possible to configure a VRF so that an 747 enterprise site participating in a BGP/MPLS multicast-enabled VPN and 748 connected to that VRF, can receive a multicast stream from, [or 749 originate a multicast stream towards], another VPN that would be 750 associated to that VRF. 752 This means that a multicast VPN solution MUST offer means for a VRF 753 to be configured so that multicast connectivity can be setup for a 754 chosen set of extranet VPNs. More precisely, it MUST be possible to 755 configure a VRF so that: 757 o receivers behind attached CEs can receive multicast traffic 758 sourced in the configured set of extranet VPNs 760 o sources behind attached CEs can reach multicast traffic receivers 761 located in the configured set of extranet VPNs 763 o multicast reception and emission can be independently enabled for 764 each of the extranet VPNs 766 Moreover, a solution MUST allow service providers to control an 767 extranet's multicast connectivity independently from the extranet's 768 unicast connectivity. More specifically: 770 o enabling unicast connectivity to another VPN MUST be possible 771 without activating multicast connectivity with that VPN 773 o enabling multicast connectivity with another VPN SHOULD NOT 774 require more than the strict minimal unicast routing : sending 775 multicast to a VPN SHOULD NOT require having unicast routes to 776 that VPN, receiving multicast from a VPN SHOULD be possible with 777 nothing more than unicast routes to the relevant multicast sources 778 of that VPN 780 o when unicast routes from another VPN are imported into a VR/VRF, 781 for multicast RPF resolution, this SHOULD be possible without 782 making those routes available for unicast routing 784 Proper support for this feature SHOULD NOT require replicating 785 multicast traffic on a PE-CE link, whether it is a physical or 786 logical link. 788 5.1.7. Internet Multicast 790 Connectivity with Internet Multicast is a particular case of the 791 previous section, where sites attached to a VR/VRF would need to 792 receive/send multicast traffic from/to the Internet. 794 This should be considered OPTIONAL given the additional 795 considerations, such as security, needed to fulfill the requirements 796 for providing Internet Multicast. 798 5.1.8. Carrier's carrier 800 Many L3 PPVPN solutions, such as [RFC4364] and [VRs] define the 801 "Carrier's Carrier" model, where a "carrier's carrier" service 802 provider supports one or more customer ISP, or "sub-carriers". A 803 multicast VPN solution SHOULD support the carrier's carrier model in 804 a scalable and efficient manner. 806 Ideally the range of tunneling protocols available for the sub- 807 carrier ISP should be the same as those available for the carrier's 808 carrier ISP. This implies that the protocols that may be used at the 809 PE-CE level SHOULD NOT be restricted to protocols required as per 810 Section 5.1.2 and SHOULD include some of the protocols listed in 811 Section 5.2.4, such as for instance P2MP MPLS signaling protocols. 813 In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs 814 [RFC4364], this means that MPLS label distribution SHOULD happen at 815 the PE-CE level, giving the ability to the sub-carrier to use 816 multipoint LSPs as a tunneling mechanism. 818 5.1.9. Multi-homing, load balancing and resiliency 820 A multicast VPN solution SHOULD be compatible with current solutions 821 that aim at improving the service robustness for customers such as 822 multi-homing, CE-PE link load balancing and fail-over. A multicast 823 VPN solution SHOULD also be able to offer those same features for 824 multicast traffic. 826 Any solution SHOULD support redundant topology of CE-PE links. It 827 SHOULD minimize multicast traffic disruption and fail-over. 829 5.1.10. RP Engineering 831 When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer 832 side, the RP function (or RP-address in the case of bidir-PIM) has to 833 be associated to a node running PIM, and configured on this node. 835 5.1.10.1. RP Outsourcing 837 In the case of PIM-SM in ASM mode, engineering of the RP function 838 requires the deployment of specific protocols and associated 839 configurations. A service provider may offer to manage customers' 840 multicast protocol operation on their behalf. This implies that it 841 is necessary to consider cases where a customer's RPs are out-sourced 842 (e.g., on PEs). Consequently, a VPN solution MAY support the hosting 843 of the RP function in a VR or VRF. 845 5.1.10.2. RP Availability 847 Availability of the RP function (or address) is required for proper 848 operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity 849 to the RP from a receiver or source will impact the multicast 850 service. For this reason different mechanisms exist, such as BSR 851 [I-D.ietf-pim-sm-bsr] or anycast-RP (MSDP based [RFC3446] or PIM 852 based [RFC4610]). 854 These protocols and procedures SHOULD work transparently through a 855 multicast VPN, and MAY if relevant, be implemented in a VRF/VR. 857 Moreover, a multicast VPN solution MAY improve the robustness of the 858 ASM multicast service regarding loss of connectivity to the RP, by 859 providing specific features that help : 861 a) maintain ASM multicast service among all the sites within an MVPN 862 that maintain connectivity among themselves, even when the site(s) 863 hosting the RP lose their connectivity to the MVPN 865 b) maintain ASM multicast service within any site that loses 866 connectivity to the service provider 868 5.1.10.3. RP Location 870 In the case of PIM-SM, when a source starts to emit traffic toward a 871 group (in ASM mode), if sources and receivers are located in VPN 872 sites that are different than that of the RP, then traffic may 873 transiently flow twice through the SP network and the CE-PE link of 874 the RP (from source to RP, and then from RP to receivers). This 875 traffic peak, even short, may not be convenient depending on the 876 traffic and link bandwidth. 878 Thus, a VPN solution MAY provide features that solve or help mitigate 879 this potential issue. 881 5.1.11. Addressing 883 A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions 884 on multicast group addresses used by VPN customers. 886 In particular, like unicast traffic, an overlap of multicast group 887 address sets used by different VPN customers MUST be supported. 889 The use of globally unique means of multicast-based service 890 identification at the scale of the domain where such services are 891 provided SHOULD be recommended. For IPv4 multicast, this implies the 892 use of the multicast administratively scoped range, (239/8 as defined 893 by [RFC2365]) for services which are to be used only inside the VPN, 894 and of either SSM-range addresses (232/8 as defined by [RFC4607]) or 895 globally assigned group addresses (e.g. GLOP [RFC3180], 233/8) for 896 services for which traffic may be transmitted outside the VPN. 898 5.1.12. Minimum MTU 900 For customers, it is often a serious issue whether transmitted 901 packets will be fragmented or not. In particular, some multicast 902 applications might have different requirements than those that make 903 use of unicast, and they may expect services that guarantee available 904 packet length not to be fragmented. 906 Therefore, a multicast VPN solution SHOULD be designed with these 907 considerations in mind. In practice: 909 o the encapsulation overhead of a multicast VPN solution SHOULD be 910 minimized, so that customer devices can be free of fragmentation 911 and reassembly activity as much as possible 913 o a multicast VPN solution SHOULD enable the service provider to 914 commit to a minimum path MTU usable by multicast VPN customers 916 o a multicast VPN solution SHOULD be compatible with path MTU 917 discovery mechanisms (see [RFC1191] and [RFC4459]), and particular 918 care SHOULD be given to means to help troubleshoot MTU issues 920 Moreover, since Ethernet LAN segments are often located at first and 921 last hops, a multicast VPN solution SHOULD be designed to allow for a 922 minimum 1500 byte IP MTU for VPN customers multicast packet, when the 923 provider backbone design allows it. 925 5.2. Service provider standpoint 927 Note: To avoid repetition and confusion with terms used in solution 928 specifications, we introduced in Section 2.1 the term MDTunnel (for 929 Multicast Distribution Tunnel), which designates the data plane means 930 used by the service provider to forward customer multicast traffic 931 over the core network. 933 5.2.1. General requirement 935 The deployment of a multicast VPN solution SHOULD be possible with no 936 (or very limited) impact on existing deployments of standardized 937 multicast related protocols on P and PE routers. 939 5.2.2. Scalability 941 Some currently standardized and deployed L3VPN solutions have the 942 major advantage of being scalable in the core regarding the number of 943 customers and the number of customer routes. For instance, in the 944 [RFC4364] and VRs [I-D.ietf-l3vpn-vpn-vr] models, a P router sees a 945 number of MPLS tunnels that is only linked to the number of PEs and 946 not to the number of VPNs, or customer sites. 948 As far as possible, this independence in the core, with respect to 949 the number of customers and to customer activity, is recommended. 950 Yet, it is recognized that in our context scalability and resource 951 usage optimality are competing goals, so this requirement may be 952 reduced to giving the possibility of bounding the quantity of states 953 that the service provider needs to maintain in the core for 954 MDTunnels, with a bound being independent of the multicast activity 955 of VPN customers. 957 It is expected that multicast VPN solutions will use some kind of 958 point-to-multipoint technology to efficiently carry multicast VPN 959 traffic, and because such technologies require maintaining state 960 information, this will use resources in the control plane of P and PE 961 routers (memory and processing, and possibly address space). 963 Scalability is a key requirement for multicast VPN solutions. 964 Solutions MUST be designed to scale well with an increase in the 965 number of any of the following: 967 o the number of PEs 969 o the number of customer VPNs (total and per PE) 971 o the number of PEs and sites in any VPN 973 o the number of client multicast channels (groups or source-groups) 975 Please consult section 4.2 for typical orders of magnitude up to 976 which a multicast VPN solution is expected to scale 977 Scalability of both performance and operation MUST be considered. 979 Key considerations SHOULD include: 981 o the processing resources required by the control plane 982 (neighborhood or session maintenance messages, keep-alives, 983 timers, etc.) 985 o the memory resources needed for the control plane 987 o the amount of protocol information transmitted to manage a 988 multicast VPN (e.g. signaling throughput) 990 o the amount of control plane processing required on PE and P 991 routers to add or remove a customer site (or a customer from a 992 multicast session) 994 o the number of multicast IP addresses used (if IP multicast in ASM 995 mode is proposed as a multicast distribution tunnel) 997 o other particular elements inherent to each solution that impact 998 scalability (e.g., if a solution uses some distribution tree 999 inside the core, topology of the tree and number of leaf nodes may 1000 be some of them) 1002 It is expected that the applicability of each solution will be 1003 evaluated with regards to the aforementioned scalability criteria. 1005 These considerations naturally lead us to believe that proposed 1006 solutions SHOULD offer the possibility of sharing such resources 1007 between different multicast streams (between different VPNs, between 1008 different multicast streams of the same or of different VPNs). This 1009 means for instance, if MDTunnels are trees, being able to share an 1010 MDTunnel between several customers. 1012 Those scalability issues are expected to be more significant on P 1013 routers, but a multicast VPN solution SHOULD address both P and PE 1014 routers as far as scalability is concerned. 1016 5.2.3. Resource optimization 1018 5.2.3.1. General goals 1020 One of the aims of the use of multicast instead of unicast is 1021 resource optimization in the network. 1023 The two obvious suboptimal behaviors that a multicast VPN solution 1024 would want to avoid are needless duplication (when the same data 1025 travels twice or more on a link, e.g. when doing ingress PE 1026 replication) and needless reception (e.g. a PE receiving traffic that 1027 it does not need because there are no downstream receivers). 1029 5.2.3.2. Trade-off and tuning 1031 As previously stated in this document, designing a scalable solution 1032 that makes an optimal use of resources is considered difficult. Thus 1033 what is expected from a multicast VPN solution is that it addresses 1034 the resource optimization issue while taking into account the fact 1035 that some trade-off has to be made. 1037 Moreover, it seems that a "one size fits all" trade-off probably does 1038 not exist either. Thus a multicast VPN solution SHOULD offer service 1039 providers appropriate configuration settings that let them tune the 1040 trade-off according to their particular constraints (network 1041 topology, platforms, customer applications, level of service offered 1042 etc.). 1044 As an illustration here are some example bounds of the trade-off 1045 space: 1047 Bandwidth optimization: setting up optimized core MDTunnels whose 1048 topology (PIM or P2MP LSP trees, etc.) precisely follows a 1049 customer's multicast routing changes. This requires managing a 1050 large amount of state in the core, and also quick reactions of the 1051 core to customer multicast routing changes. This approach can be 1052 advantageous in terms of bandwidth, but it is poor in terms of 1053 state management. 1055 State optimization: setting up MDTunnels that aggregate multiple 1056 customer multicast streams (all or some of them, across different 1057 VPNs or not). This will have better scalability properties, but 1058 at the expense of bandwidth since some MDTunnel leaves will very 1059 likely receive traffic they don't need, and because increased 1060 constraints will make it harder to find optimal MDTunnels. 1062 5.2.3.3. Traffic engineering 1064 If the VPN service provides traffic engineering features for the 1065 connection used between PEs for unicast traffic in the VPN service, 1066 the solution SHOULD provide equivalent features for multicast 1067 traffic. 1069 A solution SHOULD offer means to support key TE objectives as defined 1070 in [RFC3272], for the multicast service. 1072 A solution MAY also usefully support means to address multicast- 1073 specific traffic engineering issues: it is known that bandwidth 1074 resource optimization in the point-to-multipoint case is an NP-hard 1075 problem, and that techniques used for unicast TE may not be 1076 applicable to multicast traffic. 1078 Also, it has been identified that managing the trade-off between 1079 resource usage and scalability may incur uselessly sending traffic to 1080 some PEs participating in a multicast VPN. For this reason, a 1081 multicast VPN solution MAY permit that the bandwidth/state tuning 1082 take into account the relative cost or availability of bandwidth 1083 toward each PE. 1085 5.2.4. Tunneling Requirements 1087 5.2.4.1. Tunneling technologies 1089 Following the principle of separation between the control plane and 1090 the forwarding plane, a multicast VPN solution SHOULD be designed so 1091 that control and forwarding planes are not interdependent: the 1092 control plane SHALL NOT depend on which forwarding plane is used (and 1093 vice versa), and the choice of forwarding plane SHOULD NOT be limited 1094 by the design of the solution. Also, the solution SHOULD NOT be tied 1095 to a specific tunneling technology. 1097 In a multicast VPN solution extending a unicast L3 PPVPN solution, 1098 consistency in the tunneling technology has to be favored: such a 1099 solution SHOULD allow the use of the same tunneling technology for 1100 multicast as for unicast. Deployment consistency, ease of operation 1101 and potential migrations are the main motivations behind this 1102 requirement. 1104 For MDTunnels, a solution SHOULD be able to use a range of tunneling 1105 technologies, including point-to-point and point-to-multipoint, such 1106 as GRE [RFC2784] (including GRE in multicast IP trees), MPLS 1107 [RFC3031] (including P2P or MP2P tunnels, and multipoint tunnels 1108 signaled with MPLS P2MP extensions to RSVP 1109 [I-D.ietf-mpls-rsvp-te-p2mp] or LDP 1110 [I-D.ietf-mpls-mp-ldp-reqs][I-D.ietf-mpls-ldp-p2mp]), L2TP (including 1111 L2TP for multicast [RFC4045]), IPsec [RFC4031], IP-in-IP [RFC2003], 1112 etc. 1114 Naturally, it is RECOMMENDED that a solution is built so that it can 1115 leverage the point to multipoint variants of these techniques, that 1116 allow for packet replications to happen along a tree in the provider 1117 core network, and may help improve bandwidth efficiency in a 1118 multicast VPN context. 1120 5.2.4.2. MTU and Fragmentation 1122 A solution SHOULD support a method that provides the minimum MTU of 1123 the MDTunnel (e.g., to discover MTU, to communicate MTU via 1124 signaling, etc.) so that: 1126 o fragmentation inside the MDTunnel does not happen, even when 1127 allowed by the underlying tunneling technology 1129 o proper troubleshooting can be performed if packets that are too 1130 big for the MDTunnel happen to be encapsulated in the MDTunnel 1132 5.2.5. Control mechanisms 1134 The solution MUST provide some mechanisms to control the sources 1135 within a VPN. This control includes the number of sources that are 1136 entitled to send traffic on the VPN, and/or the total bit rate of all 1137 the sources. 1139 At the reception level, the solution MUST also provide mechanisms to 1140 control the number of multicast groups or channels VPN users are 1141 entitled to subscribe to and/or the total bit rate represented by the 1142 corresponding multicast traffic. 1144 All these mechanisms MUST be configurable by the service provider in 1145 order to control the amount of multicast traffic and state within a 1146 VPN. 1148 Moreover it MAY be desirable to be able to impose some bound on the 1149 quantity of state used by a VPN in the core network for its multicast 1150 traffic, whether on each P or PE router, or globally. The motivation 1151 is that it may be needed to avoid out-of-resources situations (e.g. 1152 out of memory to maintain PIM state if IP multicast is used in the 1153 core for multicast VPN traffic, or out of memory to maintain RSVP 1154 state if MPLS P2MP is used, etc.). 1156 5.2.6. Support of Inter-AS, inter-provider deployments 1158 A solution MUST support inter-AS multicast VPNs, and SHOULD support 1159 inter-provider multicast VPNs. Considerations about coexistence with 1160 unicast inter-AS VPN Options A, B and C (as described in section 10 1161 of [RFC4364]) are strongly encouraged. 1163 A multicast VPN solution SHOULD provide inter-AS mechanisms requiring 1164 the least possible coordination between providers, and keep the need 1165 for detailed knowledge of providers' networks to a minimum - all this 1166 being in comparison with corresponding unicast VPN options. 1168 o Within each service provider the service provider SHOULD be able 1169 on its own to pick the most appropriate tunneling mechanism to 1170 carry (multicast) traffic among PEs (just like what is done today 1171 for unicast) 1173 o If a solution does require a single tunnel to span P routers in 1174 multiple ASs, the solution SHOULD provide mechanisms to ensure 1175 that the inter-provider co-ordination to setup such a tunnel is 1176 minimized 1178 Moreover such support SHOULD be possible without compromising other 1179 requirements expressed in this requirement document, and SHALL NOT 1180 incur penalties on scalability and bandwidth-related efficiency. 1182 5.2.7. Quality of Service Differentiation 1184 A multicast VPN solution SHOULD give a VPN service provider the 1185 ability to offer, guarantee and enforce differentiated levels of QoS 1186 for its different customers. 1188 5.2.8. Infrastructure security 1190 The solution SHOULD provide the same level of security for the 1191 service provider as what currently exists for unicast VPNs (for 1192 instance, as developed in the Security sections of [RFC4364] and 1193 [I-D.ietf-l3vpn-vpn-vr]). For instance, traffic segregation and 1194 intrinsic protection against DOS and DDOS attacks of the BGP/MPLS VPN 1195 solution must be supported by the multicast solution. 1197 Moreover, since multicast traffic and routing are intrinsically 1198 dynamic (receiver-initiated), some mechanism SHOULD be proposed so 1199 that the frequency of changes in the way client traffic is carried 1200 over the core can be bounded and not tightly coupled to dynamic 1201 changes of multicast traffic in the customer network. For example, 1202 multicast route dampening functions would be one possible mechanism. 1204 Network devices that participate in the deployment and the 1205 maintenance of a given L3VPN MAY represent a superset of the 1206 participating devices that are also involved in the establishment and 1207 the maintenance of the multicast distribution tunnels. As such the 1208 activation of IP multicast capabilities within a VPN SHOULD be 1209 device-specific, not only to make sure that only the relevant devices 1210 will be multicast-enabled, but also to make sure that multicast 1211 (routing) information will be disseminated to the multicast-enabled 1212 devices only, hence limiting the risk of multicast-inferred DOS 1213 attacks. 1215 Traffic of a multicast channel for which there are no members in a 1216 given multicast VPN MUST NOT be propagated within the multicast VPN, 1217 most particularly if the traffic comes from another VPN or from the 1218 Internet. 1220 Security considerations are particularly important for inter-AS and 1221 inter-provider deployments. In such cases, it is RECOMMENDED that a 1222 multicast VPN solution support means to ensure the integrity and 1223 authenticity of multicast-related exchanges across inter-AS or inter- 1224 provider borders. It is RECOMMENDED that corresponding procedures 1225 require the least possible coordination between providers; more 1226 precisely, when specific configurations or cryptographic keys have to 1227 be deployed, this shall be limited to ASBRs (Autonomous System Border 1228 Routers) or a subset of them, and optionally BGP Route Reflectors (or 1229 a subset of them). 1231 Lastly, control mechanisms described in Section 5.2.5 are also to be 1232 considered from this infrastructure security point of view. 1234 5.2.9. Robustness 1236 Resiliency is also crucial to infrastructure security, thus a 1237 multicast VPN solution SHOULD either avoid single points of failures 1238 or propose some technical solution making it possible to implement a 1239 fail-over mechanism. 1241 As an illustration, one can consider the case of a solution that 1242 would use PIM-SM as a means to setup MDTunnels. In such a case, the 1243 PIM RP might be a single point of failure. Such a solution SHOULD be 1244 compatible with a solution implementing RP resiliency, such as 1245 anycast-RP [RFC4610] or BSR [I-D.ietf-pim-sm-bsr]. 1247 5.2.10. Operation, Administration and Maintenance 1249 The operation of a multicast VPN solution SHALL be as light as 1250 possible and providing automatic configuration and discovery SHOULD 1251 be a priority when designing a multicast VPN solution. Particularly 1252 the operational burden of setting up multicast on a PE or for a VR/ 1253 VRF SHOULD be as low as possible. 1255 Also, as far as possible, the design of a solution SHOULD carefully 1256 consider the number of protocols within the core network: if any 1257 additional protocols are introduced compared with the unicast VPN 1258 service, the balance between their advantage and operational burden 1259 SHOULD be examined thoroughly. 1261 Moreover, monitoring of multicast specific parameters and statistics 1262 SHOULD be offered to the service provider, following the requirements 1263 expressed in [RFC4176]. 1265 Most notably the provider SHOULD have access to: 1267 o Multicast traffic statistics (incoming/outgoing/dropped/total 1268 traffic conveyed, by period of time) 1270 o Information about client multicast resource usage (multicast 1271 routing state and bandwidth usage) 1273 o Alarms when limits are reached on such resources 1275 o The IPPM (IP Performance Metrics [RFC2330]) -related information 1276 that is relevant to the multicast traffic usage: such information 1277 includes the one-way packet delay, the inter-packet delay 1278 variation, etc. 1280 o Statistics on decisions related to how client traffic is carried 1281 on distribution tunnels (e.g. "traffic switched onto a multicast 1282 tree dedicated to such groups or channels") 1284 o Statistics on parameters that could help the provider to evaluate 1285 its optimality/state trade-off 1287 This information SHOULD be made available through standardized 1288 protocols such as SNMP [RFC3411] MIBs (Management Information Bases) 1289 or IPFIX [I-D.ietf-ipfix-protocol]. For instance, in the context of 1290 BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs defined in 1291 [RFC4382] SHOULD be proposed, with proper integration with [RFC3811], 1292 [RFC3812], [RFC3813] and [RFC3814] when applicable. 1294 Mechanisms similar to those described in Section 5.2.12 SHOULD also 1295 exist for proactive monitoring of the MDTunnels. 1297 Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be 1298 scalable with respect to the parameters mentioned in Section 5.2.2. 1299 In particular, it is RECOMMENDED that particular attention is given 1300 to the impact of monitoring mechanisms on performances and QoS. 1302 Moreover, it is RECOMMENDED that any OAM mechanism designed to 1303 trigger alarms in relation to performance or resource usage metrics, 1304 integrate the ability to limit the rate at which such alarms are 1305 generated (e.g. some form of an hysteresis mecanism based on low/high 1306 thresholds defined for the metrics). 1308 5.2.11. Compatibility and migration issues 1310 It is a requirement that unicast and multicast services MUST be able 1311 to co-exist within the same VPN. 1313 Likewise, a multicast VPN solution SHOULD be designed so that its 1314 activation in devices that participate in the deployment and the 1315 maintenance of a multicast VPN SHOULD be as smooth as possible, i.e. 1316 without affecting the overall quality of the services that are 1317 already supported by the underlying infrastructure. 1319 A multicast VPN solution SHOULD prevent compatibility and migration 1320 issues, for instance by focusing on providing mechanisms facilitating 1321 forward compatibility. Most notably a solution supporting only a 1322 subset of the requirements expressed in this document SHOULD be 1323 designed to allow compatibility to be introduced in further 1324 revisions. 1326 It SHOULD be an aim of any multicast VPN solution to offer as much 1327 backward compatibility as possible. Ideally a solution would have 1328 the ability to offer multicast VPN services across a network 1329 containing some legacy routers that do not support any multicast VPN 1330 specific features. 1332 In any case a solution SHOULD state a migration policy from possibly 1333 existing deployments. 1335 5.2.12. Troubleshooting 1337 A multicast VPN solution that dynamically adapts the way some client 1338 multicast traffic is carried over the provider's network may incur 1339 the disadvantage of being hard to troubleshoot. In such a case, to 1340 help diagnose multicast network issues, a multicast VPN solution 1341 SHOULD provide monitoring information describing how client traffic 1342 is carried over the network (e.g. if a solution uses multicast-based 1343 MDTunnels, which provider multicast group is used for a given client 1344 multicast stream). A solution MAY also provide configuration options 1345 to avoid any dynamic changes, for multicast traffic of a particular 1346 VPN or a particular multicast stream. 1348 Moreover, a solution MAY provide mechanisms that allows network 1349 operators to check that all VPN sites that advertised interest in a 1350 particular customer multicast stream are properly associated with the 1351 corresponding MDTunnel. Providing operators with means to check the 1352 proper setup and operation of MDTunnels MAY also be provided (e.g. 1353 when P2MP MPLS is used for MDTunnels, troubleshooting functionalities 1354 SHOULD integrate mechanisms compliant with [RFC4687], such as LSPPing 1355 [RFC4379][I-D.ietf-mpls-p2mp-lsp-ping]). Depending on the 1356 implementation such verification could be initiated by a source-PE or 1357 e receiver-PE. 1359 6. Security Considerations 1361 This document does not by itself raise any particular security issue. 1363 A set of security issues have been identified that MUST be addressed 1364 when considering the design and deployment of multicast-enabled L3 PP 1365 VPNs. Such issues have been described in Section 5.1.5 and 1366 Section 5.2.8. 1368 7. IANA Considerations 1370 This document has no actions for IANA. 1372 8. Contributors 1374 The main contributors to this document are listed below, in 1375 alphabetical order: 1377 o Christian Jacquenet 1378 France Telecom 1379 3, avenue Francois Chateau 1380 CS 36901 35069 RENNES Cedex, France 1381 Email: christian.jacquenet@francetelecom.com 1383 o Yuji Kamite 1384 NTT Communications Corporation 1385 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 1386 Tokyo 163-1421, Japan 1387 Email: y.kamite@ntt.com 1389 o Jean-Louis Le Roux 1390 France Telecom R & D 1391 2, avenue Pierre-Marzin 1392 22307 Lannion Cedex, France 1393 Email: jeanlouis.leroux@francetelecom.com 1395 o Nicolai Leymann 1396 T-Systems International GmbH 1397 Engineering Networks, Products & Services 1398 Goslarer Ufer 3510589 Berlin, Germany 1399 Email: nicolai.leymann@t-systems.com 1401 o Renaud Moignard 1402 France Telecom R & D 1403 2, avenue Pierre-Marzin 1404 22307 Lannion Cedex, France 1405 Email: renaud.moignard@francetelecom.com 1407 o Thomas Morin 1408 France Telecom R & D 1409 2, avenue Pierre-Marzin 1410 22307 Lannion Cedex, France 1411 Email: thomas.morin@francetelecom.com 1413 9. Acknowledgments 1415 The authors would like to thank, by rough chronological order, 1416 Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, 1417 Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel 1418 King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, 1419 Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka 1420 Savola, Benjamin Niven-Jenkins, Thomas Nadeau, for their review, 1421 valuable input and feedback. 1423 We also thank the people who kindly answered the survey, and Daniel 1424 King who took care of gathering and anonymizing its results. 1426 10. References 1428 10.1. Normative references 1430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1431 Requirement Levels", BCP 14, RFC 2119, March 1997. 1433 [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 1434 3 Provider Provisioned Virtual Private Networks (PPVPNs)", 1435 RFC 4031, April 2005. 1437 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1438 Private Network (VPN) Terminology", RFC 4026, March 2005. 1440 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1441 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1442 Protocol Specification (Revised)", RFC 4601, August 2006. 1444 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1445 IP", RFC 4607, August 2006. 1447 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1448 Thyagarajan, "Internet Group Management Protocol, Version 1449 3", RFC 3376, October 2002. 1451 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1452 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1454 [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and 1455 A. Gonguet, "Framework for Layer 3 Virtual Private 1456 Networks (L3VPN) Operations and Management", RFC 4176, 1457 October 2005. 1459 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1460 Independent Multicast - Dense Mode (PIM-DM): Protocol 1461 Specification (Revised)", RFC 3973, January 2005. 1463 10.2. Informative references 1465 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1466 Networks (VPNs)", RFC 4364, February 2006. 1468 [I-D.ietf-l3vpn-vpn-vr] 1469 Ould-Brahim, H., "Network based IP VPN Architecture Using 1470 Virtual Routers", draft-ietf-l3vpn-vpn-vr-03 (work in 1471 progress), March 2006. 1473 [RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", 1474 RFC 2432, October 1998. 1476 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1477 Label Switching Architecture", RFC 3031, January 2001. 1479 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1480 RFC 1112, August 1989. 1482 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1483 2", RFC 2236, November 1997. 1485 [I-D.ietf-mpls-rsvp-te-p2mp] 1486 Aggarwal, R., "Extensions to RSVP-TE for Point-to- 1487 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work 1488 in progress), August 2006. 1490 [I-D.ietf-pim-sm-bsr] 1491 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 1492 draft-ietf-pim-sm-bsr-09 (work in progress), June 2006. 1494 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 1495 Independent Multicast (PIM)", RFC 4610, August 2006. 1497 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 1498 Rendevous Point (RP) mechanism using Protocol Independent 1499 Multicast (PIM) and Multicast Source Discovery Protocol 1500 (MSDP)", RFC 3446, January 2003. 1502 [I-D.ietf-mpls-ldp-p2mp] 1503 Minei, I., "Label Distribution Protocol Extensions for 1504 Point-to-Multipoint and Multipoint-to-Multipoint Label 1505 Switched Paths", draft-ietf-mpls-ldp-p2mp-02 (work in 1506 progress), October 2006. 1508 [I-D.ietf-mpls-mp-ldp-reqs] 1509 Roux, J., "Requirements for point-to-multipoint extensions 1510 to the Label Distribution Protocol", 1511 draft-ietf-mpls-mp-ldp-reqs-01 (work in progress), 1512 June 2006. 1514 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 1515 "Operations and Management (OAM) Requirements for Point- 1516 to-Multipoint MPLS Networks", RFC 4687, September 2006. 1518 [I-D.ietf-pim-bidir] 1519 Handley, M., "Bi-directional Protocol Independent 1520 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in 1521 progress), October 2005. 1523 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1524 October 1996. 1526 [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, 1527 F., and F. Ansari, "Overview of IP Multicast in a Multi- 1528 Protocol Label Switching (MPLS) Environment", RFC 3353, 1529 August 2002. 1531 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 1532 Xiao, "Overview and Principles of Internet Traffic 1533 Engineering", RFC 3272, May 2002. 1535 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1536 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1537 March 2000. 1539 [I-D.ietf-ipfix-protocol] 1540 Claise, B., "Specification of the IPFIX Protocol for the 1541 Exchange", draft-ietf-ipfix-protocol-24 (work in 1542 progress), November 2006. 1544 [RFC4045] Bourdon, G., "Extensions to Support Efficient Carrying of 1545 Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)", 1546 RFC 4045, April 2005. 1548 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 1549 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 1550 June 2004. 1552 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 1553 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 1554 Management", RFC 3811, June 2004. 1556 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1557 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1558 (TE) Management Information Base (MIB)", RFC 3812, 1559 June 2004. 1561 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1562 "Multiprotocol Label Switching (MPLS) Label Switching 1563 Router (LSR) Management Information Base (MIB)", RFC 3813, 1564 June 2004. 1566 [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, 1567 "Multiprotocol Label Switching (MPLS) Forwarding 1568 Equivalence Class To Next Hop Label Forwarding Entry (FEC- 1569 To-NHLFE) Management Information Base (MIB)", RFC 3814, 1570 June 2004. 1572 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1573 RFC 2365, July 1998. 1575 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1576 "Framework for IP Performance Metrics", RFC 2330, 1577 May 1998. 1579 [I-D.ietf-ippm-multimetrics] 1580 Stephan, E., "IP Performance Metrics (IPPM) for spatial 1581 and multicast", draft-ietf-ippm-multimetrics-02 (work in 1582 progress), October 2006. 1584 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1585 and W. Weiss, "An Architecture for Differentiated 1586 Services", RFC 2475, December 1998. 1588 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 1589 BCP 53, RFC 3180, September 2001. 1591 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1592 Architecture for Describing Simple Network Management 1593 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1594 December 2002. 1596 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1597 November 1990. 1599 [RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual 1600 Private Network (VPN) Management Information Base", 1601 RFC 4382, February 2006. 1603 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1604 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1605 February 2006. 1607 [I-D.ietf-mpls-p2mp-lsp-ping] 1608 Farrel, A. and S. Yasukawa, "Detecting Data Plane Failures 1609 in Point-to-Multipoint Multiprotocol", 1610 draft-ietf-mpls-p2mp-lsp-ping-02 (work in progress), 1611 September 2006. 1613 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1614 Network Tunneling", RFC 4459, April 2006. 1616 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1617 June 1999. 1619 Appendix A. Changelog 1621 This section lists changes made to this document (minor or editorial 1622 changes excepted) between major revisions. 1624 It shall be removed before publication as an RFC. 1626 A.1. Changes between -00 and -01 1628 o integrated comments made on L3VPN WG mailing list after -00 1629 submission 1631 o completed Carrier's carrier section (5.1.9) 1633 o updates in sections 5.1 and 5.2 about minimum MTU 1635 o added a section about "Quality of Service Differentiation" as ISP 1636 requirement (section 5.2.5) 1638 o added P2MP LDP extensions as possible MDTunnels techniques 1639 (section 5.2.3.1) 1641 o started to build section 4 "Use Case" 1643 o detailed section 5.1.3 "QoS", most notably about group join and 1644 leave delays 1646 o additions to section 5.2.12 "Inter-AS, inter-provider" 1648 o added MDTunnel verification requirement to section 5.2.11 1650 o moved "Architectural Considerations" section 1652 o moved contributors to top of document 1654 o made draft content agnostic to unicast L3VPN solutions 1656 o added two appendixes: "Changelog" and "Requirement summary" 1658 o conversion to XML [RFC2629] with the help of some scripting and 1659 Bill Fenner's xml2rfc XMLMind plugin 1661 o lot's of editorial changes 1663 A.2. Changes between -01 and -02 1665 o based on survey results: 1667 * restructure use case scenario section 1669 * fill in Scalability orders of magnitude section 1671 * better detail requirements for protocols at the PE-CE level 1673 * add considerations about PEs with scarce connectivity to 1674 section 5.2.3.3 1676 * step up requirement level for Extranet (Section 5.1.6) 1678 o some editorial changes 1680 o use capitalized wording for some requirements 1682 o fill in requirements summary 1684 A.3. Changes between -02 and -03 1686 o made inter-AS a MUST (and moved the whole section up) 1688 o add a requirement about security of multicast-related exchanges 1689 across providers/ASes, in Section 5.2.8 1691 o some editorial changes and fixed typos 1693 A.4. Changes between -03 and -04 1695 o Integrated comments received during last call 1697 o Lots of editorial comments 1699 o Improved terminology section 1701 o Number of VPNs with multicast enabled: A solution SHOULD NOT limit 1702 the proportion of multicast VPNs among all (unicast) VPNs. 1704 o Customer-side service definition Enabling a VPN for multicast 1705 support SHOULD be possible with no (or very limited impact) on 1706 existing multicast protocols possibly already deployed on the CE 1707 devices 1709 o Extranet: a solution MUST allow to control an extranet multicast 1710 connectivity independently from the extranet unicast connectivity 1712 o Service provider standpoint, added a general statement: "The 1713 deployment of a multicast VPN solution SHOULD be possible with no 1714 (or very limited) impact on possibly existing deployments of 1715 multicast protocols on P and PE routers." 1717 o Removed institutions and company names from the already long 1718 acknowledgments section. 1720 A.5. Changes between -04 and -05 1722 o Follow up of mailing list comments integration 1724 o 2547bis is now 4364 1726 o CE-PE Multicast routing and management protocols: clarified IPv6 1727 related statements 1729 o More precisions in 5.1.7. "Extranet" 1731 o Revamped section 5.1.11 "RP Engineering" : separated text about 1732 different issues "RP Outsourcing", "RP Availability", "RP 1733 Location". Updated 5.1.10 accordingly. 1735 o Updated 5.2.10 about proactive monitoring of tunnels 1737 o Removed requirements summary 1739 o Lots of editorial changes 1741 A.6. Changes between -05 and -06 1743 o editorial changes 1745 o revamp OAM-related sections to integrate comments made on WG 1746 mailing-list 1748 A.7. Changes between -06 and -08 1750 o minor editorial changes 1752 A.8. Changes between -08 and -09 1754 o editorial changes integrating Last Call comments made by Ben 1755 Jenkins and Eric gray 1757 o integrated some comment made by Stephen Farrell for the security 1758 directorate 1760 o updated references to draft which became RFCs, and reordered 1761 references a bit 1763 o other editorial changes 1765 A.9. Changes between -09 and -10 1767 o integration of comments made during IESG review : updated text on 1768 OAM and MTU issues, fixed/added references. 1770 o editorial nits 1772 Author's Address 1774 Thomas Morin (editor) 1775 France Telecom R&D 1776 2, avenue Pierre Marzin 1777 Lannion 22307 1778 France 1780 Email: thomas.morin@rd.francetelecom.com 1782 Full Copyright Statement 1784 Copyright (C) The Internet Society (2006). 1786 This document is subject to the rights, licenses and restrictions 1787 contained in BCP 78, and except as set forth therein, the authors 1788 retain all their rights. 1790 This document and the information contained herein are provided on an 1791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1792 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1793 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1794 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1795 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1798 Intellectual Property 1800 The IETF takes no position regarding the validity or scope of any 1801 Intellectual Property Rights or other rights that might be claimed to 1802 pertain to the implementation or use of the technology described in 1803 this document or the extent to which any license under such rights 1804 might or might not be available; nor does it represent that it has 1805 made any independent effort to identify any such rights. Information 1806 on the procedures with respect to rights in RFC documents can be 1807 found in BCP 78 and BCP 79. 1809 Copies of IPR disclosures made to the IETF Secretariat and any 1810 assurances of licenses to be made available, or the result of an 1811 attempt made to obtain a general license or permission for the use of 1812 such proprietary rights by implementers or users of this 1813 specification can be obtained from the IETF on-line IPR repository at 1814 http://www.ietf.org/ipr. 1816 The IETF invites any interested party to bring to its attention any 1817 copyrights, patents or patent applications, or other proprietary 1818 rights that may cover technology that may be required to implement 1819 this standard. Please address the information to the IETF at 1820 ietf-ipr@ietf.org. 1822 Acknowledgment 1824 Funding for the RFC Editor function is provided by the IETF 1825 Administrative Support Activity (IASA).