idnits 2.17.1 draft-yasukawa-l3vpn-p2mp-mcast-00.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 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 738. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 831), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 17) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 (October 2004) is 7126 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 704, but not defined == Unused Reference: 'RFC3667' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'P2MP-REQ' is defined on line 778, 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) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-03) exists of draft-nalawade-idr-mdt-safi-00 Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa 2 IETF Internet Draft NTT 3 Expires: April 2005 4 Shankar Karuna 5 Sarveshwar Bandi 6 Motorola 8 Adrian Farrel 9 Old Dog Consulting 11 October 2004 13 BGP/MPLS IP Multicast VPNs 15 draft-yasukawa-l3vpn-p2mp-mcast-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 This document describes a solution framework for IP Multicast 48 VPNs. It describes procedures for establishing optimal virtual 49 private IP multicast networks over a provider network. The simple 50 multicast tunnel operation mechanism within a core network provides 51 easy and flexible IP multicast VPN service operation for the 52 service provider. And because the solution can minimize PIM 53 neighbor maintenance over remote PEs, the solution enhances the 54 scalability performance of the multicast VPN service network. This 55 document also describes a P2MP TE LSP based multicast tunnel 56 mechanism which could enhance TE capability and reliability of IP 57 multicast VPNs. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Contents 67 1. Introduction .................................................. 04 68 2. Motivations ................................................... 04 69 2.1. Basic Motivations for IP multicast VPN operation ......... 04 70 2.2. Motivations for IP multicast VPN protocol design ......... 05 71 3. IP Multicast VPN Framework .................................... 06 72 3.1. Basic network model ...................................... 06 73 3.2. Proxy-Source/RP model .................................... 08 74 3.3. Proxy-Source/RP function ................................. 09 75 3.4. Auto-Discovery of VPN membership ......................... 09 76 3.5. Default MDT configuration ................................ 10 77 3.6 Exchanging IP multicast register information .............. 10 78 3.6.1. Source Activate (SA) SAFI .............................. 11 79 3.6.2. JOIN SAFI .............................................. 12 80 3.7 Default MDT operation ..................................... 13 81 3.8. Data MDT operation ....................................... 14 82 3.9. Inter-Site Scaling and Site Interdependencies ............ 16 83 3.10. Multi-Homing scenario ................................... 17 84 3.11. Multi-Area/As operation ................................. 17 85 4. IANA Considerations ........................................... 17 86 5. Security Considerations ....................................... 17 87 6. Acknowledgements .............................................. 17 88 7. Intellectual Property Considerations .......................... 17 89 8. Normative References .......................................... 18 90 9. Informational References ...................................... 18 91 10. Authors' Addresses ........................................... 19 92 11. Full Copyright Statement ..................................... 20 94 1. Introduction 96 This document describes a solution framework for IP Multicast 97 VPNs. It describes basic procedures for establishing optimal virtual 98 private IP multicast networks over a provider network by dividing a 99 customer's multicast network into multiple regions and setting 100 independent multicast distribution trees within each customer site 101 and interconnecting these independent trees by provider P2MP MPLS 102 tunnels. In this solution, each PE connected to a customer's site 103 acts as a proxy-source or a proxy-rendezvous point (RP) for the 104 multicast group and a default multicast tunnel is established from a 105 PE which accommodates a multicast source to multiple PEs which act as 106 proxy-source/RP for their receivers in the connected site. 108 As a result, the solution can construct IP multicast distribution 109 trees that have optimal topologies for IP multicast distribution and 110 avoid using multiple multicast and unicast distribution tunnels in 111 the service provider core during the customer's tree transition 112 phase. This simple multicast tunnel operation mechanism within a core 113 provides easy and flexible IP multicast VPN service operation for the 114 service provider. And, because the solution can terminate each 115 customer's Join/Prune message at PEs, the solution can minimize PIM 116 neighbor maintenance over remote PEs. This enhances the scalability 117 performance of multicast VPN service network. This document also 118 describes a P2MP TE LSP based multicast tunnel mechanism which could 119 enhance TE capability and reliability of IP multicast VPNs. 121 2. Motivations 123 2.1. Basic Motivations for IP multicast VPN operation 125 There are growing demands for providing IP multicast services on top 126 of a BGP/MPLS IP VPN [RFC2547bis] environment. Candidates for these 127 services are, for example, in-house video distribution/conference and 128 data synchronization/distribution between business system servers 129 which usually require strict QoS control and highly reliable network 130 conditions. Therefore it is highly desirable that a solution has the 131 capability to implement some QoS guarantee and protection mechanisms 132 in itself, or has capabilities to operate with conventional QoS 133 guarantee and protection mechanisms. 135 Because IP multicast VPNs require full meshed multicast distribution 136 between multiple customer sites, and this operation usually requires 137 complicated multicast tree management within a provider core network, 138 it is also highly desirable that a solution provides the service 139 provider with several easy mechanisms to control and manage these IP 140 multicast distributions within the network. 142 2.2. Motivations for IP multicast VPN protocol design 144 The basic function of an IP multicast VPN is to enable a multicast 145 source which exists in a customer site to send IP multicast traffic 146 privately over the provider core network to multicast receivers that 147 exist in different customer sites. 149 To enable this private IP multicast transmission, several solutions 150 have been proposed. Within the proposals, the most significant 151 solution is [MCAST-VPN] which introduces the Multicast Domain (MD) 152 mechanism to interconnect each customer's IP multicast networks over 153 the provider network to enable IP multicast distribution between the 154 sites. An MD is essentially a set of MVRFs associated with interfaces 155 that can send multicast traffic to each other and is equivalent to 156 a multi-access interface from the standpoint of a PIM customer 157 instance. Therefore, in this MD model, a provider wide customer IP 158 multicast network is formed over an MD which transparently exchanges 159 customer's IP multicast control messages between PEs which form IP 160 multicast adjacencies between them. This means that when the customer 161 network runs the PIM protocol, PIM adjacencies are formed between 162 MVRFs at the PEs and periodic PIM Join/Prune messages and Hello 163 messages are transmitted between them. 165 This features introduces some scalability concerns for the service 166 provider when they operate IP multicast VPNs because today's 167 conventional L3VPNs accommodate a lot of large scale VPNs and it is 168 easily assumed that a majority of these VPNs will introduce IP 169 multicast VPN services in the near future. This would require a huge 170 amount of PIM adjacencies to be maintained over the provider core 171 network and this would reduce the VPN's network performance and 172 increase the difficulties of managing the network. 174 A further MVPN proposal [MVPN-RAGGARWA] addresses three scalability 175 concerns for this conventional [MCAST-VPN] solution as fundamental 176 issues to be resolved. The first addressed concern is the overhead of 177 PIM neighbor adjacencies. The second concern is the overhead of 178 periodic PIM Join/Prune messages, and the last concern is the amount 179 of state in the SP core. It is highly desirable for any solution to 180 address these concerns. 182 Another concern which is not yet addressed is suboptimal IP multicast 183 distribution which could easily occur in an IP multicast VPN 184 environment. Most customers want to operate their own private IP 185 multicast networks over multiple customer sites which are usually 186 widely separated from each other over the provider network, and it is 187 easily assumed that the customer runs PIM [PIM-SM] with only a very 188 limited number of RPs in sites which may be located remotely from the 189 site which a multicast source belongs to. In this case, during shared 190 tree distribution, multicast packets must first be sent to the RP's 191 site and then must to be sent back to receivers' sites even in the 192 case where some receivers belong to the same site as the source. This 193 kind of multiple transmission over the provider network is suboptimal 194 and wastes network resource. Moreover some receivers would suffer 195 severe transmission delays and some multicast application would not 196 tolerate this. 198 In addition to these undesirable conditions, a customer's IP 199 multicast distribution pattern changes drastically when the 200 distribution tree is transferred from a shared tree to a source 201 specific tree. This would also cause drastic changes in the multicast 202 distribution pattern in the provider core and would introduce 203 unstable conditions for the operation of the core network and 204 consequently for the VPNs. There is no mechanism for a service 205 provider to limit this kind of undesirable condition and to control 206 the multicast distribution pattern. Therefore it is highly desirable 207 for a solution to address these concerns. It is desirable for a 208 solution to provide the service provider with mechanisms which can 209 avoid this kind of suboptimal IP multicast distribution within their 210 core networks and which can allow control of multicast distribution 211 within their core networks by eliminating the necessity of using and 212 changing multiple multicast tunnels and by providing a minimum number 213 of stable multicast tunnels which are easily managed by the service 214 provider. 216 Because some IP multicast VPN applications require bandwidth 217 guarantees, delay-constrained multicast distribution paths, and 218 highly reliable paths, it is desirable for a solution to have 219 capabilities to setup a bandwidth guaranteed multicast distribution 220 path, to explicitly control routes of the distribution path, and to 221 accommodate global and fast local repair mechanisms. 223 3. IP Multicast VPN Framework 225 3.1. Basic network model 227 This document utilizes the same network model as BGP/IP MPLS VPNs 228 [RFC2547bis] for realizing IP multicast VPNs. A provider configures 229 whether a particular VPN is multicast-enabled or not. All the PEs 230 that contain customer sites belonging to the same VPN with multicast 231 enabled on them will be connected using a "Multicast Distribution 232 Tree (MDT)" in the provider's backbone. 234 As deployed in BGP/IP MPLS VPNs [RFC2547bis] and [MCAST-VPN], each CE 235 router is a multicast routing adjacency of a PE router, but CE 236 routers at different sites do NOT become multicast routing 237 adjacencies of each other. 239 Unlike the [MCAST-VPN] model, this document proposes the use of BGP 240 for both discovering IP multicast VPN membership and exchanging IP 241 multicast routing information in a given IP multicast VPN. 243 As for the membership discovery, all the PE routers advertise their 244 IP multicast VPN membership to other PE routers using BGP so that 245 each PE router in the network has a complete view of the IP multicast 246 VPN membership of the other PE routers. 248 After this information exchange, the Default MDT for a Multicast 249 Domain is constructed automatically. Note that this Default MDT 250 construction occurs when the PEs in the domain come up and advertise 251 their membership of a multicast enabled VPN, and the construction 252 does not depend on the existence of multicast traffic in the domain. 254 One further difference is that the MDTs are usually created by P2MP 255 TE LSPs by running a P2MP TE signaling protocol in the 256 backbone. Therefore, it may not be necessary to run IP multicast 257 routing protocols in the core to support IP multicast VPNs (dependent 258 on how the P2MP TE trees are managed). 260 As for multicast routing information exchange, this document proposes 261 BGP to carry the information. Therefore, being different from the 262 [MCAST-VPN] model, the customer's IP multicast instances of a 263 particular VPN running on the PE do not form routing adjacencies 264 with each other. This means that the customer's IP multicast control 265 packets are always terminated at PEs and independent multicast 266 domains are formed within each customer site which is a member of the 267 IP multicast VPN. In this model, the customer's IP multicast control 268 messages, such as PIM Join/Prune messages, are converted to BGP 269 messages and these messages are exchanged between PEs so that IP 270 multicast routing can be enabled between each independent IP 271 multicast domains. 273 This preserves two important features of BGP/IP MPLS VPNs 274 [RFC2547bis]; "Separation of controlling and forwarding plane in the 275 provider core" and "Distribution of customer's routing information 276 via provider's routing facility". These are very important 277 preservations for the SP to preserve its network management model 278 while allowing it to control/engineer the customer's data traffic and 279 control traffic over the network. 281 Multicast data packets from within a VPN are received from a CE 282 router by an ingress PE router, the ingress PE then encapsulates the 283 mutlicast packets and forwards them along the Default MDT to all the 284 PE routers connected to sites of the given VPN. Every PE router 285 attached to a site of the given VPN thus receives all multicast 286 packets from within that VPN. If a particular PE router is not on the 287 path to any receiver of that multicast group, the PE simply discards 288 that packet. 290 In the same way as [MCAST-VPN], this document proposes to set up Data 291 MDTs to accommodate a large amount of traffic being sent to a 292 particular multicast group but where that group does not have 293 receivers at all the VPN sites. 295 3.2. Proxy-Source/RP model 297 Section 2.2 of [RFC3446] describes the need to run multiple RPs in 298 the scenarios where the topological location of RP, Source and 299 receivers are unpredictable. This document proposes a solution along 300 similar lines. 302 This document proposes that all PEs which are members of a given VPN 303 act as proxy Source/RPs for a given IP multicast group. 304 Approving all the PEs to be a proxy Source/RP for the group, each 305 customer site can form an independent IP multicast tree within the 306 site regardless of multicast tree formations in other sites. 308 To accomplish this model, a PE that is either directly connected to 309 the multicast source in the VPN or connected via a CE MUST act as a 310 proxy-RP for the receivers in the same site when the customer network 311 runs PIM-SM protocol in the VPN. 313 If a customer wants to run the RP within his network, in such a case 314 the customer can configure one RP on each of his sites and can use an 315 anycast-RP and MSDP based mechanism [RFC3446]. This solution can be 316 extended to support such an approach and is presently out of scope of 317 this document. 319 A PE that is either directly connected to an RP in the VPN or 320 connected via a CE MUST act as a Source/RP for the receivers in the 321 same site, and a PE that is either directly connected to multicast 322 receivers for that multicast group or connected via a CE MUST act as 323 a Source/RP for the receivers in the same site. 325 A P2MP TE LSP or a MP2MP TE LSP which is described in a later section 326 is established from an ingress PE to multiple egress PEs to form a 327 default MDT. The setup of default MDT is triggered after the VPN 328 membership auto-discovery phase. 330 Therefore, each egress PE which acts as a proxy-Source/RP can always 331 receive IP multicast data traffic via this LSP tunnel. 333 A P2MP TE LSP is established from an ingress PE to egress PEs which 334 are interested in receiving the multicast data dynamically to form a 335 data MDT. The ingress PE sets up and modifies a data MDT dynamically 336 by receiving BGP messages which convey egress PEs interests for 337 joining/leaving the VPN membership. Therefore, each egress PE which 338 acts as a proxy-Source/RP can receive IP multicast data traffic via 339 this LSP tunnel on demand. 341 3.3. Proxy-Source/RP function 343 To make each PE interconnected to a customer site act as a proxy-RP, 344 this document assumes that some RP discovery mechanisms, such as 345 static configuration or Bootstrap Router, indicates all of the PIM 346 router existing in the connected customer site to perform the same 347 group-to-RP (PE) mapping. This ensures that all the PIM router in the 348 customers site utilize the PE as RP. 350 The PE which act as RP and interconnected to IP multicast source must 351 handle PIM register message operations, including decapsulation and 352 sending source specific join message and PIM register stop message 353 and must convert PIM register message to IP multicast source active 354 information. 356 The PE which acts as RP and is interconnected to multicast receivers 357 must terminate PIM Join/Prune messages and convert this information 358 to IP multicast registration information. 360 3.4. Auto-Discovery of VPN membership 362 This document assumes MDT SAFI [MDT-SAFI] to discover VPN 363 membership. In this model, a MDT group-address is defined per 364 Multicast Domain and all the PEs that are configured with MVRFs 365 belonging to same IP multicast VPN discover each other thorough this 366 SAFI. 368 3.5. Default MDT configuration 370 After VPN membership discovery, each PE which is a member of an IP 371 multicast VPN will trigger the formation of a P2MP tree towards every 372 other PE that has Multicast VRFs for the same Multicast Domain. The 373 P2MP TE LSPs [P2MP-RSVP] are established by assigning a MDT 374 group-address to the P2MP ID of the SESSION object, and assigning the 375 initiator PE's address to the Tunnel Sender Address of the 376 SENDER_TEMPLATE object. The destination PEs are designated as leaves 377 of the P2MP tree and are encoded as recipients in P2P Sub-LSP 378 Objects. 380 In order for each PE to forward received IP multicat data packets to 381 the appropriate MVRF, each PE which is a member of the IP multicast 382 VPN MUST associate the P2MP TE LSPs with a proper MVRF by assigned 383 P2MP Labels. These associations are configured when a PE assigns P2MP 384 Labels to the P2MP TE LSPs. Therefore, in this model, PHP operation 385 MUST be strictly prohibited. 387 A MP2MP TE LSP can be also utilized for establishing a Default 388 MDT. With the help of Route Reflector functionality in MP-BGP the 389 PE's interested in this Multicast Domain are learnt at the node that 390 runs as the Route reflector and these PE's are configured as leaves 391 for P2MP TE LSP with the route reflector node as root. 393 After an RP has set up a P2MP TE LSP to the leaves, the leaves setup 394 a P2P TE LSPs to the RP. In this way, a MP2MP TE LSP is established 395 between PEs which are members of the Multicast Domain. This MP2MP 396 based Default MDT configuration mechanism is useful but it is out of 397 scope of this document. The detailed mechanism and procedure will be 398 defined in the another [MP2MP-TE-MPLS] document. 400 3.6 Exchanging IP multicast register information 402 This documents proposes exchanging two kinds of IP multicast register 403 information between PEs via BGP. 405 A new Subsequent-Address Family called Source Activate (SA) SAFI is 406 newly defined to announce the activation of a particular customer's 407 IP multicast data stream. This SAFI is used by a PE which is either 408 directly connected to an IP multicast source or connected via a CE to 409 inform other PEs located in different sites that a particular 410 customer's (S,G) IP multicast data stream has become active and this 411 active IP multicast data can be accessed via this announcing 412 PE. Therefore, a PE which is either directly connected to an IP 413 multicast source or connected via a CE and acts as proxy RP and sends 414 this information via BGP after it confirms establishment of a source 415 specific IP multicast tree between the Designated Router and itself 416 by sending a Register-Stop message and receiving a Null-Register 417 Message. 419 Another Subsequent-Address Family called JOIN SAFI is also newly 420 defined to announce the interest of a particular PE to join and prune 421 a particular customer's IP multicast data stream. This SAFI is used 422 by PEs which are either directly connected to IP multicast receivers 423 or connected via CEs to inform a PE which is either directly 424 connected to an IP multicast source or connected via a CE that they 425 are interested in receiving a particular customer's (S,G) IP 426 multicast data stream by announcing JOIN SAFI information. Therefore 427 PEs which are either directly connected to IP multicast receivers or 428 connected via CEs and which act as proxy-Source/RPs send this 429 information via BGP after they have received SA information and have 430 confirmed that IP multicast receivers in their site are also 431 interested in receiving/leaving this IP multicast data stream by 432 receiving customer Join/Prune message. 434 3.6.1. Source Activate (SA) SAFI 436 This SAFI is used to announce to all the other PEs about a particular 437 customer (S,G) data stream becoming active. 439 SA SAFI: 441 +------------------------------+ 442 | | 443 | RD (8 octets) | 444 +------------------------------+ 445 | PE's IPv4 address | 446 | (4 octets) | 447 +------------------------------+ 448 | Provider's Group-address | 449 | (4 octets) | 450 +------------------------------+ 451 | Customer's Source-address | 452 | (4 octets) | 453 +------------------------------+ 454 | Customer's Group-address | 455 | (4 octets) | 456 +------------------------------+ 458 PE's IPv4 address: IP address of the PE that has detected a multicast 459 source in the customer network. 461 Provider's Group-address: The PE assigns a multicast group address 462 from an address range that is independent of the customer multicast 463 group addresses. This multicast group address is used by the PE's 464 that have interested receivers to be able to associate a Data MDT 465 associated with data stream corresponding to Customer's 466 Source-address and Customer's Group-address 468 Customer's Source-address: Address of customer's multicast source. 469 Customer's Group-address : Address of customer's multicast group 470 address. 472 3.6.2. JOIN SAFI 474 This SAFI will be used by a PE when it desires to receive data for 475 a particular customer (S,G) data stream. 477 JOIN SAFI: 479 +------------------------------+ 480 | | 481 | RD (8 octets) | 482 +------------------------------+ 483 | PE's IPv4 address | 484 | (4 octets) | 485 +------------------------------+ 486 | Customer's Source-address | 487 | (4 octets) | 488 +------------------------------+ 489 | Customer's Group-address | 490 | (4 octets) | 491 +------------------------------+ 493 PE's IPv4 address: IP address of the PE that has interested 494 receivers. 496 Customer's Source-address: Address of customer's multicast source. 497 Customer's Group-address : Address of customer's multicast group 498 address. 500 3.7 Default MDT operation 502 This section describes how the proposed solution enables IP multicast 503 VPN operation using a Default MDT assuming a VPN customer runs the 504 PIM-SM protocol within their network. 506 To establish a Default MDT, MVRFs are first configured on every PE 507 which is a member of a given IP multicast VPN. A unique group address 508 and RD are assigned to that Multicast Domain. After this 509 configuration, each that PE belongs to that Multicast Domain 510 announces its VPN membership to other PEs by BGP using MDT-SAFI. 512 After this auto-discovery of VPN membership, each PE initiates the 513 formation of a P2MP TE LSP by assigning the group address to that 514 LSP. A P2MP TE LSP is established from the initiator PE to other PEs 515 which are also members of this Multicast Domain. During the P2MP TE 516 LSP establishment each PE that is also egress of the LSP and a member 517 of that Multicast Domain configures an association between P2MP TE 518 LSPs which constitute Default MDT and MVRF for that Multicast Domain 519 by relating assigned MPLS labels to the MVRF. The egress PE uses the 520 group address announced by the PE, which is the root for this P2MP TE 521 LSP, in the MDT-SAFI message [MDT-SAFI]. 523 Note that as described in the previous section, a MP2MP TE LSP could 524 be utilized to establish the Default MDT. But MP2MP TE MPLS is out of 525 scope of this document and its detailed mechanism and procedure will 526 be addressed in another document. 528 Because in this mechanism, each PE that is member of the Multicast 529 Domain must act as a proxy-RP for that multicast groups. Therefore, 530 all PIM router within a customer's site must be configured by some 531 mechanism to treat a connected PE as its RP and to perform same 532 group-to-proxy-RP mapping. Examples of these mechanism are static 533 configuration and Bootstrap Router mechanism [PIM-BSR] described in 534 the previous section. 536 Consider the situation where an IP multicast source starts IP 537 multicast distribution. The Designated Router (DR) encapsulates IP 538 multicast data packets and sends these packets as PIM register 539 messages to a PE which now act as proxy-RP for that customer's 540 site. Receiving PIM register messages, the PE sends a source specific 541 Join message to the DR to form a source specific multicast tree 542 between the PE and the DR. The PE simultaneously starts announcing to 543 other PEs the activation of a multicast group via BGP using the SA 544 SAFI. The PE sends a Register stop message to the DR after it starts 545 receiving multicast Data on the source specific tree. 547 When receivers in another customer site want to Join a given 548 multicast distribution, then the receivers send Join (*,G) messages 549 to their RP to form a shared multicast distribution tree. Note that a 550 PE which is either directly connected to the receivers or connected 551 via a CE now acts as proxy-RP for the receivers. Therefore a shared 552 multicast distribution tree is formed from proxy-RP (PE) to multiple 553 receivers in a customer's site. And because this PE knows that 554 corresponding multicast data is already activated, the PE sends its 555 IP multicast registry information via BGP using JOIN SAFI. This 556 information is flooded to all the PEs. As a result, an ingress PE 557 which is either directly connected to the IP multicast source or 558 connected via a CE configures its MVRF to start forwarding received 559 IP multicast data packets to a P2MP TE LSP which comprises the 560 Default MDT. In this way, IP multicast data packets are MPLS 561 encapsulated at an ingress proxy-RP (PE) and are tunneled via the 562 P2MP TE LSP to all the egress proxy-Source/RPs (PEs) and these IP 563 multicast data packets are decapsulated at the egress PEs and IP 564 multicast data packets are transmitted to IP multicast receivers in 565 the site if a shared tree is already formed by multicast receivers 566 who are interested in receiving these IP multicast flows. 568 When receivers in the customer's site want to switch multicast 569 distribution trees from a shared tree to a source specific tree, the 570 receivers send source specific Join (S,G) message to source node. In 571 this case, a source node is located in another site and therefore 572 this message is always transmitted to the PE which now acts as the 573 proxy-RP for that multicast group. Receiving this source specific 574 Join message, the PE changes IP multicast distribution to the source 575 specific tree because the PE starts acting as proxy-Source from that 576 point of time. Note that this multicast tree switch over does not 577 cause any additional JOIN SAFI transmission by the PE because the PE 578 can already receive IP multicast data and can act as proxy- Source 579 without changing the multicast distribution operation over the 580 provider core network. In this way, each customer's IP multicast 581 domain switches IP multicast tree from shared tee to source specific 582 tree independently without affecting the multicast distribution 583 within a provider core network and another customer's sites. 585 3.8. Data MDT operation 587 This document proposes to setup Data MDTs in addition to a Default 588 MDT when IP multicast transmission over a Default MDT is judged as 589 inefficient. The difference from conventional approaches [MCAST-VPN] 590 [MVPN-RAGGARWA] is this document assumes that Data MDTs are 591 constructed by [P2MP-RSVP]. Therefore, this proposal can construct 592 QoS guaranteed and highly reliable Data MDTs which would be better 593 for a particular class of IP multicast traffic. 595 This section describes how the proposed solution enables IP multicast 596 VPN operation using the Data MDT assuming a VPN customer runs the 597 PIM-SM protocol within their network. In this document, we assume two 598 kinds of Data MDT construction model; Static configuration model and 599 Traffic driven model. 601 In the static configuration model, we assume that IP multicast flows 602 which are transmitted by Data MDTs are pre-defined and mutually 603 agreed by the SP and its customers. This means that multicast group 604 addresses assigned for IP multicast flows which use Data MDT are 605 pre-defined and configured on each PE's MVRF. Therefore an ingress PE 606 which is registered by this multicast group address can setup, modify 607 and tear-down an appropriate P2MP TE LSP on demand. When several 608 downstream PEs which act as proxy-RP for interconnected customer 609 sites detect the existence of receivers which are interested in 610 joining a particular multicast distribution by receiving Join 611 messages, then the PEs report their interest to join the group by BGP 612 using the JOIN SAFI. After receiving these reports, an ingress PE 613 establishes a P2MP TE LSP to the egress leaves which have reported 614 interest. After this operation, when a new PE uses the BGP JOIN SAFI 615 to report to the ingress PE its interest to join the the group, the 616 ingress PE initiates Grafting and expands the P2MP TE LSP to reach 617 that new PE. When an existing PE detects that no more receivers are 618 connected to a customer's site by receiving Prune messages, the PE 619 withdraws the corresponding IP multicast registration by using BGP 620 withdraw message specifying the corresponding JOIN SAFI. 622 Then the ingress PE initiates Pruning and cuts out the unnecessary 623 leaf from the P2MP TE LSP. In this way, this proposal can setup, 624 modify and tear-down Data MDT on demand basis. 626 In the traffic driven model, an ingress PE monitors incoming IP 627 multicast data packets and when it detects some data flow exceeds a 628 pre-determined threshold, then the ingress PE immediately establishes 629 a new P2MP TE LSP to reach the receivers' PEs because the ingress PE 630 recognizes which PEs are interested in joining this group via 631 BGP. After establishment, the ingress PE switches corresponding IP 632 multicast data packets from the Default MDT to the Data MDT. In this 633 way, Data MDT based IP multicast transmission is performed on demand 634 in this model. After this Data MDT establishment, this model follows 635 exactly the same operations as the static configuration model when 636 the Data MDT is modified. 638 In order to associate the Data MDT with the appropriate MVRF, the 639 egress PEs utilize the PE Group-address announced by the PE (which is 640 the root of the P2MP TE LSP) via the SA SAFI. 642 3.9. Inter-Site Scaling and Site Interdependencies 644 As described in section 3.8, customer sites may be members of the 645 same multicast VPN yet operate in near independence. That is, each 646 site has its own RP and may choose to use a source-specific tree 647 based at the PE, or a shared distribution tree. This choice is 648 private to each customer site, and is not communicated to other sites 649 (nor would it provide any useful information if it were 650 communicated). 652 Clearly, also, the number of leaves downstream of an egress PE does 653 not affect the way in which the traffic is managed at upstream 654 nodes. That is, neither the source site nor the MPLS P2MP TE LSP in 655 the SP's network are in any way different if there is one or one 656 hundred receivers at a customer site downstream of an egress PE. The 657 PE represents a fixed point in the multicast tree that must receive 658 data and is an egress of the MPLS P2MP TE LSP. 660 For this reason, there is no requirement for the routing protocols to 661 report each receiver across the SP network to the ingress site when 662 the receivers are added to or removed from the multicast group. All 663 that is required is that the egress PE reports (using the BGP JOIN 664 SAFI) when the first receiver joins the group so that it becomes a 665 leaf on the MPLS P2MP TE LSP, and indicates when the last receiver at 666 the site leaves the multicast group so that the PE can be pruned from 667 the MPLS P2MP TE LSP. In order to make this optimization each PE must 668 count the number of receivers at its site, but since it is acting as 669 a proxy-source/RP this is easy for it to do. Such an optimization 670 substantially reduces the amount of MP-BGP traffic caused by the VPN 671 multicast group and is RECOMMENDED for all implementations. 673 Note that an egress PE that makes this optimization may further 674 protect itself against flapping membership of a multicast group. In 675 the case where the membership may frequently vary between no 676 receivers and some receivers an egress PE MAY choose to remain as a 677 leaf of the MPLS P2MP TE LSP for some period of time (controllable by 678 the operator) even when it has no downstream receivers for the 679 multicast traffic. If a local timer expires before any new receivers 680 join the group, the PE should use MP-BGP to report that it no longer 681 wishes to receive data for the multicast group, and this will result 682 in it being pruned from the MPLS P2MP TE LSP tree. Any traffic 683 received by a PE for a multicast group for which it has no downstream 684 receivers SHOULD be discarded. 686 3.10. Multi-Homing scenario 688 The proposed solution provides a very effective fail over mechanism 689 in the case where the multicast source/receivers are connected to 690 multiple PEs. The PEs which are connected to the customer network 691 announce themselves as the RPs via the bootstrap mechanism. When one 692 of the PE fails the alternate PE becomes RP for this multicast domain 693 and this PE can readily takeover as it is already connected via the 694 default MDT. 696 3.11. Multi-Area/As operation 698 This solution can be easily extended to Multi-Area/As operations as 699 P2MP TE tunnels can be setup in such scenarios between the PEs. The 700 details of this section will be provided in the next revision. 702 4. IANA Considerations 704 [TBD] 706 5. Security Considerations 708 Since this document is based on [RFC2547bis] and [P2MP-RSVP], the 709 security considerations involving those drafts apply here as well. 711 6. Acknowledgements 713 We would like to thank Antu Chatterjee and Masaaki TAKAGI for their 714 suggestions and contributions to this draft 716 7. Intellectual Property Considerations 718 The IETF takes no position regarding the validity or scope of any 719 Intellectual Property Rights or other rights that might be claimed to 720 pertain to the implementation or use of the technology described in 721 this document or the extent to which any license under such rights 722 might or might not be available; nor does it represent that it has 723 made any independent effort to identify any such rights. Information 724 on the procedures with respect to rights in RFC documents can be 725 found in BCP 78 and BCP 79. 727 Copies of IPR disclosures made to the IETF Secretariat and any 728 assurances of licenses to be made available, or the result of an 729 attempt made to obtain a general license or permission for the use of 730 such proprietary rights by implementers or users of this 731 specification can be obtained from the IETF on-line IPR repository at 732 http://www.ietf.org/ipr. 734 The IETF invites any interested party to bring to its attention any 735 copyrights, patents or patent applications, or other proprietary 736 rights that may cover technology that may be required to implement 737 this standard. Please address the information to the IETF at 738 ietf-ipr@ietf.org. 740 8. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 746 RFC 3667, February 2004. 748 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 749 Technology", BCP 79, RFC 3668, February 2004. 751 [RFC2547bis] Rosen, E., et. al. "BGP/MPLS VPNs", 752 draft-ietf-l3vpn-rfc2547bis, work in progress 754 [PIM-SM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, 755 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 756 Protocol Specification (Revised)", 757 draft-ietf-pim-sm-v2-new-08.txt, work in progress. 759 9. Informational References 761 [RFC3446] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, 762 "Anycast Rendevous Point (RP) mechanism using Protocol 763 Independent Multicast (PIM) and Multicast Source 764 Discovery Protocol (MSDP)", January 2003 766 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 767 IANA Considerations Section in RFCs", BCP: 26, RFC 2434, 768 October 1998. 770 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 771 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 772 Tunnels", RFC 3209, December 2001. 774 [RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC 775 Text on Security Considerations", BCP: 72, RFC 3552, 776 July 2003. 778 [P2MP-REQ] S. Yasukawa, et. al., "Requirements for Point to 779 Multipoint Traffic Engineered MPLS LSPs", 780 draft-ietf-mpls-p2mp-requirement, work in progress. 782 [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to 783 Multipoint TE LSPs", draft-raggarwa-mpls-rsvp-te-p2mp, 784 work in progress. 786 [MDT-SAFI] Nalawade and Sreekantiah, "MDT SAFI", 787 draft-nalawade-idr-mdt-safi-00.txt, February 2004 789 [MCAST-VPN] Y. Cai, E. Rosen, I. Wijnands, "Multicast in BGP/MPLS 790 IP VPNs", , May 2004. 792 [MVPN-RAGGARWA] R. Aggarwal, "Multicast in BGP/MPLS VPNs and VPLS", 793 , 794 February, 2004. 796 [MP2MP-TE-MPLS] Work in progress 798 [PIM-BSR] N.Bhaskar, A Gall and Stig Venaas, 799 "BootStrap Router(BSR) Mechanism for PIM", 800 , July 2004. 802 10. Authors' Addresses 804 Seisho Yasukawa 805 NTT Corporation 806 9-11, Midori-Cho 3-Chome 807 Musashino-Shi, Tokyo 180-8585, 808 Japan 809 Phone: +81 422 59 4769 810 Email: yasukawa.seisho@lab.ntt.co.jp 812 Shankar Karuna 813 Motorola 814 Vanenburg IT park, Madhapur, 815 Hyderabad, India 816 Email: kshankar@motorola.com 817 Sarveshwar Bandi 818 Motorola 819 Vanenburg IT park, Madhapur, 820 Hyderabad, India 821 Email: sarvesh@motorola.com 823 Adrian Farrel 824 Old Dog Consulting 825 EMail: adrian@olddog.co.uk 827 11. Full Copyright Statement 829 Copyright (C) The Internet Society (2004). This document is subject 830 to the rights, licenses and restrictions contained in BCP 78, and 831 except as set forth therein, the authors retain all their rights. 833 This document and the information contained herein are provided on an 834 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 835 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 836 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 837 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 838 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 839 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.