idnits 2.17.1 draft-morin-l3vpn-ppvpn-mcast-reqts-00.txt: -(401): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 689. -- Found old boilerplate from RFC 3978, Section 5.5 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 12) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 2004) is 7133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3272' is mentioned on line 428, but not defined ** Obsolete undefined reference: RFC 3272 (Obsoleted by RFC 9522) == Missing Reference: 'IPSEC' is mentioned on line 518, but not defined == Unused Reference: 'RFC3668' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'IPMCAST-MPLS' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'IP-in-IP' is defined on line 635, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-vpn-vr-02 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-07 Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L3VPN Working Group T. Morin 2 Internet Draft R. Moignard 3 Category: Informational JL. Le Roux 4 France Telecom R&D 5 October 2004 7 Requirements for multicast in Provider Provisioned IP VPNs 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 3 of RFC3667 [RFC3667]. By submitting this 15 Internet-Draft, each author represents that any applicable patent or 16 other IPR claims of which he or she is aware have been or will be 17 disclosed, and any of which he or she become aware will be disclosed, 18 in accordance with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document presents a set of functional requirements for network 38 solutions that allow the support of IP multicast within IP provider 39 provided virtual private networks (PP VPNs). It specifies 40 requirements both from the end user and service provider standpoints. 41 It is intended that potential solutions, that specify the support of 42 IP multicast within VPNs, use these requirements as a guideline. It 43 is not the intent of this document to propose technical solutions, 44 nor to detail solution specific issues. 46 Table of Contents 48 1. Introduction................................................2 49 2. Conventions used in this document...........................3 50 2.1. Terminology.................................................3 51 2.2. Conventions.................................................3 52 1. Problem Statement...........................................3 53 1.1. Motivations.................................................3 54 1.2. Requirements Overview.......................................4 55 1.3. Scalability vs. optimality..................................4 56 2. Operational implementation examples.........................4 57 3. Requirements for supporting IP multicast within IP PP VPNs..5 58 3.1. End user/customer standpoint................................5 59 3.1.1. Service definition..........................................5 60 3.1.2. CE-PE routing protocols.....................................5 61 3.1.3. Quality of Service (QoS)....................................5 62 3.1.4. SLA parameters measurement..................................6 63 3.1.5. Data transmission security..................................6 64 3.1.6. Monitoring and Troubleshooting..............................6 65 3.1.7. Extranet....................................................7 66 3.1.8. Multi-homing, load balancing and resiliency.................7 67 3.1.9. Addressing..................................................7 68 3.2. Service provider standpoint.................................7 69 3.2.1. Scalability.................................................7 70 3.2.2. Resource optimization.......................................8 71 3.2.3. Control mechanisms..........................................9 72 3.2.4. Infrastructure security.....................................9 73 3.2.5. Robustness.................................................10 74 3.2.6. Management tools, OAM......................................10 75 3.2.7. Trouble shooting...........................................10 76 3.2.8. Inter-AS, inter provider...................................10 77 3.2.9. Tunneling Requirements.....................................11 78 3.2.10. Architecture consideration.................................11 79 3.2.11. Compatibility..............................................11 80 4. Security Considerations....................................12 81 5. Acknowledgments............................................12 82 6. References.................................................12 83 6.1. Normative references.......................................12 84 6.2. Informative references.....................................12 85 7. Author's Addresses.........................................13 86 8. Intellectual Property Notice...............................14 87 8.1. IPR Disclosure Acknowledgement.............................14 89 1. Introduction 91 L3VPN services satisfying requirement defined in [VPN-REQ], are now 92 being offered by many service providers worldwide. The success of 93 those VPN services is certainly due to intrinsic characteristics of 94 the solutions: 95 - customers are unaware of the deployed network technology and 96 do not need to activate specific mechanisms, 98 - P routers in the core are unaware of the numbers of VPN 99 customers which allows a good scalability, 100 - the dynamic configuration of the VPNs which minimize 101 configuration operation when adding new customers 103 In the meantime, there is a growing need for support of multicast 104 services. Efforts to provide efficient IP multicast routing 105 protocols and multicast group management have been done in 106 standardization bodies which results in particular to the definition 107 of PIM [PIM-SM] [PIM-SSM] and IGMP [IGMPv1] [IGMPv2] [IGMPv3]. 109 However, multicast traffic is not supported natively within the 110 solution defined in [RFC2547bis]. A simple solution to support 111 multicast service in VPN networks consists in establishing unicast 112 tunnels and replicating traffic on PEs. Such kind of techniques have 113 obvious drawbacks such as scalability, operational cost, and 114 bandwidth usage. 116 This document complements the generic L3 VPN requirement draft [VPN- 117 REQ], by specifying additional requirements specific to multicast 118 services. It clarifies the needs from both VPN client and provider 119 standpoints and formulates the problems that should be addressed by 120 technical solutions with as key objective to stay solution agnostic. 121 There is no intent to either specify solution specific details in 122 this document or application specific requirements. 124 It is intended that solutions that specify procedures and protocol 125 extensions for multicast in VPN networks satisfy these requirements. 127 2. Conventions used in this document 129 2.1. Terminology 131 The reader is assumed to be familiar with the terminology in [VPN- 132 REQ], [RFC2547bis], [PIM-SM], [PIM-SSM]. 134 2.2. Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 1. Problem Statement 142 1.1. Motivations 144 More and more L3 VPN customers use IP multicast services within their 145 private infrastructures. Naturally, they want to extend these 146 multicast services to remote sites that are connected via a VPN. 148 For instance, it could be a national TV channel with several 149 geographical locations that wants to multicast a TV program from a 150 central point to several regional locations within its VPN. 152 A solution to support multicast traffic would consist in using 153 unicast PSN tunnels and letting PE routers (provider's routers) 154 replicate traffic. This is obviously sub-optimal as it places the 155 replication burden on the PE and hence has very poor scaling 156 characteristics. It also wastes bandwidth and control plane 157 resources in the provider network. 159 Thus, to provide multicast services for L3 VPN networks in an 160 efficient manner (that is, with scalable impact on signaling and 161 protocol state), in a large scale environment, new mechanisms are 162 required. Existing L3 VPN mechanisms have to be enhanced to support 163 multicast services. 165 1.2. Requirements Overview 167 This document targets provider provided IP VPN solutions designed to 168 carry customer multicast traffic, with as main requirement the fact 169 that a solution SHOULD first satisfy requirements documented in [VPN- 170 REQ] : as much as possible, multicast service should have the same 171 flavor as the unicast one, including same simplicity (technology 172 unaware), the same quality of service (if any), the same management 173 (e.g. monitoring of performances), etc. 175 Moreover, it is also obvious that a multicast VPN solution MUST 176 interoperate seamlessly with current unicast solutions. Even if this 177 is not a core requirement, it would also make sense that multicast 178 VPN solutions define themselves as extensions to existing provider 179 provided IP VPN solutions (such as for instance, [RFC2547bis] or 180 [VR]) and privilege consistency with those. 182 Finally, this document identifies multicast specific issues - most 183 notably from the service provider standpoint - and thus expresses 184 additional requirements specific to multicast. 186 1.3. Scalability vs. optimality 188 An issue has been identified as intrinsic to the transport of 189 multicast VPN traffic over a service provider network, whatever the 190 technical solution chosen: in the general case, there is a tension 191 between resource optimization and number of state maintained. 192 Thus, some trade-off has to be made, and this document will express 193 some requirements related to this trade-off. 195 2. Operational implementation examples 197 This section aims at presenting a few representative examples of 198 multicast applications in a VPN context. The goal is to highlight 199 how different applications and network context may have a different 200 impact on how a trade-off is made. 202 [to be completed] 204 3. Requirements for supporting IP multicast within IP PP VPNs 206 Again, the aim of this draft is not to specify solutions but to give 207 requirements for supporting IP multicast within IP PP VPNs. 209 In order to list these requirements we have taken two different 210 standpoints of two different important entities: the end user (the 211 customer using the VPN) and the service provider. 213 In the rest of the document, we mean by a "solution", a solution that 214 allows to perform multicast into a provider provisioned IP VPN. 216 3.1. End user/customer standpoint 218 3.1.1. Service definition 220 As for unicast, the multicast service should be provider provisioned 221 and shall not need some extra features on the customer equipments 222 (CE). 224 3.1.2. CE-PE routing protocols 226 Between the CEs and the PEs the multicast protocols that SHOULD be 227 implemented in the solution are PIM-SM [PIM-SM] (including PIM-SSM 228 [PIM-SSM], and bidirectional PIM [BIDIR-PIM]), and IGMP (v1, v2 and 229 v3 [IGMPv1] [IGMPv2] [IGMPv3]). 231 3.1.3. Quality of Service (QoS) 233 First, general considerations about QoS in L3VPNs as developed in 234 section 5.5 of [VPN-REQ] are also relevant to this section. 236 The QoS includes various parameters such as delay, jitter, packet 237 loss, and service availability expressed in percentage of time. 238 These parameters are defined in the unicast current provider provided 239 VPN services, are sold by the service provider to the customers and 240 defined in the SLA (Service Level Agreements). 242 The level of availability of multicast traffic should be on par with 243 what exists for unicast traffic. For instance traffic protection 244 mechanisms SHOULD be available for customer multicast traffic when it 245 is carried over the service provider network. 247 The multicast in the VPN solution shall allow to define at least the 248 same level of quality of service. As multicast is often used to 249 deliver high quality services such as video broadcast, the solution 250 should have additional features to support high QoS such as bandwidth 251 reservation and call admission control. 253 Moreover, a multicast VPN solution should as much as possible ensure 254 that client multicast traffic packets are not lost nor duplicated, 255 even if the means used to carry a client multicast data stream over 256 the provider network changes. 258 3.1.4. SLA parameters measurement 260 As SLA parameters are part of the sold service, they are often 261 monitored. The monitoring is used for technical reasons by the 262 service provider and is often sold to the customer for e2e service 263 purposes. 265 The solution shall allow to monitor SLA parameters and may allow to 266 use similar techniques (as those used by the unicast services) to 267 monitor them. 269 Multicast specific characteristics that may be monitored are, for 270 instance, multicast statistics per stream and latency time to receive 271 a multicast group traffic across the VPN. 273 3.1.5. Data transmission security 275 Security is a key point for customer who uses a VPN solution. The 276 RFC2547 model offers some guarantees concerning the security level of 277 data transmission within the VPN. 279 The solution shall provide an architecture that has the same level of 280 security both for the unicast and multicast traffic. 282 A VPN multicast solution may choose to make the 283 optimality/scalability trade-off stated in section 1.3 by 284 distributing multicast traffic of a client group to a set of PE 285 routers that may include PEs which are not part of the VPN. From a 286 security standpoint, this may be a problem for some VPN customers, 287 thus a multicast VPN solution using such a scheme should offer ways 288 to avoid this for specific customers (and/or specific customer 289 multicast streams). 291 3.1.6. Monitoring and Troubleshooting 293 Apart from obvious statistics on multicast traffic, customers of a 294 multicast VPN will need information concerning the status of their 295 multicast resource usage. 297 Indeed, as mentioned in section 3.2.3, for scalability purpose 298 service provider may limit the number (and/or throughput) of 299 multicast streams that are received and produced at a client site, 300 and obviously customers will need to be able to know their current 301 resource usage (state and throughput) and will need to receive some 302 kind of alert if rejects are happening. 304 3.1.7. Extranet 306 In current PP L3VPN models, a customer site may be setup to be part 307 of multiple VPNs. The need for a corresponding multicast feature 308 will need to be assessed in further revisions of this draft, but a 309 multicast solution should at least specify how it handles multicast 310 traffic of a such site. 312 3.1.8. Multi-homing, load balancing and resiliency 314 A multicast VPN solution should be compatible with current solutions 315 aimed at improving the service robustness for customers such as 316 multi-homing, CE-PE link load balancing and failover. A multicast 317 VPN solution should also be able to offer those same features for 318 multicast traffic. 320 3.1.9. Addressing 322 A multicast provider provided L3VPN should not impose restrictions on 323 multicast group addresses used by VPN customers. 325 In particular, as for unicast traffic, overlap of multicast group 326 address sets used by different customers MUST be supported. 328 3.2. Service provider standpoint 330 3.2.1. Scalability 332 Some currently standardized and deployed L3VPN solution have the 333 major advantage of being scalable in the core regarding the number of 334 customers and number of customer routes. For instance, in the 335 [RFC2547bis] model, a P router sees a number of MPLS tunnels that is 336 only linked to the number of PEs and not at all to the number of 337 customers. 339 As far as possible, this independence in the core, with respect to 340 the number of customers and to customer activity, is recommended. 341 Yet, it is identified that in our context the scalability and 342 resource usage optimality goals are competing, so this requirement 343 may be reduced to having the possibility of bounding the quantity of 344 states that the service provider needs to maintain in the core, the 345 bound being independent of the multicast activity of VPN customers. 347 It is expected that multicast VPN solutions will use some kind of 348 point to multipoint technology to efficiently carry VPN multicast 349 traffic, and that such technologies require maintaining state 350 information, and will use resources in the control plane (memory and 351 processing, and possibly address space). 353 Scalability is a key requirement for multicast VPN solutions. 354 Solutions MUST be designed to scale well with an increase in the 355 number of any of the following: 356 - the number of PEs 357 - the number of customers VPNs (total and per PE) 358 - the number of PEs and sites in any VPN 359 - the number of client multicast channels 360 (groups or source-groups) 362 Both scalability of performance and operation MUST be considered. 364 Key considerations SHOULD include: 365 - the processing resources needed on the control plan 366 (neighborhood or session maintenance messages, 367 keep-alives, timers, etc.) 368 - the memory resources needed for the control plane 369 - the amount of protocol information transmitted to manage 370 a multicast VPN (message size) 371 - the amount of potential routing extensions 372 - the amount of control plane processing required on PE and P to 373 add remove a customer site ( or a customer from a multicast 374 session) 375 - the number of multicast IP addresses used (if IP multicast 376 distribution trees are used to carry customer multicast 377 traffic) 379 It is expected that the applicability of each solution will be 380 evaluated with regards to the aforementioned scalability criteria. 382 These considerations naturally lead us to believe that proposed 383 solutions SHOULD offer the possibility of sharing such resources 384 between different VPN multicast streams (between different VPNs, 385 between different VPN multicast streams of the same or of different 386 VPNs). This means, for instance, being able to share IP multicast 387 trees between several customers. 389 Those scalability issues are expected to be more pregnant on P 390 routers, but a multicast in VPNs solution should address both P and 391 PE routers as far as scalability is concerned. 393 3.2.2. Resource optimization 395 3.2.2.1. General goals 397 One of the aims of the use of multicast instead of unicast is 398 resource optimization in the network. 400 The two obvious things that a multicast VPN solution would want to 401 avoid are useless duplication � when same data travels twice or more 402 on a same link (e.g. when doing ingress PE replication) - and data 403 sent uselessly (e.g. PE receiving traffic they don't need). 405 3.2.2.2. Trade-off and tuning 407 But as previously stated in this document, a scalable resource 408 optimal solution is probably not possible. Thus what is expected 409 from a multicast VPN solution is that it addresses the resource 410 optimization issue taking into account the fact that some trade-off 411 has to be made. 413 Moreover, we think that a "one size fits all" trade-off probably does 414 not exist either, and that the most sensible approach would be a 415 versatile solution offering the providers appropriate configurable 416 settings letting them tune the trade-off according to their peculiar 417 constraints (network topology, platforms, customer applications, 418 level of service offered etc.). 420 3.2.2.3. Traffic engineering 422 In addition, if traffic engineering features are provided by the 423 connection mode that is used between PEs for unicast traffic in the 424 VPN service, the solution SHOULD provide the same for multicast 425 traffic. 427 The solution should offer mean to support key multicast TE objectives 428 as defined in [RFC 3272]. 430 3.2.3. Control mechanisms 432 The solution must provide some mechanisms to control the source 433 emission within a VPN. This control includes the number of sources 434 and/or the total bit rate of all the sources. 436 At the reception level, the solution must also provide mechanisms to 437 control the number of channels (group or source/group) to which a VPN 438 site has subscribed and/or the total bit rate. 440 All these mechanisms must be configurable by the service provider in 441 order to control the amount of multicast traffic within a VPN. 443 Moreover it may be desirable to be able to impose some global bound 444 on the quantity of state used by a VPN in the core network for its 445 multicast traffic. 447 3.2.4. Infrastructure security 449 Concerning the infrastructure, the solution shall provide the same 450 level of security for the service provider. For instance, that means 451 that the intrinsic protection against DOS and DDOS attacks of the 452 BGP/MPLS solution must be the same in the multicast solution. 454 Moreover, since multicast traffic and routing are intrinsically 455 dynamic, some mechanism must be proposed so that the frequency of 456 changes in the way client traffic is carried over the core is bounded 457 and not tightly coupled to dynamic changes of multicast traffic in 458 the customer network. 460 Last, control mechanisms described in previous section are also to be 461 considered from this infrastructure security point of view. 463 3.2.5. Robustness 465 Resiliency is also crucial to infrastructure security, thus a 466 multicast VPN solution shall whether avoid single points of failures 467 or propose some technical solution making possible to implement a 468 failover mechanism. 470 3.2.6. Management tools, OAM 472 The operation of a multicast VPN solution shall be as light as 473 possible and automatic configuration and discovery should be 474 privileged. Particularly the operational cost of setting up 475 multicast on a PE should be as low as possible. 477 Moreover, monitoring of multicast specific parameters and statistics 478 should be offered to the service provider. 480 Most notably the provider should have access to : 481 - multicast traffic statistics 482 - information about client multicast resource usage (state and 483 throughput) 484 - alarms when limits are reached on such resources 485 - statistics on decisions related to how client traffic is carried 486 on transport trees (e.g. traffic switched onto a stream specific 487 multicast tree) 488 - statistics on parameters that could help the provider to 489 evaluate its optimality/state trade-off 491 3.2.7. Trouble shooting 493 A multicast VPN solution that would dynamically adapt the way some 494 client multicast traffic is carried over the provider network may 495 incur the disadvantage of being hard to troubleshoot. 497 In such a case, to help diagnose multicast network issues a multicast 498 VPN solution should provide monitoring information describing how 499 client traffic is carried over the network (e.g. which provider 500 multicast group is used for such and such client multicast stream). 501 Moreover a solution may also provide configuration options to avoid 502 any dynamic changes, for multicast traffic of a particular VPN or a 503 specific multicast stream (client group or source-group). 505 3.2.8. Inter-AS, inter provider 506 A multicast VPN solution shall support inter area, inter-AS and inter 507 provider multicast VPNs. Options A, B and C (as described in section 508 10 of [RFC2547bis]) SHOULD be supported. 510 Moreover such support should be possible without compromising other 511 requirements of this draft, and should not incur penalty on 512 scalability and bandwidth resource usage. 514 3.2.9. Tunneling Requirements 516 Connectivity between PE devices in the backbone SHOULD be able to use 517 a range of tunneling technologies, including point-to-point and 518 point-to-multipoint, such as L2TP [L2TP-MCAST], IPSEC [IPSEC], GRE 519 [GRE], IP-in-IP, MPLS [P2MP], etc. 521 In a multicast VPN solution extending a unicast IP PP VPN solution, 522 consistency in the tunneling technology has to be privileged : such a 523 solution SHOULD allow the use of the same tunneling technology for 524 multicast as for unicast. 526 3.2.10. Architecture consideration 528 As far as possible, the solution shall minimize the number of 529 protocols that have to be activated within the core network, i.e. in 530 the P and PE routers. 532 It is desirable to maximize the re-use of existing L3 VPN techniques 533 and protocols. For instance, the same routing protocol (or an 534 extension) shall be used both for unicast and multicast solution. 536 Moreover, introducing new protocol specific to this issue should be 537 avoided when possible (on both PE and P routers), and extensions to 538 existing protocols should be preferred when relevant. 540 The motivations behind those requirements are good interworking and 541 troubleshooting. 543 3.2.11. Compatibility 545 First, it is a requirement that unicast and multicast services MUST 546 be able to co-exist within the same VPN. 548 A multicast VPN solution SHOULD prevent compatibility and migration 549 issues, for instance by privileging mechanisms facilitating forward 550 compatibility. Most notably a solution supporting only a subset of 551 those requirements SHOULD be designed to be compatible with future 552 enhanced revisions. 554 It SHOULD be an aim of any multicast into VPN solution to offer as 555 much backward compatibility as possible. An ideal which is probably 556 impossible to achieve would be to offer multicast VPN services across 557 legacy routers without any change to any router in the network. 559 4. Security Considerations 561 This document does not by itself raise particular security issues. 563 5. Acknowledgments 565 The authors would like to thank Vincent Parfait (Equant), Elodie 566 Hemon Larreur and Sebastien Loye (France Telecom) and for their 567 review and suggestion of an earlier draft of this document. 569 The authors would also like to thank Zubair Ahmad (Equant) for his 570 valuable input. 572 6. References 574 6.1. Normative references 576 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, RFC 577 3667, February 2004. 579 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 580 Technology", BCP 79, RFC 3668, February 2004. 582 [RFC2026] S. Bradner, "The Internet Standards Process - Revision 583 3", BCP 9, RFC 2026, October 1996. 585 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997 588 [VPN-REQ] M. Carugi, et. al., "Service requirements for Layer 3 589 PPVPNs", draft-ietf-l3vpn-requirements-02 (work in progress) 591 [PIM-SM] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 592 Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, 593 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 594 Specification.", RFC 2362, June 1998. 596 [IGMPv1] S. Deering, "Host extensions for IP multicasting", RFC 597 1112 599 [IGMPv2] W. Fenner, "Internet Group Management Protocol, IGMP 600 version 2", RFC 2236, November 1997. 602 [IGMPv3] B. Cain, "Internet Group Management Protocol, Version 603 3", RFC 3376 605 6.2. Informative references 607 [RFC2547bis] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-ietf-l3vpn- 608 rfc2547bis-03 (work in progress), October 2004 610 [VR] P. Knight et al., "Network based IP VPN Architecture 611 using Virtual Routers", April 2004, draft-ietf-l3vpn-vpn-vr-02 (work 612 in progress) 614 [PIM-SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for 615 IP" September 2004, draft-ietf-ssm-arch-06 (work in progress) 617 [BIDIR-PIM] Mark Handley, Isidor Kouvelas, Tony Speakman, Lorenzo 618 Vicisano "Bi-directional Protocol Independent Multicast", July 2004, 619 draft-ietf-pim-bidir-07 (work in progress) 621 [IPMCAST-MPLS] D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul 622 and F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label 623 Switching (MPLS) Environment", RFC3353, August 2002. 625 [P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extended 626 RSVP-TE for Point-to-Multipoint LSP Tunnels", July 2004, draft- 627 yasukawa-mpls-rsvp-p2mp-04 (work in progress) 629 [L2TP-MCAST] G. Bourdon, "Extensions to support efficient carrying 630 of multicast traffic in Layer-2 Tunneling Protocol (L2TP)", draft- 631 ietf-l2tpext-mcast-05 (work in progress) 633 [GRE] 635 [IP-in-IP] 637 7. Author's Addresses 639 Thomas Morin 640 France Telecom R & D 641 2, avenue Pierre-Marzin 642 22307 Lannion Cedex 643 France 644 Email: thomas.morin@francetelecom.com 646 Renaud Moignard 647 France Telecom R & D 648 2, avenue Pierre-Marzin 649 22307 Lannion Cedex 650 France 651 Email: renaud.moignard@francetelecom.com 653 Jean-Louis Le Roux 654 France Telecom R & D 655 2, avenue Pierre-Marzin 656 22307 Lannion Cedex 657 France 658 Email: jeanlouis.leroux@francetelecom.com 660 8. Intellectual Property Notice 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed 664 to pertain to the implementation or use of the technology 665 described in this document or the extent to which any license 666 under such rights might or might not be available; nor does it 667 represent that it has made any independent effort to identify any 668 such rights. Information on the procedures with respect to rights 669 in RFC documents can be found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use 674 of such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository 676 at http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention 679 any copyrights, patents or patent applications, or other 680 proprietary rights that may cover technology that may be required 681 to implement this standard. Please address the information to the 682 IETF at ietf-ipr@ietf.org. 684 8.1. IPR Disclosure Acknowledgement 686 By submitting this Internet-Draft, I certify that any applicable 687 patent or other IPR claims of which I am aware have been disclosed, 688 and any of which I become aware will be disclosed, in accordance with 689 RFC 3668. 691 Full Copyright Statement 693 "Copyright (C) The Internet Society (2004). This document is subject 694 to the rights, licenses and restrictions contained in BCP 78, and 695 except as set forth therein, the authors retain all their rights. 697 This document and translations of it may be copied and furnished to 698 others, and derivative works that comment on or otherwise explain it 699 or assist its implementation may be prepared, copied, published and 700 distributed, in whole or in part, without restriction of any kind, 701 provided that the above copyright notice and this paragraph are 702 included on all such copies and derivative works. However, this 703 document itself may not be modified in any way, such as by removing 704 the copyright notice or references to the Internet Society or other 705 Internet organizations, except as needed for the purpose of 706 developing Internet standards in which case the procedures for 707 copyrights defined in the Internet Standards process must be 708 followed, or as required to translate it into languages other than 709 English. 711 The limited permissions granted above are perpetual and will not be 712 revoked by the Internet Society or its successors or assigns. 714 This document and the information contained herein are provided on an 715 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 716 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 717 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 718 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 719 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 720 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.