idnits 2.17.1 draft-ietf-l3vpn-2547bis-mcast-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4115. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4121. 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 IETF Trust 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 (July 9, 2008) is 5770 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) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-05 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-06 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-05 == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-04 ** Obsolete normative reference: RFC 4601 (ref. 'PIM-SM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen (Editor) 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Standards Track 5 Expires: January 9, 2009 Rahul Aggarwal (Editor) 6 Juniper Networks 8 July 9, 2008 10 Multicast in MPLS/BGP IP VPNs 12 draft-ietf-l3vpn-2547bis-mcast-07.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual 40 Private Network) to travel from one VPN site to another, special 41 protocols and procedures must be implemented by the VPN Service 42 Provider. These protocols and procedures are specified in this 43 document. 45 Table of Contents 47 1 Specification of requirements ......................... 5 48 2 Introduction .......................................... 5 49 2.1 Optimality vs Scalability ............................. 5 50 2.1.1 Multicast Distribution Trees .......................... 7 51 2.1.2 Ingress Replication through Unicast Tunnels ........... 8 52 2.2 Overview .............................................. 8 53 2.2.1 Multicast Routing Adjacencies ......................... 8 54 2.2.2 MVPN Definition ....................................... 9 55 2.2.3 Auto-Discovery ........................................ 10 56 2.2.4 PE-PE Multicast Routing Information ................... 11 57 2.2.5 PE-PE Multicast Data Transmission ..................... 11 58 2.2.6 Inter-AS MVPNs ........................................ 12 59 2.2.7 Optionally Eliminating Shared Tree State .............. 13 60 3 Concepts and Framework ................................ 13 61 3.1 PE-CE Multicast Routing ............................... 13 62 3.2 P-Multicast Service Interfaces (PMSIs) ................ 14 63 3.2.1 Inclusive and Selective PMSIs ......................... 15 64 3.2.2 P-Tunnels Instantiating PMSIs ......................... 16 65 3.3 Use of PMSIs for Carrying Multicast Data .............. 18 66 3.4 PE-PE Transmission of C-Multicast Routing ............. 20 67 3.4.1 PIM Peering ........................................... 20 68 3.4.1.1 Full Per-MVPN PIM Peering Across a MI-PMSI ............ 20 69 3.4.1.2 Lightweight PIM Peering Across a MI-PMSI .............. 20 70 3.4.1.3 Unicasting of PIM C-Join/Prune Messages ............... 21 71 3.4.2 Using BGP to Carry C-Multicast Routing ................ 22 72 4 BGP-Based Autodiscovery of MVPN Membership ............ 22 73 5 PE-PE Transmission of C-Multicast Routing ............. 25 74 5.1 Selecting the Upstream Multicast Hop (UMH) ............ 26 75 5.1.1 Eligible Routes for UMH Selection ..................... 26 76 5.1.2 Information Carried by Eligible UMH Routes ............ 27 77 5.1.3 Selecting the Upstream PE ............................. 27 78 5.1.4 Selecting the Upstream Multicast Hop .................. 29 79 5.2 Details of Per-MVPN Full PIM Peering over MI-PMSI ..... 29 80 5.2.1 PIM C-Instance Control Packets ........................ 30 81 5.2.2 PIM C-instance RPF Determination ...................... 30 82 5.3 Use of BGP for Carrying C-Multicast Routing ........... 31 83 5.3.1 Sending BGP Updates ................................... 31 84 5.3.2 Explicit Tracking ..................................... 32 85 5.3.3 Withdrawing BGP Updates ............................... 33 86 5.3.4 BSR ................................................... 33 87 6 PMSI Instantiation .................................... 34 88 6.1 Use of the Intra-AS I-PMSI A-D Route .................. 34 89 6.1.1 Sending Intra-AS I-PMSI A-D Routes .................... 34 90 6.1.2 Receiving Intra-AS I-PMSI A-D Routes .................. 35 91 6.2 When C-flows are Specifically Bound to P-Tunnels ...... 35 92 6.3 Aggregating Multiple MVPNs on a Single P-tunnel ....... 36 93 6.3.1 Aggregate Tree Leaf Discovery ......................... 37 94 6.3.2 Aggregation Methodology ............................... 37 95 6.3.3 Demultiplexing C-multicast traffic .................... 38 96 6.4 Considerations for Specific Tunnel Technologies ....... 40 97 6.4.1 RSVP-TE P2MP LSPs ..................................... 40 98 6.4.2 PIM Trees ............................................. 42 99 6.4.3 mLDP P2MP LSPs ........................................ 43 100 6.4.4 mLDP MP2MP LSPs ....................................... 43 101 6.4.5 Ingress Replication ................................... 43 102 7 Binding Specific C-flows to Specific P-Tunnels ........ 44 103 7.1 General Considerations when Switching P-Tunnels ....... 46 104 7.2 Optimizing Multicast Distribution via S-PMSIs ......... 47 105 7.3 Announcing the Presence of Unsolicited Flooded Data ... 49 106 7.4 Protocols for Binding C-flows to P-tunnels ............ 49 107 7.4.1 Using BGP S-PMSI A-D Routes ........................... 50 108 7.4.1.1 Advertising C-flow Binding to P-Tunnel ................ 50 109 7.4.1.2 Explicit Tracking ..................................... 51 110 7.4.2 UDP-based Protocol .................................... 51 111 7.4.2.1 Advertising C-flow Binding to P-tunnel ................ 51 112 7.4.2.2 Packet Formats and Constants .......................... 52 113 7.4.3 Aggregation ........................................... 54 114 8 Inter-AS Procedures ................................... 54 115 8.1 Non-Segmented Inter-AS P-Tunnels ...................... 55 116 8.1.1 Inter-AS MVPN Auto-Discovery .......................... 55 117 8.1.2 Inter-AS MVPN Routing Information Exchange ............ 56 118 8.1.3 Inter-AS P-Tunnels .................................... 56 119 8.1.3.1 PIM-Based Inter-AS P-Multicast Trees .................. 56 120 8.1.3.2 The PIM MVPN Join Attribute ........................... 58 121 8.1.3.2.1 Definition ............................................ 58 122 8.1.3.2.2 Usage ................................................. 59 123 8.2 Segmented Inter-AS P-Tunnels .......................... 59 124 8.2.1 Inter-AS MVPN Auto-Discovery Routes ................... 59 125 8.2.1.1 Originating Inter-AS MVPN A-D Information ............. 60 126 8.2.1.2 Propagating Inter-AS MVPN A-D Information ............. 61 127 8.2.1.2.1 Inter-AS Auto-Discovery Route received via EBGP ....... 61 128 8.2.1.2.2 Leaf Auto-Discovery Route received via EBGP ........... 63 129 8.2.1.2.3 Inter-AS Auto-Discovery Route received via IBGP ....... 63 130 8.2.2 Inter-AS MVPN Routing Information Exchange ............ 64 131 8.2.3 Inter-AS I-PMSI ....................................... 64 132 8.2.3.1 Support for Unicast VPN Inter-AS Methods .............. 65 133 8.2.3.2 Bandwidth Optimization by Filtering on ASBRs .......... 65 134 8.2.4 Inter-AS S-PMSI ....................................... 66 135 9 Duplicate Packet Detection and Single Forwarder PE .... 67 136 9.1 Multihomed C-S or C-RP ................................ 68 137 9.1.1 Single forwarder PE selection ......................... 69 138 9.2 Switching from the C-RP tree to C-S tree .............. 70 139 10 Eliminating PE-PE Distribution of (C-*,C-G) State ..... 71 140 10.1 Co-locating C-RPs on a PE ............................. 72 141 10.1.1 Initial Configuration ................................. 73 142 10.1.2 Anycast RP Based on Propagating Active Sources ........ 73 143 10.1.2.1 Receiver(s) Within a Site ............................. 73 144 10.1.2.2 Source Within a Site .................................. 73 145 10.1.2.3 Receiver Switching from Shared to Source Tree ......... 74 146 10.2 Using MSDP between a PE and a Local C-RP .............. 74 147 11 Support for PIM-BIDIR C-Groups ........................ 75 148 11.1 The VPN Backbone Becomes the RPL ...................... 76 149 11.1.1 Control Plane ......................................... 76 150 11.1.2 Data Plane ............................................ 77 151 11.2 Partitioned Sets of PEs ............................... 77 152 11.2.1 Partitions ............................................ 78 153 11.2.2 Using PE Distinguisher Labels ......................... 79 154 11.2.3 Partial Mesh of MP2MP P-Tunnels ....................... 79 155 12 Encapsulations ........................................ 80 156 12.1 Encapsulations for Single PMSI per P-Tunnel ........... 80 157 12.1.1 Encapsulation in GRE .................................. 80 158 12.1.2 Encapsulation in IP ................................... 81 159 12.1.3 Encapsulation in MPLS ................................. 82 160 12.2 Encapsulations for Multiple PMSIs per P-Tunnel ........ 82 161 12.2.1 Encapsulation in GRE .................................. 83 162 12.2.2 Encapsulation in IP ................................... 83 163 12.3 Encapsulations Identifying a Distinguished PE ......... 83 164 12.3.1 For MP2MP LSP P-tunnels ............................... 83 165 12.3.2 For Support of PIM-BIDIR C-Groups ..................... 84 166 12.4 General Considerations for IP and GRE Encaps .......... 84 167 12.4.1 MTU (Maximum Transmission Unit) ....................... 84 168 12.4.2 TTL (Time to Live) .................................... 85 169 12.4.3 Avoiding Conflict with Internet Multicast ............. 85 170 12.5 Differentiated Services ............................... 86 171 13 Security Considerations ............................... 86 172 14 IANA Considerations ................................... 87 173 15 Other Authors ......................................... 87 174 16 Other Contributors .................................... 87 175 17 Authors' Addresses .................................... 87 176 18 Normative References .................................. 89 177 19 Informative References ................................ 90 178 20 Full Copyright Statement .............................. 91 179 21 Intellectual Property ................................. 91 181 1. Specification of requirements 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 2. Introduction 189 [RFC4364] specifies the set of procedures that a Service Provider 190 (SP) must implement in order to provide a particular kind of VPN 191 service ("BGP/MPLS IP VPN") for its customers. The service described 192 therein allows IP unicast packets to travel from one customer site to 193 another, but it does not provide a way for IP multicast traffic to 194 travel from one customer site to another. 196 This document extends the service defined in [RFC4364] so that it 197 also includes the capability of handling IP multicast traffic. This 198 requires a number of different protocols to work together. The 199 document provides a framework describing how the various protocols 200 fit together, and also provides detailed specification of some of the 201 protocols. The detailed specification of some of the other protocols 202 is found in pre-existing documents or in companion documents. 204 Throughout this draft we will use the term "VPN-IP route" to mean a 205 route that is either in the VPN-IPv4 address family [RFC4364] or in 206 the VPN-IPv6 address family [RFC4659]. 208 2.1. Optimality vs Scalability 210 In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is 211 achieved without the need to keep any per-VPN state in the core of 212 the SP's network (the "P routers"). Routing information from a 213 particular VPN is maintained only by the Provider Edge routers (the 214 "PE routers", or "PEs") that attach directly to sites of that VPN. 215 Customer data travels through the P routers in tunnels from one PE to 216 another (usually MPLS Label Switched Paths, LSPs), so to support the 217 VPN service the P routers only need to have routes to the PE routers. 218 The PE-to-PE routing is optimal, but the amount of associated state 219 in the P routers depends only on the number of PEs, not on the number 220 of VPNs. 222 However, in order to provide optimal multicast routing for a 223 particular multicast flow, the P routers through which that flow 224 travels have to hold state that is specific to that flow. A 225 multicast flow is identified by the (source, group) tuple where the 226 source is the IP address of the sender and the group is the IP 227 multicast group address of the destination. Scalability would be 228 poor if the amount of state in the P routers were proportional to the 229 number of multicast flows in the VPNs. Therefore, when supporting 230 multicast service for a BGP/MPLS IP VPN, the optimality of the 231 multicast routing must be traded off against the scalability of the P 232 routers. We explain this below in more detail. 234 If a particular VPN is transmitting "native" multicast traffic over 235 the backbone, we refer to it as an "MVPN". By "native" multicast 236 traffic, we mean packets that a CE sends to a PE, such that the IP 237 destination address of the packets is a multicast group address, or 238 the packets are multicast control packets addressed to the PE router 239 itself, or the packets are IP multicast data packets encapsulated in 240 MPLS. 242 We say that the backbone multicast routing for a particular multicast 243 group in a particular VPN is "optimal" if and only if all of the 244 following conditions hold: 246 - When a PE router receives a multicast data packet of that group 247 from a CE router, it transmits the packet in such a way that the 248 packet is received by every other PE router that is on the path 249 to a receiver of that group; 251 - The packet is not received by any other PEs; 253 - While in the backbone, no more than one copy of the packet ever 254 traverses any link. 256 - While in the backbone, if bandwidth usage is to be optimized, the 257 packet traverses minimum cost trees rather than shortest path 258 trees. 260 Optimal routing for a particular multicast group requires that the 261 backbone maintain one or more source-trees that are specific to that 262 flow. Each such tree requires that state be maintained in all the P 263 routers that are in the tree. 265 This would potentially require an unbounded amount of state in the P 266 routers, since the SP has no control of the number of multicast 267 groups in the VPNs that it supports. Nor does the SP have any control 268 over the number of transmitters in each group, nor of the 269 distribution of the receivers. 271 The procedures defined in this document allow an SP to provide 272 multicast VPN service without requiring the amount of state 273 maintained by the P routers to be proportional to the number of 274 multicast data flows in the VPNs. The amount of state is traded off 275 against the optimality of the multicast routing. Enough flexibility 276 is provided so that a given SP can make his own tradeoffs between 277 scalability and optimality. An SP can even allow some multicast 278 groups in some VPNs to receive optimal routing, while others do not. 279 Of course, the cost of this flexibility is an increase in the number 280 of options provided by the protocols. 282 The basic technique for providing scalability is to aggregate a 283 number of customer multicast flows onto a single multicast 284 distribution tree through the P routers. A number of aggregation 285 methods are supported. 287 The procedures defined in this document also accommodate the SP that 288 does not want to build multicast distribution trees in his backbone 289 at all; the ingress PE can replicate each multicast data packet and 290 then unicast each replica through a tunnel to each egress PE that 291 needs to receive the data. 293 2.1.1. Multicast Distribution Trees 295 This document supports the use of a single multicast distribution 296 tree in the backbone to carry all the multicast traffic from a 297 specified set of one or more MVPNs. Such a tree is referred to as an 298 "Inclusive Tree". An Inclusive Tree that carries the traffic of more 299 than one MVPN is an "Aggregate Inclusive Tree". An Inclusive Tree 300 contains, as its members, all the PEs that attach to any of the MVPNs 301 using the tree. 303 With this option, even if each tree supports only one MVPN, the upper 304 bound on the amount of state maintained by the P routers is 305 proportional to the number of VPNs supported, rather than to the 306 number of multicast flows in those VPNs. If the trees are 307 unidirectional, it would be more accurate to say that the state is 308 proportional to the product of the number of VPNs and the average 309 number of PEs per VPN. The amount of state maintained by the P 310 routers can be further reduced by aggregating more MVPNs onto a 311 single tree. If each such tree supports a set of MVPNs, (call it an 312 "MVPN aggregation set"), the state maintained by the P routers is 313 proportional to the product of the number of MVPN aggregation sets 314 and the average number of PEs per MVPN. Thus the state does not grow 315 linearly with the number of MVPNs. 317 However, as data from many multicast groups is aggregated together 318 onto a single "Inclusive Tree", it is likely that some PEs will 319 receive multicast data for which they have no need, i.e., some degree 320 of optimality has been sacrificed. 322 This document also provides procedures that enable a single multicast 323 distribution tree in the backbone to be used to carry traffic 324 belonging only to a specified set of one or more multicast groups, 325 from one or more MVPNs. Such a tree is referred to as a "Selective 326 Tree" and more specifically as an "Aggregate Selective Tree" when the 327 multicast groups belong to different MVPNs. By default, traffic from 328 most multicast groups could be carried by an Inclusive Tree, while 329 traffic from, e.g., high bandwidth groups could be carried in one of 330 the "Selective Trees". When setting up the Selective Trees, one 331 should include only those PEs that need to receive multicast data 332 from one or more of the groups assigned to the tree. This provides 333 more optimal routing than can be obtained by using only Inclusive 334 Trees, though it requires additional state in the P routers. 336 2.1.2. Ingress Replication through Unicast Tunnels 338 This document also provides procedures for carry MVPN data traffic 339 through unicast tunnels from the ingress PE to each of the egress 340 PEs. The ingress PE replicates the multicast data packet received 341 from a CE and sends it to each of the egress PEs using the unicast 342 tunnels. This requires no multicast routing state in the P routers 343 at all, but it puts the entire replication load on the ingress PE 344 router, and makes no attempt to optimize the multicast routing. 346 2.2. Overview 348 2.2.1. Multicast Routing Adjacencies 350 In BGP/MPLS IP VPNs [RFC4364], each CE ("Customer Edge") router is a 351 unicast routing adjacency of a PE router, but CE routers at different 352 sites do not become unicast routing adjacencies of each other. This 353 important characteristic is retained for multicast routing -- a CE 354 router becomes a multicast routing adjacency of a PE router, but CE 355 routers at different sites do not become multicast routing 356 adjacencies of each other. 358 The multicast routing protocol on the PE-CE link is presumed to be 359 PIM ("Protocol Independent Multicast") [PIM-SM]. Both the ASM ("Any 360 Source Multicast") and the SSM ("Source-Specific Multicast") service 361 models are supported. Thus both shared C-trees and source-specific C- 362 trees are supported. Shared C-trees may be unidirectional or 363 bidirectional; in the latter case the multicast routing protocol is 364 presumed to be the BIDIR-PIM [BIDIR-PIM] "variant" of PIM-SM. A CE 365 router exchanges "ordinary" PIM control messages with the PE router 366 to which it is attached. 368 Support for PIM-DM ("Dense Mode") is outside the scope of this 369 document. 371 The PEs attaching to a particular MVPN then have to exchange the 372 multicast routing information with each other. Two basic methods for 373 doing this are defined: (1) PE-PE PIM, and (2) BGP. In the former 374 case, the PEs need to be multicast routing adjacencies of each other. 375 In the latter case, they do not. For example, each PE may be a BGP 376 adjacency of a Route Reflector (RR), and not of any other PEs. 378 In order to support the "Carrier's Carrier" model of [RFC4364], mLDP 379 (Label Distribution Protocol Extentions for Multipoint Label Switched 380 Paths) [MLDP] may also be supported on the PE-CE interface. The use 381 of mLDP on the PE-CE interface is described in [MVPN-BGP]. The use 382 of BGP on the PE-CE interface is not within the scope of this 383 document. 385 2.2.2. MVPN Definition 387 An MVPN is defined by two sets of sites, Sender Sites set and 388 Receiver Sites set, with the following properties: 390 - Hosts within the Sender Sites set could originate multicast 391 traffic for receivers in the Receiver Sites set. 393 - Receivers not in the Receiver Sites set should not be able to 394 receive this traffic. 396 - Hosts within the Receiver Sites set could receive multicast 397 traffic originated by any host in the Sender Sites set. 399 - Hosts within the Receiver Sites set should not be able to receive 400 multicast traffic originated by any host that is not in the 401 Sender Sites set. 403 A site could be both in the Sender Sites set and Receiver Sites set, 404 which implies that hosts within such a site could both originate and 405 receive multicast traffic. An extreme case is when the Sender Sites 406 set is the same as the Receiver Sites set, in which case all sites 407 could originate and receive multicast traffic from each other. 409 Sites within a given MVPN may be either within the same, or in 410 different organizations, which implies that an MVPN can be either an 411 Intranet or an Extranet. 413 A given site may be in more than one MVPN, which implies that MVPNs 414 may overlap. 416 Not all sites of a given MVPN have to be connected to the same 417 service provider, which implies that an MVPN can span multiple 418 service providers. 420 Another way to look at MVPN is to say that an MVPN is defined by a 421 set of administrative policies. Such policies determine both Sender 422 Sites set and Receiver Sites set. Such policies are established by 423 MVPN customers, but implemented/realized by MVPN Service Providers 424 using the existing BGP/MPLS VPN mechanisms, such as Route Targets, 425 with extensions, as necessary. 427 2.2.3. Auto-Discovery 429 In order for the PE routers attaching to a given MVPN to exchange 430 MVPN control information with each other, each one needs to discover 431 all the other PEs that attach to the same MVPN. (Strictly speaking, 432 a PE in the Receiver Sites set need only discover the other PEs in 433 the Sender Sites set and a PE in the Sender Sites set need only 434 discover the other PEs in the Receiver Sites set.) This is referred 435 to as "MVPN Auto-Discovery". 437 This document discusses two ways of providing MVPN autodiscovery: 439 - BGP can be used for discovering and maintaining MVPN membership. 440 The PE routers advertise their MVPN membership to other PE 441 routers using BGP. A PE is considered to be a "member" of a 442 particular MVPN if it contains a VRF (Virtual Routing and 443 Forwarding table, see [RFC4364]) that is configured to contain 444 the multicast routing information of that MVPN. This auto- 445 discovery option does not make any assumptions about the methods 446 used for transmitting MVPN multicast data packets through the 447 backbone. 449 - If it is known that the PE-PE multicast control packets (i.e., 450 PIM packets) of a particular MVPN are to be transmitted through a 451 non-aggregated Inclusive Tree supporting the ASM service model 452 (e.g., through a Tree that is created by non-SSM PIM-SM or by 453 BIDIR-PIM), and if the PEs attaching to that MVPN are configured 454 with the group address corresponding to that tree, then the PEs 455 can auto-discover each other simply by joining the tree and then 456 multicasting PIM Hellos over the tree. 458 2.2.4. PE-PE Multicast Routing Information 460 The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain 461 at most one BGP peering with every other PE in the network. This 462 peering is used to exchange VPN routing information. The use of Route 463 Reflectors further reduces the number of BGP adjacencies maintained 464 by a PE to exchange VPN routing information with other PEs. This 465 document describes various options for exchanging MVPN control 466 information between PE routers based on the use of PIM or BGP. These 467 options have different overheads with respect to the number of 468 routing adjacencies that a PE router needs to maintain to exchange 469 MVPN control information with other PE routers. Some of these options 470 allow the retention of the unicast BGP/MPLS VPN model letting a PE 471 maintain at most one BGP routing adjacency with other PE routers to 472 exchange MVPN control information. BGP also provides reliable 473 transport and uses incremental updates. Another option is the use of 474 the currently existing, "soft state" PIM standard [PIM-SM] that uses 475 periodic complete updates. 477 2.2.5. PE-PE Multicast Data Transmission 479 Like [RFC4364], this document decouples the procedures for exchanging 480 routing information from the procedures for transmitting data 481 traffic. Hence a variety of transport technologies may be used in the 482 backbone. For inclusive trees, these transport technologies include 483 unicast PE-PE tunnels, using encapsulation in MPLS, IP, or GRE 484 ("Generic Routing Encapsulation"), multicast distribution trees 485 created by PIM (either unidirectional in the SSM or ASM service 486 models, or bidirectional) using IP/GRE encapsulation, point-to- 487 multipoint LSPs created by RSVP-TE or mLDP, and multipoint-to- 488 multipoint LSPs created by mLDP. 490 In order to aggregate traffic from multiple MVPNs onto a single 491 multicast distribution tree, it is necessary to have a mechanism to 492 enable the egresses of the tree to demultiplex the multicast traffic 493 received over the tree and to associate each received packet with a 494 particular MVPN. This document specifies a mechanism whereby 495 upstream label assignment [MPLS-UPSTREAM-LABEL] is used by the root 496 of the tree to assign a label to each flow. This label is used by 497 the receivers to perform the demultiplexing. This document also 498 describes procedures based on BGP that are used by the root of an 499 Aggregate Tree to advertise the Inclusive and/or Selective binding 500 and the demultiplexing information to the leaves of the tree. 502 This document also describes the data plane encapsulations for 503 supporting the various SP multicast transport options. 505 The specification for aggregating traffic of multiple MVPNs onto a 506 single multipoint-to-multipoint LSP or onto a single bidirectional 507 multicast distribution tree is outside the scope of this document. 509 The specifications for using as selective trees multicast 510 distribution trees that support the ASM service model is outside the 511 scope of this document. The specification for using multipoint-to- 512 multipoint LSPs as selective trees is outside the scope of this 513 document. 515 This document assumes that when SP multicast trees are used, traffic 516 for a particular multicast group is transmitted by a particular PE on 517 only one SP multicast tree. The use of multiple SP multicast trees 518 for transmitting traffic belonging to a particular multicast group is 519 outside the scope of this document. 521 2.2.6. Inter-AS MVPNs 523 [RFC4364] describes different options for supporting BGP/MPLS IP 524 unicast VPNs whose provider backbones contain more than one 525 Autonomous System (AS). These are know as Inter-AS VPNs. In an 526 Inter-AS VPN, the ASes may belong to the same provider or to 527 different providers. This document describes how Inter-AS MVPNs can 528 be supported for each of the unicast BGP/MPLS VPN Inter-AS options. 529 This document also specifies a model where Inter-AS MVPN service can 530 be offered without requiring a single SP multicast tree to span 531 multiple ASes. In this model, an inter-AS multicast tree consists of 532 a number of "segments", one per AS, which are stitched together at AS 533 boundary points. These are known as "segmented inter-AS trees". Each 534 segment of a segmented inter-AS tree may use a different multicast 535 transport technology. 537 It is also possible to support Inter-AS MVPNs with non-segmented 538 source trees that extend across AS boundaries. 540 2.2.7. Optionally Eliminating Shared Tree State 542 The document also discusses some options and protocol extensions that 543 can be used to eliminate the need for the PE routers to distribute to 544 each other the (*,G) and (*,G,RPT-bit) states that occur when the 545 VPNs are creating unidirectional C-trees to support the ASM service 546 model. 548 3. Concepts and Framework 550 3.1. PE-CE Multicast Routing 552 Support of multicast in BGP/MPLS IP VPNs is modeled closely after 553 support of unicast in BGP/MPLS IP VPNs. That is, a multicast routing 554 protocol will be run on the PE-CE interfaces, such that PE and CE are 555 multicast routing adjacencies on that interface. CEs at different 556 sites do not become multicast routing adjacencies of each other. 558 If a PE attaches to n VPNs for which multicast support is provided 559 (i.e., to n "MVPNs"), the PE will run n independent instances of a 560 multicast routing protocol. We will refer to these multicast routing 561 instances as "VPN-specific multicast routing instances", or more 562 briefly as "multicast C-instances". The notion of a "VRF" ("Virtual 563 Routing and Forwarding Table"), defined in [RFC4364], is extended to 564 include multicast routing entries as well as unicast routing entries. 565 Each multicast routing entry is thus associated with a particular 566 VRF. 568 Whether a particular VRF belongs to an MVPN or not is determined by 569 configuration. 571 In this document, we will not attempt to provide support for every 572 possible multicast routing protocol that could possibly run on the 573 PE-CE link. Rather, we consider multicast C-instances only for the 574 following multicast routing protocols: 576 - PIM Sparse Mode (PIM-SM), supporting the ASM service model 578 - PIM Sparse Mode, supporting the SSM service model 580 - PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional C- 581 trees to support the ASM service model. 583 In order to support the "Carrier's Carrier" model of [RFC4364], mLDP 584 may also be supported on the PE-CE interface. The use of mLDP on the 585 PE-CE interface is described in [MVPN-BGP]. 587 The use of BGP on the PE-CE interface is not within the scope of this 588 document. 590 As the only multicast C-instances discussed by this document are PIM- 591 based C-instances, we will generally use the term "PIM C-instances" 592 to refer to the multicast C-instances. 594 A PE router may also be running a "provider-wide" instance of PIM, (a 595 "PIM P-instance"), in which it has a PIM adjacency with, e.g., each 596 of its IGP neighbors (i.e., with P routers), but NOT with any CE 597 routers, and not with other PE routers (unless another PE router 598 happens to be an IGP adjacency). In this case, P routers would also 599 run the P-instance of PIM, but NOT a C-instance. If there is a PIM 600 P-instance, it may or may not have a role to play in support of VPN 601 multicast; this is discussed in later sections. However, in no case 602 will the PIM P-instance contain VPN-specific multicast routing 603 information. 605 In order to help clarify when we are speaking of the PIM P-instance 606 and when we are speaking of a PIM C-instance, we will also apply the 607 prefixes "P-" and "C-" respectively to control messages, addresses, 608 etc. Thus a P-Join would be a PIM Join that is processed by the PIM 609 P-instance, and a C-Join would be a PIM Join that is processed by a 610 C-instance. A P-group address would be a group address in the SP's 611 address space, and a C-group address would be a group address in a 612 VPN's address space. A C-Tree is a multicast distribution tree 613 constructed and maintained by the PIM C-instances. A C-flow is a 614 stream of multicast packets with a common C-source address and a 615 common C-group address. We will use the notation "C-(S,G)" or "(C- 616 S,C-G)" to identify specific C-flows. If a particular C-tree is a 617 shared tree (whether unidirectional or bidirectional) rather than a 618 source-specific tree, we will sometimes speak of the entire set of 619 flows traveling that tree, identifying the set as "C-(*,G)" or 620 "(C-*,C-G)". 622 3.2. P-Multicast Service Interfaces (PMSIs) 624 Multicast data packets received by a PE over a PE-CE interface must 625 be forwarded to one or more of the other PEs in the same MVPN for 626 delivery to one or more other CEs. 628 We define the notion of a "P-Multicast Service Interface" (PMSI). If 629 a particular MVPN is supported by a particular set of PE routers, 630 then there will be one or more PMSIs connecting those PE routers 631 and/or subsets thereof. A PMSI is a conceptual "overlay" on the P 632 network with the following property: a PE in a given MVPN can give a 633 packet to the PMSI, and the packet will be delivered to some or all 634 of the other PEs in the MVPN, such that any PE receiving the packet 635 will be able to determine the MVPN to which the packet belongs. 637 As we discuss below, a PMSI may be instantiated by a number of 638 different transport mechanisms, depending on the particular 639 requirements of the MVPN and of the SP. We will refer to these 640 transport mechanisms as "P-tunnels". 642 For each MVPN, there are one or more PMSIs that are used for 643 transmitting the MVPN's multicast data from one PE to others. We 644 will use the term "PMSI" such that a single PMSI belongs to a single 645 MVPN. However, the transport mechanism that is used to instantiate a 646 PMSI may allow a single P-tunnel to carry the data of multiple PMSIs. 648 In this document we make a clear distinction between the multicast 649 service (the PMSI) and its instantiation. This allows us to separate 650 the discussion of different services from the discussion of different 651 instantiations of each service. The term "P-tunnel" is used to refer 652 to the transport mechanism that instantiates a service. 654 PMSIs are used to carry C-multicast data traffic. The C-multicast 655 data traffic travels along a C-tree, but in the SP backbone all C- 656 trees are tunneled through P-tunnels. Thus we will sometimes talk of 657 a P-tunnel carrying one or more C-trees. 659 Some of the options for passing multicast control traffic among the 660 PEs do so by sending the control traffic through a PMSI; other 661 options do not send control traffic through a PMSI. 663 3.2.1. Inclusive and Selective PMSIs 665 We will distinguish between three different kinds of PMSI: 667 - "Multidirectional Inclusive" PMSI (MI-PMSI) 669 A Multidirectional Inclusive PMSI is one that enables ANY PE 670 attaching to a particular MVPN to transmit a message such that it 671 will be received by EVERY other PE attaching to that MVPN. 673 There is at most one MI-PMSI per MVPN. (Though the P-tunnel or 674 P-tunnels that instantiate an MI-PMSI may actually carry the data 675 of more than one PMSI.) 677 An MI-PMSI can be thought of as an overlay broadcast network 678 connecting the set of PEs supporting a particular MVPN. 680 - "Unidirectional Inclusive" PMSI (UI-PMSI) 682 A Unidirectional Inclusive PMSI is one that enables a particular 683 PE, attached to a particular MVPN, to transmit a message such 684 that it will be received by all the other PEs attaching to that 685 MVPN. There is at most one UI-PMSI per PE per MVPN, though the 686 P-tunnel that instantiates a UI-PMSI may in fact carry the data 687 of more than one PMSI. 689 - "Selective" PMSI (S-PMSI). 691 A Selective PMSI is one that provides a mechanism wherein a 692 particular PE in an MVPN can multicast messages so that they will 693 be received by a subset of the other PEs of that MVPN. There may 694 be an arbitrary number of S-PMSIs per PE per MVPN. The P-tunnel 695 that instantiates a given S-PMSI may carry data from multiple S- 696 PMSIs. 698 We will see in later sections the role played by these different 699 kinds of PMSI. We will use the term "I-PMSI" when we are not 700 distinguishing between "MI-PMSIs" and "UI-PMSIs". 702 3.2.2. P-Tunnels Instantiating PMSIs 704 The P-tunnels that are used to instantiate PMSIs will be referred to 705 as "P-tunnels". A number of different tunnel setup techniques can be 706 used to create the P-tunnels that instantiate the PMSIs. Among these 707 are: 709 - PIM 711 A PMSI can be instantiated as (a set of) Multicast Distribution 712 Trees created by the PIM P-instance ("P-trees"). 714 The multicast distribution trees that instantiate I-PMSIs may be 715 either shared trees or source-specific trees. 717 This document (along with [MVPN-BGP]) specifies procedures for 718 identifying a particular C-(S,G) flow and assigning it to a 719 particular S-PMSI. Such an S-PMSI is most naturally instantiated 720 as a source-specific tree. 722 The use of shared trees (including bidirectional trees) to 723 instantiate S-PMSIs is outside the scope of this document. 725 The use of PIM-DM to create P-tunnels is not supported. 727 P-tunnels may be shared by multiple MVPNs (i.e., a given P-tunnel 728 may be the instantiation of multiple PMSIs), as long as the 729 tunnel encapsulation provides some means of demultiplexing the 730 data traffic by MVPN. 732 - MLDP 734 MLDP Point-to-Multipoint (P2MP) LSPs or Multipoint-to-Multipoint 735 (MP2MP) LSPs can be used to instantiate I-PMSIs. 737 An S-PMSI or a UI-PMSI could be instantiated as a single mLDP 738 P2MP LSP, whereas an MI-PMSI would have to be instantiated as a 739 set of such LSPs (each PE in the MVPN being the root of one such 740 LSP), or as a single MP2MP LSP. 742 Procedures for sharing MP2MP LSPs across multiple MVPNs are 743 outside the scope of this document. 745 The use of MP2MP LSPs to instantiate S-PMSIs is outside the scope 746 of this document. 748 Section 11.2.3 discusses a way of using a partial mesh of MP2MP 749 LSPs to instantiate a PMSI. However, a full specification of the 750 necessary procedures is outside the scope of this document. 752 - RSVP-TE 754 A PMSI may be instantiated as one or more RSVP-TE Point-to- 755 Multipoint (P2MP) LSPs. An S-PMSI or a UI-PMSI would be 756 instantiated as a single RSVP-TE P2MP LSP, whereas a 757 Multidirectional Inclusive PMSI would be instantiated as a set of 758 such LSPs, one for each PE in the MVPN. RSVP-TE P2MP LSPs can be 759 shared across multiple MVPNs. 761 - A Mesh of Unicast P-Tunnels. 763 If a PMSI is implemented as a mesh of unicast P-tunnels, a PE 764 wishing to transmit a packet through the PMSI would replicate the 765 packet, and send a copy to each of the other PEs. 767 An MI-PMSI for a given MVPN can be instantiated as a full mesh of 768 unicast P-tunnels among that MVPN's PEs. A UI-PMSI or an S-PMSI 769 can be instantiated as a partial mesh. 771 It can be seen that each method of implementing PMSIs has its own 772 area of applicability. This specification therefore allows for the 773 use of any of these methods. At first glance, this may seem like an 774 overabundance of options. However, the history of multicast 775 development and deployment should make it clear that there is no one 776 option which is always acceptable. The use of segmented inter-AS 777 trees does allow each SP to select the option which it finds most 778 applicable in its own environment, without causing any other SP to 779 choose that same option. 781 SPECIFYING THE CONDITIONS UNDER WHICH A PARTICULAR TREE BUILDING 782 METHOD IS APPLICABLE IS OUTSIDE THE SCOPE OF THIS DOCUMENT. 784 The choice of the tunnel technique belongs to the sender router and 785 is a local policy decision of that router. The procedures defined 786 throughout this document do not mandate that the same tunnel 787 technique be used for all P-tunnels going through a given provider 788 backbone. It is however expected that any tunnel technique that can 789 be used by a PE for a particular MVPN is also supported by all the 790 other PEs having VRFs for the MVPN. Moreover, the use of ingress 791 replication by any PE for an MVPN, implies that all other PEs MUST 792 use ingress replication for this MVPN. 794 3.3. Use of PMSIs for Carrying Multicast Data 796 Each PE supporting a particular MVPN must have a way of discovering 797 the following information: 799 - The set of other PEs in its AS that are attached to sites of that 800 MVPN, and the set of other ASes that have PEs attached to sites 801 of that MVPN. However, if non-segmented inter-AS trees are used 802 (see section 8.1), then each PE needs to know the entire set of 803 PEs attached to sites of that MVPN. 805 - If segmented inter-AS trees are to be used, the set of border 806 routers in its AS that support inter-AS connectivity for that 807 MVPN 809 - If the MVPN is configured to use an MI-PMSI, the information 810 needed to set up and to use the P-tunnels instantiating the MI- 811 PMSI, 813 - For each other PE, whether the PE supports Aggregate Trees for 814 the MVPN, and if so, the demultiplexing information that must be 815 provided so that the other PE can determine whether a packet that 816 it received on an aggregate tree belongs to this MVPN. 818 In some cases the information above is provided by means of the BGP- 819 based auto-discovery procedures discussed in sections 4 and 6.1. In 820 other cases, this information is provided after discovery is 821 complete, by means of procedures discussed in sections 6.2 and 7.4. 822 In either case, the information that is provided must be sufficient 823 to enable the PMSI to be bound to the identified P-tunnel, to enable 824 the P-tunnel to be created if it does not already exist, and to 825 enable the different PMSIs that may travel on the same P-tunnel to be 826 properly demultiplexed. 828 If an MVPN uses an MI-PMSI, then the information needed to identify 829 the P-tunnels that instantiate the MI-PMSI has to be known to the PEs 830 attached to the MVPN before any data can be transmitted on the MI- 831 PMSI. This information is either statically configured or auto- 832 discovered (see section 4). The actual process of constructing the 833 P-tunnels (e.g., via PIM, RSVP-TE, or mLDP) SHOULD occur as soon as 834 this information is known. 836 When MI-PMSIs are used, they may serve as the default method of 837 carrying C-multicast data traffic. When we say that an MI-PMSI is 838 the "default" method of carrying C-multicast data traffic for a 839 particular MVPN, we mean that it is not necessary to use any special 840 control procedures to bind a particular C-flow to the MI-PMSI; any C- 841 flows that have not been bound to other PMSIs will be assumed to 842 travel through the MI-PMSI. 844 There is no requirement to use MI-PMSIs as the default method of 845 carrying C-flows. It is possible to adopt a policy in which all C- 846 flows are carried on UI-PMSIs or S-PMSIs. In this case, if an MI- 847 PMSI is not used for carrying routing information it is not needed at 848 all. 850 Even when an MI-PMSI is used as the default method of carrying an 851 MVPN's C-flows, if a particular C-flow has certain characteristics, 852 it may be desirable to migrate it from the MI-PMSI to an S-PMSI. 853 These characteristics, as well as the procedures for migrating a C- 854 flow from an MI-PMSI to an S-PMSI, are discussed in section 7. 856 Sometimes a set of C-flows are traveling the same, shared, C-tree 857 (e.g., either unidirectional or bidirectional), and it may be 858 desirable to move the whole set of C-flows as a unit to an S-PMSI. 859 Procedures for doing this are outside the scope of this 860 specification. 862 Some of the procedures for transmitting C-multicast routing 863 information among the PEs require that the routing information be 864 sent over an MI-PMSI. Other procedures do not use an MI-PMSI to 865 transmit the C-multicast routing information. 867 For a given MVPN, whether an MI-PMSI is used to carry C-multicast 868 routing information is independent from whether an MI-PMSI is used as 869 the default method of carrying the C-multicast data traffic. 871 As previously stated, it is possible to send all C-flows on a set of 872 S-PMSIs, omitting any usage of I-PMSIs. This prevents PEs from 873 receiving data that they don't need, at the cost of requiring 874 additional P-tunnels, and additional signaling to bind the C-flows to 875 P-tunnels. Cost-effective instantiation of S-PMSIs is likely to 876 require Aggregate P-trees, which in turn makes it necessary for the 877 transmitting PE to know which PEs need to receive which multicast 878 streams. This is known as "explicit tracking", and the procedures to 879 enable explicit tracking may themselves impose a cost. This is 880 further discussed in section 7.4.1.2. 882 3.4. PE-PE Transmission of C-Multicast Routing 884 As a PE attached to a given MVPN receives C-Join/Prune messages from 885 its CEs in that MVPN, it must convey the information contained in 886 those messages to other PEs that are attached to the same MVPN. 888 There are several different methods for doing this. As these methods 889 are not interoperable, the method to be used for a particular MVPN 890 must either be configured, or discovered as part of the auto- 891 discovery process. 893 3.4.1. PIM Peering 895 3.4.1.1. Full Per-MVPN PIM Peering Across a MI-PMSI 897 If the set of PEs attached to a given MVPN are connected via a MI- 898 PMSI, the PEs can form "normal" PIM adjacencies with each other. 899 Since the MI-PMSI functions as a broadcast network, the standard PIM 900 procedures for forming and maintaining adjacencies over a LAN can be 901 applied. 903 As a result, the C-Join/Prune messages that a PE receives from a CE 904 can be multicast to all the other PEs of the MVPN. PIM "join 905 suppression" can be enabled and the PEs can send Asserts as needed. 907 This procedure is fully specified in section 5.2. 909 3.4.1.2. Lightweight PIM Peering Across a MI-PMSI 911 The procedure of the previous section has the following 912 disadvantages: 914 - Periodic Hello messages must be sent by all PEs. 916 Standard PIM procedures require that each PE in a particular MVPN 917 periodically multicast a Hello to all the other PEs in that MVPN. 918 If the number of MVPNs becomes very large, sending and receiving 919 these Hellos can become a substantial overhead for the PE 920 routers. 922 - Periodic retransmission of C-Join/Prune messages. 924 PIM is a "soft-state" protocol, in which reliability is assured 925 through frequent retransmissions (refresh) of control messages. 926 This too can begin to impose a large overhead on the PE routers 927 as the number of MVPNs grows. 929 The first of these disadvantages is easily remedied. The reason for 930 the periodic PIM Hellos is to ensure that each PIM speaker on a LAN 931 knows who all the other PIM speakers on the LAN are. However, in the 932 context of MVPN, PEs in a given MVPN can learn the identities of all 933 the other PEs in the MVPN by means of the BGP-based auto-discovery 934 procedure of section 4. In that case, the periodic Hellos would 935 serve no function, and could simply be eliminated. (Of course, this 936 does imply a change to the standard PIM procedures.) 938 When Hellos are suppressed, we may speak of "lightweight PIM 939 peering". 941 The periodic refresh of the C-Join/Prunes is not as simple to 942 eliminate. If and when "refresh reduction" procedures are specified 943 for PIM, it may be useful to incorporate them, so as to make the 944 lightweight PIM peering procedures even more lightweight. 946 Lightweight PIM peering is not specified in this document. 948 3.4.1.3. Unicasting of PIM C-Join/Prune Messages 950 PIM does not require that the C-Join/Prune messages that a PE 951 receives from a CE to be multicast to all the other PEs; it allows 952 them to be unicast to a single PE, the one that is upstream on the 953 path to the root of the multicast tree mentioned in the Join/Prune 954 message. Note that when the C-Join/Prune messages are unicast, there 955 is no such thing as "join suppression". Therefore PIM Refresh 956 Reduction may be considered to be a pre-requisite for the procedure 957 of unicasting the C-Join/Prune messages. 959 When the C-Join/Prunes are unicast, they are not transmitted on a 960 PMSI at all. Note that the procedure of unicasting the C-Join/Prunes 961 is different than the procedure of transmitting the C-Join/Prunes on 962 an MI-PMSI that is instantiated as a mesh of unicast P-tunnels. 964 If there are multiple PEs that can be used to reach a given C-source, 965 procedures described in sections 5.1 and 9 MUST be used to ensure 966 that duplicate packets do not get delivered. 968 Procedures for unicasting the PIM control messages are not further 969 specified in this document. 971 3.4.2. Using BGP to Carry C-Multicast Routing 973 It is possible to use BGP to carry C-multicast routing information 974 from PE to PE, dispensing entirely with the transmission of C- 975 Join/Prune messages from PE to PE. This is specified in section 5.3. 976 Inter-AS procedures are described in section 8. 978 4. BGP-Based Autodiscovery of MVPN Membership 980 BGP-based autodiscovery is done by means of a new address family, the 981 MCAST-VPN address family. (This address family also has other uses, 982 as will be seen later.) Any PE that attaches to an MVPN must issue a 983 BGP update message containing an NLRI ("Network Layer Reachability 984 Information" element) in this address family, along with a specific 985 set of attributes. In this document, we specify the information that 986 must be contained in these BGP updates in order to provide auto- 987 discovery. The encoding details, along with the complete set of 988 detailed procedures, are specified in a separate document [MVPN-BGP]. 990 This section specifies the intra-AS BGP-based autodiscovery 991 procedures. When segmented inter-AS trees are used, additional 992 procedures are needed, as specified in section 8. Further detail may 993 be found in [MVPN-BGP]. (When segmented inter-AS trees are not used, 994 the inter-AS procedures are almost identical to the intra-AS 995 procedures.) 997 BGP-based autodiscovery uses a particular kind of MCAST-VPN route 998 known as an "auto-discovery routes", or "A-D route". In particular, 999 it uses two kinds of "A-D routes", the "Intra-AS I-PMSI A-D Route" 1000 and the "Inter-AS I-PMSI A-D Route". (There are also additional 1001 kinds of A-D routes, such as the Source Active A-D routes which are 1002 used for purposes that go beyond auto-discovery. These are discussed 1003 in subsequent sections.) 1005 The Inter-AS A-D Route is used only when segmented inter-AS P-tunnels 1006 are used, as specified in section 8. 1008 The "Intra-AS I-PMSI A-D route" is originated by the PEs that are 1009 (directly) connected to the site(s) of an MVPN. It is distributed to 1010 other PEs that attach to sites of the MVPN. If segmented Inter-AS P- 1011 Tunnels are used, then the Intra-AS I-PMSI A-D routes are not 1012 distributed outside the AS where they originate; if segmented Inter- 1013 AS P-Tunnels are not used, then the Intra-AS I-PMSI A-D routes are, 1014 despite their name, distributed to all PEs attached to the VPN, no 1015 matter what AS the PEs are in. 1017 The NLRI of an Intra-AS I-PMSI A-D route must contain the following 1018 information: 1020 - The route type (i.e., Intra-AS I-PMSI A-D route) 1022 - The IP address of the originating PE 1024 - An RD ("Route Distinguisher", [RFC4364]) configured locally for 1025 the MVPN. This is an RD that can be prepended to that IP address 1026 to form a globally unique VPN-IP address of the PE. 1028 Intra-AS I-PMSI A-D routes carry the following attributes: 1030 - Route Target Extended Communities attribute. 1032 One or more of these MUST be carried by each Intra-AS I-PMSI A-D 1033 route.If any other PE has one of these Route Targets configured 1034 for import into a VRF, it treats the advertising PE as a member 1035 in the MVPN to which the VRF belongs. This allows each PE to 1036 discover the PEs that belong to a given MVPN. More specifically 1037 it allows a PE in the Receiver Sites set to discover the PEs in 1038 the sender sites set of the MVPN and the PEs in the Sender Sites 1039 set of the MVPN to discover the PEs in the receiver sites set of 1040 the MVPN. The PEs in the Receiver Sites set would be configured 1041 to import the Route Targets advertised in the BGP Auto-Discovery 1042 routes by PEs in the Sender Sites set. The PEs in the sender 1043 sites set would be configured to import the Route Targets 1044 advertised in the BGP Auto-Discovery routes by PEs in the 1045 Receiver Sites set. 1047 - PMSI tunnel attribute. 1049 This attribute is present whenever the MVPN uses an MI-PMSI, or 1050 when it uses a UI-PMSI rooted at the originating router. It 1051 contains the following information: 1053 * tunnel technology, which may be one of the following: 1055 + Bidirectional multicast tree created by BIDIR-PIM, 1057 + Source-specific multicast tree crated by PIM-SM, 1058 supporting the SSM service model, 1060 + A set of trees (one shared tree and a set of source 1061 trees) PIM-SM, supporting the ASM service model, 1063 + Point-to-multipoint LSP created by RSVP-TE, 1065 + Point-to-multipoint LSP created by mLDP, 1067 + multipoint-to-multipoint LSP created by mLDP 1069 + unicast tunnel 1071 * P-tunnel identifier 1073 Before a P-tunnel can be constructed to instantiate the I- 1074 PMSI, the PE must be able to create a unique identifier for 1075 the tunnel. This syntax of this identifier depends on the 1076 tunnel technology used. 1078 Each PE attaching to a given MVPN must be configured with 1079 information specifying the allowable encapsulations to use 1080 for that MVPN, as well as the particular one of those 1081 encapsulations that the PE is to identify in the PMSI Tunnel 1082 Attribute of the I-PMSI Intra-AS A-D routes that it 1083 originates. 1085 * Multi-VPN aggregation capability and demultiplexor value. 1087 This specifies whether the P-tunnel is capable of aggregating 1088 I-PMSIs from multiple MVPNs. This will affect the 1089 encapsulation used. If aggregation is to be used, a 1090 demultiplexor value to be carried by packets for this 1091 particular MVPN must also be specified. The demultiplexing 1092 mechanism and signaling procedures are described in section 1093 6. 1095 - PE Distinguisher Labels Attribute 1097 Sometimes it is necessary for one PE to advertise an upstream- 1098 assigned MPLS label that identifies another PE. Under certain 1099 circumstances to be discussed later, a PE that is the root of a 1100 multicast P-tunnel will bind an MPLS label value to one or more 1101 of the PEs that belong to the P-tunnel, and will distribute these 1102 label bindings using Intra-AS I-PMSI A-D routes. Specification of 1103 when this must be done is provided in sections 6.4.4 and 11.2.2. 1104 We refer to these as "PE Distinguisher Labels". 1106 Note that, as specified in [MPLS-UPSTREAM-LABEL], PE 1107 Distinguisher Label values are are unique only in the context of 1108 the IP address identifying the root of the P-tunnel; they are not 1109 necessarily unique per tunnel. 1111 5. PE-PE Transmission of C-Multicast Routing 1113 As a PE attached to a given MVPN receives C-Join/Prune messages from 1114 its CEs in that MVPN, it must convey the information contained in 1115 those messages to other PEs that are attached to the same MVPN. This 1116 is known as the "PE-PE transmission of C-multicast routing 1117 information". 1119 This section specifies the procedures used for PE-PE transmission of 1120 C-multicast routing information. Not every procedure mentioned in 1121 section 3.4 is specified here. Rather, this section focuses on two 1122 particular procedures: 1124 - Full PIM Peering. 1126 This procedure is fully specified herein. 1128 - Use of BGP to distribute C-multicast routing 1130 This procedure is described herein, but the full specification 1131 appears in [MVPN-BGP]. 1133 Those aspects of the procedures that apply to both of the above are 1134 also specified fully herein. 1136 Specification of other procedures is outside the scope of this 1137 document. 1139 5.1. Selecting the Upstream Multicast Hop (UMH) 1141 When a PE receives a C-Join/Prune message from a CE, the message 1142 identifies a particular multicast flow as belonging either to a 1143 source-specific tree (S,G) or to a shared tree (*,G). Throughout 1144 this section, we use the term C-root to refer to S, in the case of a 1145 source-specific tree, or to the Rendezvous Point (RP) for G, in the 1146 case of (*,G). If the route to the C-root is across the VPN 1147 backbone, then the PE needs to find the "upstream multicast hop" 1148 (UMH) for the (S,G) or (*,G) flow. The "upstream multicast hop" is 1149 either the PE at which (S,G) or (*,G) data packets enter the VPN 1150 backbone, or else is the Autonomous System Border Router (ASBR) at 1151 which those data packets enter the local AS when traveling through 1152 the VPN backbone. The process of finding the upstream multicast hop 1153 for a given C-root is known as "upstream multicast hop selection". 1155 5.1.1. Eligible Routes for UMH Selection 1157 In the simplest case, the PE does the upstream hop selection by 1158 looking up the C-root in the unicast VRF associated with the PE-CE 1159 interface over which the C-Join/Prune was received. The route that 1160 matches the C-root will contain the information needed to select the 1161 upstream multicast hop. 1163 However, in some cases, the CEs may be distributing to the PEs a 1164 special set of routes that are to be used exclusively for the purpose 1165 of upstream multicast hop selection, and not used for unicast routing 1166 at all. For example, when BGP is the CE-PE unicast routing protocol, 1167 the CEs may be using SAFI 2 to distribute a special set of routes 1168 that are to be used for, and only for, upstream multicast hop 1169 selection. When OSPF [OSPF] is the CE-PE routing protocol, the CE 1170 may use an MT-ID ("Multi-Topology Identifier") [OSPF-MT]of 1 to 1171 distribute a special set of routes that are to be used for, and only 1172 for, upstream multicast hop selection . When a CE uses one of these 1173 mechanisms to distribute to a PE a special set of routes to be used 1174 exclusively for upstream multicast hop selection, these routes are 1175 distributed among the PEs using SAFI 129, as described in [MVPN-BGP]. 1177 Whether the routes used for upstream multicast hop selection are (a) 1178 the "ordinary" unicast routes or (b) a special set of routes that are 1179 used exclusively for upstream multicast hop selection, is a matter of 1180 policy. How that policy is chosen, deployed, or implemented is 1181 outside the scope of this document. In the following, we will simply 1182 refer to the set of routes that are used for upstream multicast hop 1183 selection, the "Eligible UMH routes", with no presumptions about the 1184 policy by which this set of routes was chosen. 1186 5.1.2. Information Carried by Eligible UMH Routes 1188 Every route that is eligible for UMH selection MUST carry a VRF Route 1189 Import Extended Community [MVPN-BGP]. This attribute identifies the 1190 PE that originated the route. 1192 If BGP is used for carrying C-multicast routes, OR if "Segmented 1193 Inter-AS Tunnels" (see section 8.2) are used, then every UMH route 1194 MUST also carry a Source AS Extended Community [MVPN-BGP]. 1196 These two attributes are used in the upstream multicast hop selection 1197 procedures described below. 1199 5.1.3. Selecting the Upstream PE 1201 The first step in selecting the upstream multicast hop for a given C- 1202 root is to select the upstream PE router for that C-root. 1204 The PE that received the C-Join message from a CE looks in the VRF 1205 corresponding to the interfaces over which the C-Join was received. 1206 It finds the Eligible UMH route that is the best match for the C-root 1207 specified in that C-Join. Call this the "Installed UMH Route". 1209 Note that the outgoing interface of the Installed UMH Route may be 1210 one of the interfaces associated with the VRF, in which case the 1211 upstream multicast hop is a CE and the route to the C-root is not 1212 across the VPN backbone. 1214 Consider the set of all VPN-IP routes that are: (a) eligible to be 1215 imported into the VRF (as determined by their Route Targets), (b) are 1216 eligible to be used for upstream multicast hop selection, and (c) 1217 have exactly the same IP prefix (not necessarily the same RD) as the 1218 installed UMH route. 1220 For each route in this set, determine the corresponding upstream PE 1221 and upstream RD. If a route has a VRF Route Import Extended 1222 Community, the route's upstream PE is determined from it. If a route 1223 does not have a VRF Route Import Extended Community, the route's 1224 upstream PE is determined from the route's BGP next hop attribute. 1225 In either case, the upstream RD is taken from the route's NLRI. 1227 This results in a set of pairs of . 1229 Call this the "UMH Route Candidate Set." Then the PE MUST select a 1230 single route from the set to be the "Selected UMH Route". The 1231 corresponding upstream PE is known as the "Selected Upstream PE", and 1232 the corresponding upstream RD is known as the "Selected Upstream RD". 1234 There are several possible procedures that can be used by a PE to 1235 select a single route from the candidate set. 1237 The default procedure, which MUST be implemented, is to select the 1238 route whose corresponding upstream PE address is numerically highest, 1239 where a 32-bit IP address is treated as a 32 bit unsigned integer. 1240 Call this the "default upstream PE selection". For a given C-root, 1241 provided that the routing information used to create the candidate 1242 set is stable, all PEs will have the same default upstream PE 1243 selection. (Though different default upstream PE selections may be 1244 chosen during a routing transient.) 1246 An alternative procedure that MUST be implemented, but which is 1247 disabled by default, is the following. This procedure ensures that, 1248 except during a routing transient, each PE chooses the same upstream 1249 PE for a given combination of C-root and C-G. 1251 1. The PEs in the candidate set are numbered from lower to higher 1252 IP address, starting from 0. 1254 2. The following hash is performed: 1256 - A bytewise exclusive-or of all the bytes in the C-root 1257 address and the C-G address is performed. 1259 - The result is taken modulo n, where n is the number of PEs 1260 in the candidate set. Call this result N. 1262 The selected upstream PE is then the one that appears in position N 1263 in the list of step 1. 1265 Other hashing algorithms are allowed as well, but not required. 1267 The alternative procedure allows a form of "equal cost load 1268 balancing". Suppose, for example, that from egress PEs PE3 and PE4, 1269 source C-S can be reached, at equal cost, via ingress PE PE1 or 1270 ingress PE PE2. The load balancing procedure makes it possible for 1271 PE1 to be the ingress PE for (C-S,C-G1) data traffic while PE2 is the 1272 ingress PE for (C-S,C-G2) data traffic. 1274 Another procedure, which SHOULD be implemented, is to use the 1275 Installed UMH Route as the Selected UMH Route. If this procedure is 1276 used, the result is likely to be that a given PE will choose the 1277 upstream PE that is closest to it, according to the routing in the SP 1278 backbone. As a result, for a given C-root, different PEs may choose 1279 different upstream PEs. This is useful if the C-root is an anycast 1280 address, and can also be useful if the C-root is in a multihomed site 1281 (i.e., a site that is attached to multiple PEs). However, this 1282 procedure is more likely to lead to steady state duplication of 1283 traffic unless (a) PEs discard data traffic that arrives from the 1284 "wrong" upstream PE, or (b) data traffic is carried only in non- 1285 aggregated S-PMSIs . This issue is discussed at length in section 9. 1287 General policy-based procedures for selecting the UMH route are 1288 allowed, but not required and are not further discussed in this 1289 specification. 1291 5.1.4. Selecting the Upstream Multicast Hop 1293 In certain cases, the selected upstream multicast hop is the same as 1294 the selected upstream PE. In other cases, the selected upstream 1295 multicast hop is the ASBR that is the "BGP next hop" of the Selected 1296 UMH Route. 1298 If the selected upstream PE is in the local AS, then the selected 1299 upstream PE is also the selected upstream multicast hop. This is the 1300 case if any of the following conditions holds: 1302 - The selected UMH route has a Source AS Extended Community, and 1303 the Source AS is the same as the local AS, 1305 - The selected UMH route does not have a Source AS Extended 1306 Community, but the route's BGP next hop is the same as the 1307 upstream PE. 1309 Otherwise, the selected upstream multicast hop is an ASBR. The 1310 method of determining just which ASBR it is depends on the particular 1311 inter-AS signaling method being used (PIM or BGP), and on whether 1312 segmented or non-segmented inter-AS tunnels are used. These details 1313 are presented in later sections. 1315 5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI 1317 When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat 1318 the MI-PMSI as a LAN interface, and form full PIM adjacencies with 1319 each other over that "LAN interface". 1321 The use of PIM when an MI-PMSI is not in use is outside the scope of 1322 this document. 1324 To form full PIM adjacencies, the PEs execute the standard PIM 1325 procedures on the "LAN interface", including the generation and 1326 processing of PIM Hello, Join/Prune, Assert, DF (Designated 1327 Forwarder) election, and other PIM control packets. These are 1328 executed independently for each C-instance. PIM "join suppression" 1329 SHOULD be enabled. 1331 5.2.1. PIM C-Instance Control Packets 1333 All PIM C-Instance control packets of a particular MVPN are addressed 1334 to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address, and 1335 transmitted over the MI-PMSI of that MVPN. While in transit in the 1336 P-network, the packets are encapsulated as required for the 1337 particular kind of P-tunnel that is being used to instantiate the MI- 1338 PMSI. Thus the C-instance control packets are not processed by the P 1339 routers, and MVPN-specific PIM routes can be extended from site to 1340 site without appearing in the P routers. 1342 As specified in section 5.1.2, when a PE distributes VPN-IP routes 1343 that are eligible for use as UMH routes, the PE MUST include a VRF 1344 Route Import Extended Community with each route. For a given MVPN, a 1345 single such IP address MUST be used, and that same IP address MUST be 1346 used as the source address in all PIM control packets for that MVPN. 1348 Note that BSR ("Bootstrap Router Mechanism for PIM") [BSR] messages 1349 are treated the same as PIM C-instance control packets, and BSR 1350 processing is regarded as a integral part of the PIM C-instance 1351 processing. 1353 5.2.2. PIM C-instance RPF Determination 1355 Although the MI-PMSI is treated by PIM as a LAN interface, unicast 1356 routing is NOT run over it, and there are no unicast routing 1357 adjacencies over it. It is therefore necessary to specify special 1358 procedures for determining when the MI-PMSI is to be regarded as the 1359 "RPF Interface" for a particular C-address. 1361 The PE follows the procedures of section 5.1 to determine the 1362 selected UMH route. If that route is NOT a VPN-IP route learned from 1363 BGP as described in [RFC4364], or if that route's outgoing interface 1364 is one of the interfaces associated with the VRF, then ordinary PIM 1365 procedures for determining the RPF interface apply. 1367 However, if the selected UMH route is a VPN-IP route whose outgoing 1368 interface is not one of the interfaces associated with the VRF, then 1369 PIM will consider the RPF interface to be the MI-PMSI associated with 1370 the VPN-specific PIM instance. 1372 Once PIM has determined that the RPF interface for a particular C- 1373 root is the MI-PMSI, it is necessary for PIM to determine the "RPF 1374 neighbor" for that C-root. This will be one of the other PEs that is 1375 a PIM adjacency over the MI-PMSI. In particular, it will be the 1376 "selected upstream PE" as defined in section 5.1. 1378 5.3. Use of BGP for Carrying C-Multicast Routing 1380 It is possible to use BGP to carry C-multicast routing information 1381 from PE to PE, dispensing entirely with the transmission of C- 1382 Join/Prune messages from PE to PE. This section describes the 1383 procedures for carrying intra-AS multicast routing information. 1384 Inter-AS procedures are described in section 8. The complete 1385 specification of both sets of procedures and of the encodings can be 1386 found in [MVPN-BGP]. 1388 5.3.1. Sending BGP Updates 1390 The MCAST-VPN address family is used for this purpose. MCAST-VPN 1391 routes used for the purpose of carrying C-multicast routing 1392 information are distinguished from those used for the purpose of 1393 carrying auto-discovery information by means of a "route type" field 1394 which is encoded into the NLRI. The following information is 1395 required in BGP to advertise the MVPN routing information. The NLRI 1396 contains: 1398 - The type of C-multicast route. 1400 There are two types: 1402 * source tree join 1404 * shared tree join 1406 - The C-Group address. 1408 - The C-Source address. (In the case of a shared tree join, this is 1409 the address of the C-RP.) 1411 - The Selected Upstream RD corresponding to the C-root address 1412 (determined by the procedures of section 5.1). 1414 Whenever a C-multicast route is sent, it must also carry the Selected 1415 Upstream Multicast Hop corresponding to the C-root address 1416 (determined by the procedures of section 5.1). The selected upstream 1417 multicast hop must be encoded as part of a Route Target Extended 1418 Community, to facilitate the optional use of filters which can 1419 prevent the distribution of the update to BGP speakers other than the 1420 upstream multicast hop. See section 10.1.3 of [MVPN-BGP] for the 1421 details. 1423 There is no C-multicast route corresponding to the PIM function of 1424 pruning a source off the shared tree when a PE switches from a tree to a tree. Section 9 of this document specifies 1426 a mandatory procedure that ensures that if any PE joins a 1427 source tree, all other PEs that have joined or will join the shared tree will also join the source tree. This 1429 eliminates the need for a C-multicast route that prunes C-S off the 1430 shared tree when switching from to 1431 tree. 1433 5.3.2. Explicit Tracking 1435 Note that the upstream multicast hop is NOT part of the NLRI in the 1436 C-multicast BGP routes. This means that if several PEs join the same 1437 C-tree, the BGP routes they distribute to do so are regarded by BGP 1438 as comparable routes, and only one will be installed. If a route 1439 reflector is being used, this further means that the PE that is used 1440 to reach the C-source will know only that one or more of the other 1441 PEs have joined the tree, but it won't know which one. That is, this 1442 BGP update mechanism does not provide "explicit tracking". Explicit 1443 tracking is not provided by default because it increases the amount 1444 of state needed and thus decreases scalability. Also, as 1445 constructing the C-PIM messages to send "upstream" for a given tree 1446 does not depend on knowing all the PEs that are downstream on that 1447 tree, there is no reason for the C-multicast route type updates to 1448 provide explicit tracking. 1450 There are some cases in which explicit tracking is necessary in order 1451 for the PEs to set up certain kinds of P-trees. There are other 1452 cases in which explicit tracking is desirable in order to determine 1453 how to optimally aggregate multicast flows onto a given aggregate 1454 tree. As these functions have to do with the setting up of 1455 infrastructure in the P-network, rather than with the dissemination 1456 of C-multicast routing information, any explicit tracking that is 1457 necessary is handled by sending a particular type of A-D route known 1458 as "Leaf A-D routes". 1460 Whenever a PE sends an A-D route with a PMSI Tunnel attribute, it can 1461 set a bit in the PMSI Tunnel attribute indicating "Leaf Information 1462 Required". A PE that installs such an A-D route MUST respond by 1463 generating a a Leaf A-D route, indicating that it needs to join (or 1464 be joined to) the specified PMSI tunnel. Details can be found in 1465 [MVPN-BGP]. 1467 5.3.3. Withdrawing BGP Updates 1469 A PE removes itself from a C-multicast tree (shared or source) by 1470 withdrawing the corresponding BGP update. 1472 If a PE has pruned a C-source from a shared C-multicast tree, and it 1473 needs to "unprune" that source from that tree, it does so by 1474 withdrawing the route that pruned the source from the tree. 1476 5.3.4. BSR 1478 BGP does not provide a method for carrying the control information of 1479 BSR packets received by a PE from a CE. BSR is supported by 1480 transmitting the BSR control messages from one PE in an MVPN to all 1481 the other PEs in that MVPN. 1483 When a PE needs to transmit a BSR message for a particular MVPN to 1484 other PEs, it must put its own IP address into the BSR message as the 1485 IP source address. As specified in section 5.1.2, when a PE 1486 distributes VPN-IP routes that are eligible for use as UMH routes, 1487 the PE MUST include a VRF Route Import Extended Community with each 1488 route. For a given MVPN, a single such IP address MUST be used, and 1489 that same IP address MUST be used as the source address in all BSR 1490 packets that the PE transmits to other PEs. 1492 The BSR message may be transmitted over any PMSI that will deliver 1493 the message to all the other PEs in the MVPN. If no such PMSI has 1494 been instantiated yet, then an appropriate P-tunnel must be 1495 advertised, and the C-flow whose C-source address is the address of 1496 the PE itself, and whose multicast group is ALL-PIM-ROUTERS 1497 (224.0.0.13), must be bound to it. This can be done using the 1498 procedures described in sections 7.3 and 7.4. Note that this is NOT 1499 meant to imply that the other PIM control packets from the PIM C- 1500 instance are to be transmitted to the other PEs. 1502 When a PE receives a BSR message for a particular MVPN over from some 1503 other PE, the PE accepts the message only if the IP source address in 1504 that message is the selected upstream PE (see section 5.1.3) for the 1505 IP address of the Bootstrap router. Otherwise the PE simply discards 1506 the packet. If the PE accepts the packet, it does normal BSR 1507 processing on it, and may forward a BSR message to one or more CEs as 1508 a result. 1510 6. PMSI Instantiation 1512 This section provides the procedures for using P-tunnels to 1513 instantiate a PMSI. It describes the procedures for setting up and 1514 maintaining the P-tunnels, as well as for sending and receiving C- 1515 data and/or C-control messages on the P-tunnels. Procedures for 1516 binding particular C-flows to particular P-tunnels are however 1517 discussed in section 7. 1519 PMSIs can be instantiated either by P-multicast trees or by PE-PE 1520 unicast tunnels. In the latter case, the PMSI is said to be 1521 instantiated by "ingress replication." 1523 This specification supports a number of different methods for setting 1524 up P-multicast trees, and these are detailed below. A P-tunnel may 1525 support a single VPN (a non-aggregated P-multicast tree), or multiple 1526 VPNs (an aggregated P-multicast tree). 1528 6.1. Use of the Intra-AS I-PMSI A-D Route 1530 6.1.1. Sending Intra-AS I-PMSI A-D Routes 1532 When a PE is provisioned to have one or more VRFs that provide MVPN 1533 support, the PE announces its MVPN membership information using 1534 Intra-AS I-PMSI A-D routes, as discussed in section 4 and detailed in 1535 section 9.1.1 of [MVPN-BGP]. (Under certain conditions, detailed in 1536 [MVPN-BGP], the Intra-AS I-PMSI A-D route may be omitted.) 1538 Generally, the Intra-AS I-PMSI A-D route will have a PMSI Tunnel 1539 Attribute that identifies a P-tunnel that is being used to 1540 instantiate the I-PMSI. Section 9.1.1 of [MVPN-BGP] details certain 1541 conditions under which the PMSI Tunnel Attribute may be omitted (or 1542 in which a PMSI Tunnel Attribute with the "no tunnel information 1543 present" bit may be sent). 1545 As a special case, when (a) C-PIM control messages are to be sent 1546 through an MI-PMSI, and (b) the MI-PMSI is instantiated by a P-tunnel 1547 technique for which each PE needs to know only a single P-tunnel 1548 identifier per VPN, then the use of the Intra-As I-PMSI A-D Routes 1549 MAY be omitted, and static configuration of the tunnel identifier 1550 used instead. However, this is not recommended for long-term use, 1551 and in all other cases, the Intra-AS A-D routes MUST be used. 1553 The PMSI tunnel attribute MAY contain an upstream-assigned MPLS 1554 label, assigned by the PE originating the Intra-AS I-PMSI A-D route. 1555 If this label is present, the P-tunnel can be carrying data from 1556 several MVPNs. The label is used on the data packets traveling 1557 through the tunnel to identify the MVPN to those data packets belong. 1558 (The specified label identifies the packet as belonging to the MVPN 1559 that is identified by the RTs of the Intra-AS I-PMSI A-D route.) 1561 See section 12.2 for details on how to place the label in the 1562 packet's label stack. 1564 The Intra-AS I-PMSI A-D Route may contain a "PE Distinguisher Labels" 1565 Attribute. This contains a set of bindings between upstream-assigned 1566 labels and PE addresses. The PE that originated the route may use 1567 this to bind an upstream-assigned label to one or more of the other 1568 PEs that belong to the same MVPN. The way in which PE Distinguisher 1569 Labels are used is discussed in sections 6.4.1, 6.4.2, 6.4.4, 11.2.2, 1570 and 12.3. 1572 6.1.2. Receiving Intra-AS I-PMSI A-D Routes 1574 When a PE receives an Intra-AS I-PMSI A-D route for a particular MVPN 1575 depends on the particular P-tunnel technology that is being used by 1576 that MVPN. If the PE tunnel technology requires tunnels to be build 1577 by means of receiver-initiated joins, the PE SHOULD join the tunnel 1578 immediately. 1580 6.2. When C-flows are Specifically Bound to P-Tunnels 1582 Section 7 specifies procedures that may be used to bind specific C- 1583 flows (specified as (C-S,C-G)) to specific P-tunnels, either through 1584 the use of S-PMSI A-D routes or a UDP-based control procedure. In 1585 either case, when a PE, say PE1, receives a control message binding a 1586 particular C-flow to a particular P-tunnel, which another PE, say 1587 PE2, uses to transmit data of that C-flow, then PE1 MUST determine 1588 whether it needs to receive the data of the specified C-flow over the 1589 specified S-PMSI. This is the case if and only if either of the 1590 following two conditions holds: 1592 1. PE1 has (C-S,C-G) state for the specified C-flow, PE2 is PE1's 1593 selected upstream PE for that C-flow, and PE1 has a VRF 1594 interface which is an output interface for (C-S, C-G), or 1596 2. PE1 has only (*, C-G) state for the specified C-flow, and the 1597 best Source Active A-D route for (C-S, C-G) (as determined by 1598 the BGP route selection procedures) is originated by the same 1599 PE as the one that originates the S-PMSI A-D route, and PE1 has 1600 a VRF interface which is an output interface for (*, C-G). 1602 If PE1 determines that it needs to receive data of the specified C- 1603 flow over the specified S-PMSI, then PE1 MUST immediately take any 1604 action necessary for it to be able to receive data on that P-tunnel. 1605 PE1 may be removed from that P-tunnel at a later time, if it PE1 no 1606 longer needs to receive any C-data that is being sent on that P- 1607 tunnel. General procedures for moving C-data from one P-tunnel to 1608 another are given in section 7.1. 1610 Note that a PE that is already receiving data on a particular P- 1611 tunnel may receive a control message telling it to bind a particular 1612 C-flow to that P-tunnel. In this case, the PE may need to modify its 1613 forwarding data structures so that it can receive that C-flow on that 1614 P-tunnel, but it will not need to engage in any signaling to join the 1615 P-tunnel. 1617 It may sometimes be desirable to bind the entire set of flows 1618 traveling along a specific C-tree (i.e., a set of flows designated as 1619 C-(*,G)) to a specific P-tunnel. Procedures to do so without 1620 mentioning each C-(S,G) flow individually are outside the scope of 1621 this document. 1623 6.3. Aggregating Multiple MVPNs on a Single P-tunnel 1625 When a P-multicast tree is shared across multiple MVPNs it is termed 1626 an "Aggregate Tree". The procedures described in this document allow 1627 a single SP multicast tree to be shared across multiple MVPNs. Unless 1628 otherwise specified a P-multicast tree technology supports 1629 aggregation. 1631 All procedures that are specific to multi-MVPN aggregation are 1632 OPTIONAL and are explicitly pointed out. 1634 Aggregate Trees allow a single P-multicast tree to be used across 1635 multiple MVPNs, so that state in the SP core grows per-set-of-MVPNs 1636 and not per MVPN. Depending on the congruence of the aggregated 1637 MVPNs, this may result in trading off optimality of multicast 1638 routing. 1640 An Aggregate Tree can be used by a PE to provide an UI-PMSI or MI- 1641 PMSI service for more than one MVPN. When this is the case the 1642 Aggregate Tree is said to have an inclusive mapping. 1644 6.3.1. Aggregate Tree Leaf Discovery 1646 BGP MVPN membership discovery (section 4) allows a PE to determine 1647 the different Aggregate Trees that it should create and the MVPNs 1648 that should be mapped onto each such tree. The leaves of an Aggregate 1649 Tree are determined by the PEs, supporting aggregation, that belong 1650 to all the MVPNs that are mapped onto the tree. 1652 If an Aggregate Tree is used to instantiate one or more S-PMSIs, then 1653 it may be desirable for the PE at the root of the tree to know which 1654 PEs (in its MVPN) are receivers on that tree. This enables the PE to 1655 decide when to aggregate two S-PMSIs, based on congruence (as 1656 discussed in the next section). Thus explicit tracking may be 1657 required. Since the procedures for disseminating C-multicast routes 1658 do not provide explicit tracking, a type of A-D route known as a 1659 "Leaf A-D Route" is used. The PE that wants to assign a particular 1660 C-multicast flow to a particular Aggregate Tree can send an A-D route 1661 which elicits Leaf A-D routes from the PEs that need to receive that 1662 C-multicast flow. This provides the explicit tracking information 1663 needed to support the aggregation methodology discussed in the next 1664 section. For more details on Leaf A-D routes please refer to [MVPN- 1665 BGP]. 1667 6.3.2. Aggregation Methodology 1669 This document does not specify the mandatory implementation of any 1670 particular set of rules for determining whether or not the PMSIs of 1671 two particular MVPNs are to be instantiated by the same Aggregate 1672 Tree. This determination can be made by implementation-specific 1673 heuristics, by configuration, or even perhaps by the use of offline 1674 tools. 1676 It is the intention of this document that the control procedures will 1677 always result in all the PEs of an MVPN to agree on the PMSIs which 1678 are to be used and on the tunnels used to instantiate those PMSIs. 1680 This section discusses potential methodologies with respect to 1681 aggregation. 1683 The "congruence" of aggregation is defined by the amount of overlap 1684 in the leaves of the customer trees that are aggregated on a SP tree. 1685 For Aggregate Trees with an inclusive mapping the congruence depends 1686 on the overlap in the membership of the MVPNs that are aggregated on 1687 the tree. If there is complete overlap i.e. all MVPNs have exactly 1688 the same sites, aggregation is perfectly congruent. As the overlap 1689 between the MVPNs that are aggregated reduces, i.e. the number of 1690 sites that are common across all the MVPNs reduces, the congruence 1691 reduces. 1693 If aggregation is done such that it is not perfectly congruent a PE 1694 may receive traffic for MVPNs to which it doesn't belong. As the 1695 amount of multicast traffic in these unwanted MVPNs increases 1696 aggregation becomes less optimal with respect to delivered traffic. 1697 Hence there is a tradeoff between reducing state and delivering 1698 unwanted traffic. 1700 An implementation should provide knobs to control the congruence of 1701 aggregation. These knobs are implementation dependent. Configuring 1702 the percentage of sites that MVPNs must have in common to be 1703 aggregated, is an example of such a knob. This will allow a SP to 1704 deploy aggregation depending on the MVPN membership and traffic 1705 profiles in its network. If different PEs or servers are setting up 1706 Aggregate Trees this will also allow a service provider to engineer 1707 the maximum amount of unwanted MVPNs hat a particular PE may receive 1708 traffic for. 1710 6.3.3. Demultiplexing C-multicast traffic 1712 If a P-multicast tree is associated with only one MVPN, determining 1713 the P-multicast tree on which a packet was received is sufficient to 1714 determine the packet's MVPN. All that the egress PE needs to know is 1715 the MVPN the P-multicast tree is associated with. 1717 When multiple MVPNs are aggregated onto one P-Multicast tree, 1718 determining the tree over which the packet is received is not 1719 sufficient to determine the MVPN to which the packet belongs. The 1720 packet must also carry some demultiplexing information to allow the 1721 egress PEs to determine the MVPN to which the packet belongs. Since 1722 the packet has been multicast through the P network, any given 1723 demultiplexing value must have the same meaning to all the egress 1724 PEs. The demultiplexing value is a MPLS label that corresponds to 1725 the multicast VRF to which the packet belongs. This label is placed 1726 by the ingress PE immediately beneath the P-Multicast tree header. 1727 Each of the egress PEs must be able to associate this MPLS label with 1728 the same MVPN. If downstream label assignment were used this would 1729 require all the egress PEs in the MVPN to agree on a common label for 1730 the MVPN. Instead the MPLS label is upstream assigned [MPLS-UPSTREAM- 1731 LABEL]. The label bindings are advertised via BGP updates originated 1732 the ingress PEs. 1734 This procedure requires each egress PE to support a separate label 1735 space for every other PE. The egress PEs create a forwarding entry 1736 for the upstream assigned MPLS label, allocated by the ingress PE, in 1737 this label space. Hence when the egress PE receives a packet over an 1738 Aggregate Tree, it first determines the tree that the packet was 1739 received over. The tree identifier determines the label space in 1740 which the upstream assigned MPLS label lookup has to be performed. 1741 The same label space may be used for all P-multicast trees rooted at 1742 the same ingress PE, or an implementation may decide to use a 1743 separate label space for every P-multicast tree. 1745 A full specification of the procedures to support aggregation on 1746 shared trees or on MP2MP LSPs is outside the scope of this document. 1748 The encapsulation format is either MPLS or MPLS-in-something (e.g. 1749 MPLS-in-GRE [MPLS-IP]). When MPLS is used, this label will appear 1750 immediately below the label that identifies the P-multicast tree. 1751 When MPLS-in-GRE is used, this label will be the top MPLS label that 1752 appears when the GRE header is stripped off. 1754 When IP encapsulation is used for the P-multicast Tree, whatever 1755 information that particular encapsulation format uses for identifying 1756 a particular tunnel is used to determine the label space in which the 1757 MPLS label is looked up. 1759 If the P-multicast tree uses MPLS encapsulation, the P-multicast tree 1760 is itself identified by an MPLS label. The egress PE MUST NOT 1761 advertise IMPLICIT NULL or EXPLICIT NULL for that tree. Once the 1762 label representing the tree is popped off the MPLS label stack, the 1763 next label is the demultiplexing information that allows the proper 1764 MVPN to be determined. 1766 This specification requires that, to support this sort of 1767 aggregation, there be at least one upstream-assigned label per MVPN. 1768 It does not require that there be only one. For example, an ingress 1769 PE could assign a unique label to each C-(S,G). (This could be done 1770 using the same technique this is used to assign a particular C-(S,G) 1771 to an S-PMSI, see section 7.4.) 1773 When an egress PE receives a C-multicast data packet over a P- 1774 multicast tree, it needs to forward the packet to the CEs that have 1775 receivers in the packet's C-multicast group. In order to do this the 1776 egress PE needs to determine the P-tunnel on which the packet was 1777 received. The PE can then determine the MVPN that the packet belongs 1778 to and if needed do any further lookups that are needed to forward 1779 the packet. 1781 . 1783 6.4. Considerations for Specific Tunnel Technologies 1785 While it is believed that the architecture specified in this document 1786 places no limitations on the protocols used for setting up and 1787 maintaining P-tunnels, the only protocols that have been explicitly 1788 considered are PIM-SM (both the SSM and ASM service models are 1789 considered, as are bidirectional trees), RSVP-TE, mLDP, and BGP. 1790 (BGP's role in the setup and maintenance of P-tunnels is to "stitch" 1791 together the Intra-AS segments of a segmented Inter-AS P-tunnel.) 1793 6.4.1. RSVP-TE P2MP LSPs 1795 If an I-PMSI is to be instantiated as one or more non-segmented P- 1796 tunnels, where the P-tunnels are RSVP-TE P2MP LSPs, then only the PEs 1797 which are at the head ends of those LSPs will ever include the PMSI 1798 Tunnel attribute in their Intra-AS I-PMSI A-D routes. (These will be 1799 the PEs in the "Sender Sites set".) 1801 If an I-PMSI is to be instantiated as one or more segmented P- 1802 tunnels, where some of the Intra-AS segments of these tunnels are 1803 RSVP-TE P2MP LSPs, then only a PE or ASBR which is at the head end of 1804 one of these LSPs will ever include the PMSI Tunnel attribute in its 1805 Inter-AS I-PMSI A-D route. 1807 Other PEs send Intra-AS I-PMSI A-D routes without PMSI Tunnel 1808 attributes. (These will be the PEs that are in the "Receiver Sites" 1809 but not in the "Sender Sites set".) As each "Sender Site" PE 1810 receives an Intra-AS I-PMSI A-D route from a PE in the Receiver Sites 1811 set, it adds the PE originating that Intra-AS I-PMSI A-D route to the 1812 set of receiving PEs for the P2MP LSP. The PE at the headend MUST 1813 then use RSVP-TE [RSVP-P2MP] signaling to add the receiver PEs to the 1814 P-tunnel. 1816 When RSVP-TE P2MP LSPs are used to instantiate S-PMSIs, and a 1817 particular C-flow is to be bound to the LSP, it is necessary to use 1818 explicit tracking so that the head end of the LSP knows which PEs 1819 need to receive data from the specified C-flow. If the binding is 1820 done using S-PMSI A-D routes (see section 7.4.1), the "Leaf 1821 Information Required" bit MUST be set in the PMSI Tunnel attribute. 1823 RSVP-TE P2MP LSPs can optionally support aggregation of multiple 1824 MVPNs. 1826 If an RSVP-TE P2MP TE LSP Tunnel is used for only a single MVPN, the 1827 mapping between the LSP and the MVPN can either be configured, or can 1828 be deduced from the procedures used to announce the LSP (e.g., from 1829 the RTs in the A-D route that announced the LSP). If the LSP is used 1830 for multiple MVPNs, the set of MVPNs using it (and the corresponding 1831 MPLS labels) are inferred from the PMSI tunnel attributes that 1832 specify the LSP. 1834 If an RSVP-TE P2MP LSP is being used to carry a set of C-flows 1835 traveling along a bidirectional C-Tree, using the procedures of 1836 section 11.2, the head end MUST include the PE Distinguisher Labels 1837 attribute in its I-PMSI Intra-AS A-D route or S-PMSI A-D route, and 1838 MUST provide an upstream-assigned label for each PE that it has 1839 selected as the upstream PE for the C-tree's RPA ("Rendezvous Point 1840 Address"). See section 11.2 for details. 1842 A PMSI Tunnel attribute specifying an RSVP-TE P2MP LSP contains the 1843 following information: 1844 - The type of the tunnel is set to RSVP-TE P2MP Tunnel 1846 - RSVP-TE P2MP Tunnel's SESSION Object 1848 - Optionally RSVP-TE P2MP LSP's SENDER_TEMPLATE Object. This object 1849 is included when it is desired to identify a particular P2MP TE 1850 LSP. 1852 Demultiplexing the C-multicast data packets at the egress PE follows 1853 procedures described in section 6.3.3. As specified in section 6.3.3 1854 an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for a 1855 RSVP-TE P2MP LSP that is carrying traffic for one or more MVPNs. 1857 If (and only if) a particular RSVP-TE P2MP LSP is possibly carrying 1858 data from multiple MVPNs, the following special procedures apply: 1860 - A packet in a particular MVPN, when transmitted into the LSP, 1861 must carry the MPLS label specified in the PMSI tunnel attribute 1862 that announced that LSP as a P-tunnel for that for that MVPN. 1864 - Demultiplexing the C-multicast data packets at the egress PE is 1865 done by means of the MPLS label that rises to the top of the 1866 stack after the corresponding to the P2MP LSP is popped off. 1868 It is possible that at the time a PE learns, via an A-D route with a 1869 PMSI Tunnel attribute, that it needs to receive traffic on a 1870 particular RSVP-TE P2MP LSP, the signaling to set up the LSP will not 1871 have been completed. In this case, the PE needs to wait for the 1872 RSVP-TE signaling to take place before it can modify its forwarding 1873 tables as directed by the A-D route. 1875 It is also possible that the signaling to set up an RSVP-TE P2MP LSP 1876 will be completed before a given PE learns, via a PMSI Tunnel 1877 attribute, of the use to which that LSP will be put. The PE MUST 1878 discard any traffic received on that LSP until that time. 1880 In order for the egress PE to be able to discard such traffic it 1881 needs to know that the LSP is associated with an MVPN and that the A- 1882 D route that binds the LSP to an MVPN or to a particular a C-flow has 1883 not yet been received. This is provided by extending [RSVP-P2MP] 1884 with [RSVP-OOB]. 1886 6.4.2. PIM Trees 1888 When the P-tunnels are PIM trees, the PMSI Tunnel attribute contains 1889 enough information to allow each other PE in the same MVPN to use P- 1890 PIM signaling to join the P-tunnel. 1892 If an I-PMSI is to be instantiated as one or more PIM trees, then the 1893 PE that is at the root of a given PIM tree sends an Intra-AS I-PMSI 1894 A-D route containing a PMSI Tunnel attribute that contains all the 1895 information needed for other PEs to join the tree. 1897 If PIM trees are to be used to instantiate an MI-PMSI, each PE in the 1898 MVPN must send an Intra-AS I-PMSI A-D route containing such a PMSI 1899 Tunnel attribute. 1901 If a PMSI is to be instantiated via a shared tree, the PMSI Tunnel 1902 attribute identifies the a P-group address. The RP or RPA 1903 corresponding to the P-group address is not specified. It must of 1904 course be known to all the PEs. It is presupposed that the PEs use 1905 one of the methods for automatically learning the RP-to-group 1906 correspondences (e.g., Bootstrap Router Protocol [BSR]), or else that 1907 the correspondence are configured. 1909 If a PMSI is to be instantiated via a source-specific tree, the PMSI 1910 Tunnel attribute identifies the PE router that is the root of the 1911 tree, as well as a P-group address. The PMSI Tunnel attribute always 1912 specifies whether the PIM tree is to be a unidirectional shared tree, 1913 a bidirectional shared tree, or a source-specific tree. 1915 If PIM trees are being used to instantiate S-PMSIs, the above 1916 procedures assume that each PE router has a set of group P-addresses 1917 that it can use for setting up the PIM-trees. Each PE must be 1918 configured with this set of P-addresses. If the P-tunnels are 1919 source-specific trees, then the PEs may be configured with 1920 overlapping sets of group P-addresses. If the trees are not source- 1921 specific, then each PE must be configured with a unique set of group 1922 P-addresses (i.e., having no overlap with the set configured at any 1923 other PE router). The management of this set of addresses is thus 1924 greatly simplified when source-specific trees are used, so the use of 1925 source-specific trees is strongly recommended whenever unidirectional 1926 trees are desired. 1928 Specification of the full set of procedures for using bidirectional 1929 PIM trees to instantiate S-PMSIs are outside the scope of this 1930 document. 1932 Details for constructing the PMSI Tunnel Attribute identifying a PIM 1933 tree can be found in [MVPN-BGP]. 1935 6.4.3. mLDP P2MP LSPs 1937 When the P-tunnels are mLDP P2MP trees, each Intra-AS I-PMSI A-D 1938 route has a PMSI Tunnel attribute containing enough information to 1939 allow each other PE in the same MVPN to use mLDP signaling to join 1940 the P-tunnel. The tunnel identifier consists of the root node 1941 address, along with the Generic LSP Identifier value. 1943 An mLDP P2MP LSP may be used to carry traffic of multiple VPNs, if 1944 the PMSI Tunnel Attribute specifying it contains a non-zero MPLS 1945 label. 1947 If an mLDP P2MP LSP is being used to carry a the set of flows 1948 traveling along a particular bidirectional C-tree, using the 1949 procedures of section 11.2, the root of the LSP MUST include the PE 1950 Distinguisher Labels attribute in its I-PMSI Intra-AS A-D route or S- 1951 PMSI A-D route, and MUST provide an upstream-assigned label for the 1952 PE that it has selected the upstream PE for the C-tree's RPA. See 1953 section 11.2 for details. 1955 6.4.4. mLDP MP2MP LSPs 1957 The procedures for assigning C-flows to mLDP MP2MP LSPs that serve as 1958 P-tunnels is outside the scope of this document. 1960 6.4.5. Ingress Replication 1962 As described in section 3, a PMSI can be instantiated using Unicast 1963 Tunnels between the PEs that are participating in the MVPN. In this 1964 mechanism the ingress PE replicates a C-multicast data packet 1965 belonging to a particular MVPN and sends a copy to all or a subset of 1966 the PEs that belong to the MVPN. A copy of the packet is tunneled to 1967 a remote PE over an Unicast Tunnel to the remote PE. IP/GRE Tunnels 1968 or MPLS LSPs are examples of unicast tunnels that may be used. The 1969 same Unicast Tunnel can be used to transport packets belonging to 1970 different MVPNs 1972 In order for a PE to use Unicast P-Tunnels to send a C-multicast data 1973 packet for a particular MVPN to a set of remote PEs, the remote PEs 1974 must be able to correctly decapsulate such packets and to assign each 1975 one to the proper MVPN. This requires that the encapsulation used for 1976 sending packets through the P-tunnel have demultiplexing information 1977 which the receiver can associate with a particular MVPN. 1979 If ingress replication is being used to instantiate the PMSIs for an 1980 MVPN, the PEs announce this as part of the BGP based MVPN membership 1981 auto-discovery process, described in section 4. The PMSI tunnel 1982 attribute specifies ingress replication, and also specifies a 1983 downstream-assigned MPLS label. This label will be used to identify 1984 that a particular packet belongs to the MVPN that the Intra-AS I-PMSI 1985 A-D route belongs to (as inferred from its RTs.) If PE1 specifies a 1986 particular label value for a particular MVPN, then any other PE 1987 sending PE1 a packet for that MVPN through a unicast P-tunnel must 1988 put that label on the packet's label stack. PE1 then treats that 1989 label as the demultiplexor value identifying the MVPN in question. 1991 Ingress replication may be used to instantiate any kind of PMSI. 1992 When ingress replication is done, it is RECOMMENDED, except in the 1993 one particular case mentioned in the next paragraph, that explicit 1994 tracking be done, and that the data packets of a particular C-flow 1995 only get sent to those PEs that need to see the packets of that C- 1996 flow. There is never any need to use the procedures of section 7.4 1997 for binding particular C-flows to particular P-tunnels. 1999 The particular case in which there is no need for explicit tracking 2000 is the case where ingress replication is being used to create a one- 2001 hop ASBR-ASBR Inter-AS segment of an segmented Inter-AS P-tunnel. 2003 7. Binding Specific C-flows to Specific P-Tunnels 2005 As discussed previously, Intra-AS I-PMSI A-D routes may (or may not) 2006 have PMSI tunnel attributes, identifying P-tunnels that can be used 2007 as the default P-tunnels for carrying C-multicast traffic, i.e,. for 2008 carrying C-multicast traffic that has not been specifically bound to 2009 another P-tunnel. 2011 If none of the Intra-AS I-PMSI A-D routes originated by a particular 2012 PE for a particular MVPN carry PMSI tunnel attributes at all (or if 2013 the only PMSI tunnel attributes they carry have type "No tunnel 2014 information present"), then there are no default P-tunnels for that 2015 PE to use when transmitting C-multicast traffic in that MVPN to other 2016 PEs. In that case, all such C-flows must be assigned to specific P- 2017 tunnels using one of the mechanisms specified in section 7.4. That 2018 is, all such C-flows are carried on P-tunnels that instantiate S- 2019 PMSIs. 2021 There are other cases where it may be either necessary or desirable 2022 to use the mechanisms of section 7.4 to identify specific C-flows and 2023 bind them to or unbind them from specific P-tunnels. Some possible 2024 cases are: 2026 - The policy for a particular MVPN is to send all C-data on S- 2027 PMSIs, even if the Intra-AS I-PMSI A-D routes carry PMSI tunnel 2028 attributes. (This is another case where all C-data is carried on 2029 S-PMSIs; presumably the I-PMSIs are used for control 2030 information.) 2032 - It is desired to optimize the routing of the particular C-flow, 2033 which may already be traveling on an I-PMSI, by sending it 2034 instead on an S-PMSI. 2036 - If a particular C-flow is traveling on an S-PMSI, it may be 2037 considered desirable to move it to an I-PMSI (i.e., optimization 2038 of the routing for that flow may no longer be considered 2039 desirable) 2041 - It is desired to change the encapsulation used to carry the C- 2042 flow, e.g., because one now wants to aggregate it on a P-tunnel 2043 with flows from other MVPNs. 2045 Section 7.1 discusses certain considerations that apply whenever a 2046 specified C-flow is moved (using the mechanisms of section 7.4) from 2047 one P-tunnel to another. 2049 Section 7.2 discusses the specific case of using the mechanisms of 2050 section 7.4 as a way of optimizing multicast routing by switching 2051 specific flows from one P-tunnel to another. 2053 Section 7.3 discusses the case where the mechanisms of section 7.4 2054 are used to announce the presence of "unsolicited flooded data" and 2055 to assign such data to a particular P-tunnel. 2057 Section 7.4 specifies the protocols for assigning specific C-flows to 2058 specific P-tunnels. These protocols may be used to assign a C-flow 2059 to a P-tunnel initially, or to switch a flow from one P-tunnel to 2060 another. 2062 Procedures for binding to a specified P-tunnel the set of C-flows 2063 traveling along a specified C-tree (or for so binding a set of C- 2064 flows that share some relevant characteristic), without identifying 2065 each flow individually, are outside the scope of this document. 2067 7.1. General Considerations when Switching P-Tunnels 2069 The decision to switch a particular C-flow (designated as C-(S,G)) 2070 from one P-tunnel to another is always made by the PE that is 2071 transmitting the C-flow onto the P-tunnel. If there are multiple PEs 2072 transmitting the C-flow, the decision made by a particular 2073 transmitting PE, say PE1, is binding upon all and only those 2074 receiving PEs for whom PE1 is the selected upstream PE for the C- 2075 flow. There is one exception to this rule: if the receiving PE has 2076 only (*, C-G) state, and it receives a particular C-flow from a 2077 particular transmitting PE, say PE1, then if PE1 decides to switch 2078 the flow to another tunnel, this is binding for the receiving PE, 2079 even if PE1 is not the selected upstream PE for the C-flow from the 2080 receiving PE's perspective. 2082 Procedures for switching sets of C-flows traveling along specified C- 2083 trees (or sets of C-flows sharing any other characteristic) from one 2084 P-tunnel to another are outside the scope of this document. 2086 Whenever a particular C-flow is moved from one P-tunnel to another, 2087 for whatever reason, care must be taken to ensure that there is no 2088 duplication of traffic, i.e., that at any given time, the C-flow is 2089 never transmitted on both P-tunnels. 2091 The following procedures MUST be applied : 2093 - When the decision is made by a given PE, PE1, to switch a C-flow 2094 from P-tunnel P1 to P-tunnel P2, PE1 must issue the required 2095 control plane information to signal the switch-over (see section 2096 7.4). 2098 - If P-tunnel P2 needs to be constructed from the root downwards, 2099 PE1 must initiate the signaling to construct P2. This is only 2100 required if P2 is an RSVP-TE P2MP LSP. 2102 - PE1 MUST wait for a "switch-over" delay before sending traffic of 2103 the C-flow on P-tunnel P2. It is RECOMMENDED to allow this delay 2104 to be configurable. 2106 - Once the "switch-over" delay has elapsed, PE1 MUST send traffic 2107 for the C-flow on P2, and MUST NOT send it on P1. In no case is 2108 any C-flow packet send on both P-tunnels. 2110 - When a PE that needs to receive the C-flow learns about the 2111 switch from one P-tunnel to another, it takes the necessary steps 2112 to be able to receive the traffic on the new P-tunnel, P2. This 2113 may involve modifiying the forwarding state for the relevant entries such that traffic can be accepted on the new P- 2115 tunnel P2.. If the P-tunnel is an Aggregate Tree, this also 2116 implies setting up the demultiplexing forwarding entries based on 2117 the inner label as described in section 6.3.3. Depending on the 2118 type of P-tunnel P2 is, this may require using PIM or mLDP to 2119 join the P-tunnel. 2121 - The receiving PE MAY run a switch-over timer, and until it 2122 expires, SHOULD accept traffic for the given C-flow on both P1 2123 and P2. 2125 These procedures are designed to minimize packet loss without 2126 introducing packet duplication. However, jitter may be introduced 2127 due to the difference in transit delays between the old and new P- 2128 multicast tree. 2130 For best effect, the switch-over timer should be configured to a 2131 value that is "just long enough" to allow (a) all the PEs to learn 2132 about the new binding of C-flow to P-tunnel (b) the PEs to construct 2133 the P-tunnel, if it doesn't already exist. 2135 If, after such a switch, the "old" P-tunnel P1 is no longer needed, 2136 it SHOULD be torn down and the resources supporting it freed. The 2137 procedures for "tearing down" a P-tunnel are specific to the P-tunnel 2138 technology. 2140 7.2. Optimizing Multicast Distribution via S-PMSIs 2142 Whenever a particular multicast stream is being sent on an I-PMSI, it 2143 is likely that the data of that stream is being sent to PEs that do 2144 not require it. If a particular stream has a significant amount of 2145 traffic, it may be beneficial to move it to an S-PMSI that includes 2146 only those PEs that are transmitters and/or receivers (or at least 2147 includes fewer PEs that are neither). 2149 If explicit tracking is being done, S-PMSI creation can also be 2150 triggered on other criteria. For instance there could be a "pseudo 2151 wasted bandwidth" criteria: switching to an S-PMSI would be done if 2152 the bandwidth multiplied by the number of uninterested PEs (PE that 2153 are receiving the stream but have no receivers) is above a specified 2154 threshold. The motivation is that (a) the total bandwidth wasted by 2155 many sparsely subscribed low-bandwidth groups may be large, and (b) 2156 there's no point to moving a high-bandwidth group to an S-PMSI if all 2157 the PEs have receivers for it. 2159 Switching a (C-S,C-G) stream to an S-PMSI may require the root of the 2160 S-PMSI to determine the egress PEs that need to receive the (C-S,C-G) 2161 traffic. This is true in the following cases: 2163 - If the P-tunnel is a source initiated tree, such as a RSVP-TE 2164 P2MP Tunnel, the PE needs to know the leaves of the tree before 2165 it can instantiate the S-PMSI. 2167 - If a PE instantiates multiple S-PMSIs, belonging to different 2168 MVPNs, using one P-multicast tree, such a tree is termed an 2169 Aggregate Tree with a selective mapping. The setting up of such 2170 an Aggregate Tree requires the ingress PE to know all the other 2171 PEs that have receivers for multicast groups that are mapped onto 2172 the tree. 2174 The above two cases require that explicit tracking be done for the 2175 (C-S, C-G) stream. The root of the S-PMSI MAY decide to do explicit 2176 tracking of this stream only after it has determined to move the 2177 stream to an S-PMSI, or it MAY have been doing explicit tracking all 2178 along. 2180 If the S-PMSI is instantiated by a P-multicast tree, the PE at the 2181 root of the tree must signal the leaves of the tree that the (C-S,C- 2182 G) stream is now bound to the to the S-PMSI. Note that the PE could 2183 create the identity of the P-multicast tree prior to the actual 2184 instantiation of the P-tunnel. 2186 If the S-PMSI is instantiated by a source-initiated P-multicast tree 2187 (e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree must 2188 establish the source-initiated P-multicast tree to the leaves. This 2189 tree MAY have been established before the leaves receive the S-PMSI 2190 binding, or MAY be established after the leaves receives the binding. 2191 The leaves MUST NOT switch to the S-PMSI until they receive both the 2192 binding and the tree signaling message. 2194 7.3. Announcing the Presence of Unsolicited Flooded Data 2196 A PE may receive "unsolicited" data from a CE, where the data is 2197 intended to be flooded to the other PEs of the same MVPN and then on 2198 to other CEs. By "unsolicited", we mean that the data is to be 2199 delivered to all the other PEs of the MVPN, even though those PEs may 2200 not have send any control information indicating that they need to 2201 receive that data. 2203 For example, if the BSR [BSR] is being used within the MVPN, BSR 2204 control messages may be received by a PE from a CE. These need to be 2205 forwarded to other PEs, even though no PE ever issues any kind of 2206 explicit signal saying that it wants to receive BSR messages. 2208 If a PE receives a BSR message from a CE, and if the CE's MVPN has an 2209 MI-PMSI, then the PE can just send BSR messages on the appropriate P- 2210 tunnel. Otherwise, the PE MUST announce the binding of a particular 2211 C-flow to a particular P-tunnel, using the procedures of section 7.4. 2212 The particular C-flow in this case would be (C-IPaddress_of_PE, ALL- 2213 PIM-ROUTERS). The P-tunnel identified by the procedures of section 2214 7.4 may or may not be one that was previously identified in the PMSI 2215 tunnel attribute of an I-PMSI A-D route. Further procedures for 2216 handling BSR may be found in sections 5.2.1 and 5.3.4. 2218 Analogous procedures may be used for announcing the presence of other 2219 sorts of unsolicited flooded data, e.g., dense mode data or data from 2220 proprietary protocols that presume messages can be flooded. However, 2221 a full specification of the procedures for traffic other than BSR 2222 traffic is outside the scope of this document. 2224 7.4. Protocols for Binding C-flows to P-tunnels 2226 We describe two protocols for binding C-flows to P-tunnels. 2228 These protocols can be used for moving C-flows from I-PMSIs to S- 2229 PMSIs, as long as the S-PMSI is instantiated by a P-multicast tree. 2230 (If the S-PMSI is instantiated by means of ingress replication, the 2231 procedures of section 6.4.5 suffice.) 2233 These protocols can also be used for other cases in which it is 2234 necessary to bind specific C-flows to specific P-tunnels. 2236 7.4.1. Using BGP S-PMSI A-D Routes 2238 Not withstanding the name of the mechanism "S-PMSI A-D Routes", the 2239 mechanism to be specified in this section may be used any time it is 2240 necessary to advertise a binding of a C-flow to a particular P- 2241 tunnel. 2243 7.4.1.1. Advertising C-flow Binding to P-Tunnel 2245 The ingress PE informs all the PEs that are on the path to receivers 2246 of the C-(S,G) of the binding of the P-tunnel to the C-(S,G). The BGP 2247 announcement is done by sending update for the MCAST-VPN address 2248 family. An S-PMSI A-D route is used, containing the following 2249 information: 2251 1. IP address of the originating PE 2253 2. The RD configured locally for the MVPN. This is required to 2254 uniquely identify the as the addresses could overlap 2255 between different MVPNs. This is the same RD value used in the 2256 auto-discovery process. 2258 3. The C-S address. 2260 4. The C-G address. 2262 5. A PE MAY use a single P-tunnel to aggregate two or more S- 2263 PMSIs. If the PE already advertised unaggregated S-PMSI auto- 2264 discovery routes for these S-PMSIs, then a decision to 2265 aggregate them requires the PE to re-advertise these routes. 2266 The re-advertised routes MUST be the same as the original ones, 2267 except for the PMSI tunnel attribute. If the PE has not 2268 previously advertised S-PMSI auto-discovery routes for these S- 2269 PMSIs, then the aggregation requires the PE to advertise (new) 2270 S-PMSI auto-discovery routes for these S-PMSIs. The PMSI 2271 Tunnel attribute in the newly advertised/re-advertised routes 2272 MUST carry the identity of the P-tunnel that aggregates the S- 2273 PMSIs. If at least some of the S-PMSIs aggregated onto the same 2274 P-tunnel belong to different MVPNs, then all these routes MUST 2275 carry an MPLS upstream assigned label [MPLS-UPSTREAM-LABEL, 2276 section 6.3.4]. If all these aggregated S-PMSIs belong to the 2277 same MVPN, then the routes MAY carry an MPLS upstream assigned 2278 label [MPLS-UPSTREAM-LABEL]. The labels MUST be distinct on a 2279 per MVPN basis, and MAY be distinct on a per route basis. 2281 When a PE distributes this information via BGP, it must include the 2282 following: 2284 1. An identifier for the particular P-tunnel to which the stream 2285 is to be bound. This identifier is a structured field that 2286 includes the following information: 2288 * The type of tunnel 2290 * An identifier for the tunnel. The form of the identifier 2291 will depend upon the tunnel type. The combination of 2292 tunnel identifier and tunnel type should contain enough 2293 information to enable all the PEs to "join" the tunnel and 2294 receive messages from it. 2296 2. Route Target Extended Communities attribute. This is used as 2297 described in section 4. 2299 7.4.1.2. Explicit Tracking 2301 If the PE wants to enable explicit tracking for the specified flow, 2302 it also indicates this in the A-D route it uses to bind the flow to a 2303 particular P-tunnel. Then any PE that receives the A-D route will 2304 respond with a "Leaf A-D Route" in which it identifies itself as a 2305 receiver of the specified flow. The Leaf A-D route will be withdrawn 2306 when the PE is no longer a receiver for the flow. 2308 If the PE needs to enable explicit tracking for a flow without at the 2309 same time binding the flow to a specific P-tunnel, it can do so by 2310 sending an S-PMSI A-D route whose NLRI identifies the flow and whose 2311 PMSI Tunnel attribute has its tunnel type value set to "no tunnel 2312 information present" and its "leaf information required" bit set to 2313 1. This will elicit the Leaf A-D Routes. This is useful when the PE 2314 needs to know the receivers before selecting a P-tunnel. 2316 7.4.2. UDP-based Protocol 2318 This procedure carries its control messages in UDP, and requires that 2319 the MVPN has an MI-PMSI that can be used to carry the control 2320 messages. 2322 7.4.2.1. Advertising C-flow Binding to P-tunnel 2324 In order for a given PE to move a particular C-flow to a particular 2325 P-tunnel, an "S-PMSI Join message" is sent periodically on the MI- 2326 PMSI. (Notwithstanding the name of the mechanism, the mechanism may 2327 be used to bind a flow to any P-tunnel.) The S-PMSI Join is a UDP- 2328 encapsulated message whose destination address is ALL-PIM-ROUTERS 2329 (224.0.0.13), and whose destination port is 3232. 2331 The S-PMSI Join Message contains the following information: 2333 - An identifier for the particular multicast stream that is to be 2334 bound to the P-tunnel. This can be represented as an (S,G) pair. 2336 - An identifier for the particular P-tunnel to which the stream is 2337 to be bound. This identifier is a structured field that includes 2338 the following information: 2340 * The type of tunnel used to instantiate the S-PMSI 2342 * An identifier for the tunnel. The form of the identifier 2343 will depend upon the tunnel type. The combination of tunnel 2344 identifier and tunnel type should contain enough information 2345 to enable all the PEs to "join" the tunnel and receive 2346 messages from it. 2348 * If (and only if) the identified P-tunnel is aggregating 2349 several S-PMSIs, any demultiplexing information needed by the 2350 tunnel encapsulation protocol to identify a particular S- 2351 PMSI. 2353 If the policy for the MVPN is that traffic is sent/received by 2354 default over an MI-PMSI, then traffic for a particular C-flow can be 2355 switched back to the MI-PMSI simply by ceasing to send S-PMSI Joins 2356 for that C-flow. 2358 7.4.2.2. Packet Formats and Constants 2360 The S-PMSI Join message is encapsulated within UDP, and has the 2361 following type/length/value (TLV) encoding: 2363 0 1 2 3 2364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Type | Length | Value | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | . | 2369 | . | 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 Type (8 bits) 2374 Length (16 bits): the total number of octets in the Type, Length, and 2375 Value fields combined 2377 Value (variable length) 2379 Currently only one type of S-PMSI Join is defined. A type 1 S-PMSI 2380 Join is used when the S-PMSI tunnel is a PIM tunnel that is used to 2381 carry a single multicast stream, where the packets of that stream 2382 have IPv4 source and destination IP addresses. 2384 0 1 2 3 2385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | Type | Length | Reserved | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | C-source | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | C-group | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | P-group | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 Type (8 bits): 1 2398 Length (16 bits): 16 2400 Reserved (8 bits): This field SHOULD be zero when transmitted, and 2401 MUST be ignored when received. 2403 C-Source (32 bits): the IPv4 address of the traffic source in the 2404 VPN. 2406 C-Group (32 bits): the IPv4 address of the multicast traffic 2407 destination address in the VPN. 2409 P-Group (32 bits): the IPv4 group address that the PE router is going 2410 to use to encapsulate the flow (C-Source, C-Group). 2412 The P-group identifies the S-PMSI P-tunnel, and the (C-S,C-G) 2413 identifies the multicast flow that is carried in the P-tunnel. 2415 The protocol uses the following constants. 2417 [S-PMSI_DELAY]: 2419 the PE router that is to transmit onto the S-PMSI will delay this 2420 amount of time before it begins using the S-PMSI. The default 2421 value is 3 seconds. 2423 [S-PMSI_TIMEOUT]: 2425 if a PE (other than the transmitter) does not receive any packets 2426 over the S-PMSI P-tunnel for this amount of time, the PE will 2427 prune itself from the S-PMSI P-tunnel, and will expect (C-S,C-G) 2428 packets to arrive on an I-PMSI. The default value is 3 minutes. 2429 This value must be consistent among PE routers. 2431 [S-PMSI_HOLDOWN]: 2433 if the PE that transmits onto the S-PMSI does not see any (C-S,C- 2434 G) packets for this amount of time, it will resume sending (C- 2435 S,C-G) packets on an I-PMSI. 2437 This is used to avoid oscillation when traffic is bursty. The 2438 default value is 1 minute. 2440 [S-PMSI_INTERVAL] 2441 the interval the transmitting PE router uses to periodically send 2442 the S-PMSI Join message. The default value is 60 seconds. 2444 7.4.3. Aggregation 2446 S-PMSIs can be aggregated on a P-multicast tree. The S-PMSI to 2447 C-(S,G) binding advertisement supports aggregation. Furthermore the 2448 aggregation procedures of section 6.3 apply. It is also possible to 2449 aggregate both S-PMSIs and I-PMSIs on the same P-multicast tree. 2451 8. Inter-AS Procedures 2453 If an MVPN has sites in more than one AS, it requires one or more 2454 PMSIs to be instantiated by inter-AS P-tunnels. This document 2455 describes two different types of inter-AS P-tunnel: 2457 1. "Segmented Inter-AS P-tunnels" 2459 A segmented inter-AS P-tunnel consists of a number of 2460 independent segments that are stitched together at the ASBRs. 2461 There are two types of segment, inter-AS segments and intra-AS 2462 segments. The segmented inter-AS P-tunnel consists of 2463 alternating intra-AS and inter-AS segments. 2465 Inter-AS segments connect adjacent ASBRs of different ASes; 2466 these "one-hop" segments are instantiated as unicast P-tunnels. 2468 Intra-AS segments connect ASBRs and PEs that are in the same 2469 AS. An intra-AS segment may be of whatever technology is 2470 desired by the SP that administers the that AS. Different 2471 intra-AS segments may be of different technologies. 2473 Note that the intra-AS segments of inter-AS P-tunnels form a 2474 category of P-tunnels that is distinct from simple intra-AS P- 2475 tunnels; we will rely on this distinction later (see Section 2476 9). 2478 A segmented inter-AS P-tunnel can be thought of as a tree that 2479 is rooted at a particular AS, and that has as its leaves the 2480 other ASes that need to receive multicast data from the root 2481 AS. 2483 2. "Non-segmented Inter-AS P-tunnels" 2485 A non-segmented inter-AS P-tunnel is a single P-tunnel that 2486 spans AS boundaries. The tunnel technology cannot change from 2487 one point in the tunnel to the next, so all ASes through which 2488 the P-tunnel passes must support that technology. In essence, 2489 AS boundaries are of no significance to a non-segmented inter- 2490 AS P-tunnel. 2492 Section 10 of [RFC4364] describes three different options for 2493 supporting unicast Inter-AS BGP/MPLS IP VPNs, known as options A, B, 2494 and C. We describe below how both segmented and non-segmented inter- 2495 AS trees can be supported when option B or option C is used. (Option 2496 A does not pass any routing information through an ASBR at all, so no 2497 special inter-AS procedures are needed.) 2499 8.1. Non-Segmented Inter-AS P-Tunnels 2501 In this model, the previously described discovery and tunnel setup 2502 mechanisms are used, even though the PEs belonging to a given MVPN 2503 may be in different ASes. 2505 8.1.1. Inter-AS MVPN Auto-Discovery 2507 The previously described BGP-based auto-discovery mechanisms work "as 2508 is" when an MVPN contains PEs that are in different Autonomous 2509 Systems. However, please note that, if non-segmented Inter-AS P- 2510 Tunnels are to be used, then the "Intra-AS" I-PMSI A-D routes MUST be 2511 distributed across AS boundaries! 2513 8.1.2. Inter-AS MVPN Routing Information Exchange 2515 When non-segmented inter-AS P-tunnels are used, MVPN C-multicast 2516 routing information may be exchanged by means of PIM peering across 2517 an MI-PMSI, or by means of BGP carrying C-multicast routes. 2519 When PIM peering is used to distribute the C-multicast routing 2520 information, a PE that sends C-PIM Join/Prune messages for a 2521 particular C-(S,G) must be able to identify the PE that is its PIM 2522 adjacency on the path to S. This is the "selected upstream PE" 2523 described in section 5.1. 2525 If BGP (rather than PIM) is used to distribute the C-multicast 2526 routing information, and if option b of section 10 of [RFC4364] is in 2527 use, then the C-multicast routes will be installed in the ASBRs along 2528 the path from each multicast source in the MVPN to each multicast 2529 receiver in the MVPN. If option b is not in use, the C-multicast 2530 routes are not installed in the ASBRs. The handling of the C- 2531 multicast routes in either case is thus exactly analogous to the 2532 handling of unicast VPN-IP routes in the corresponding case. 2534 8.1.3. Inter-AS P-Tunnels 2536 The procedures described earlier in this document can be used to 2537 instantiate either an I-PMSI or an S-PMSI with inter-AS P-tunnels. 2538 Specific tunneling techniques require some explanation. 2540 If ingress replication is used, the inter-AS PE-PE P-tunnels will use 2541 the inter-AS tunneling procedures for the tunneling technology used. 2543 Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP P- 2544 Tunnels. 2546 Procedures for using PIM to set up the P-tunnels are discussed in 2547 the next section. 2549 8.1.3.1. PIM-Based Inter-AS P-Multicast Trees 2551 When PIM is used to set up an inter-AS P-multicast tree, the PIM 2552 Join/Prune messages used to join the tree contain the IP address of 2553 the upstream PE. However, there are two special considerations that 2554 must be taken into account: 2556 - It is possible that the P routers within one or more of the ASes 2557 will not have routes to the upstream PE. For example, if an AS 2558 has a "BGP-free core", the P routers in an AS will not have 2559 routes to addresses outside the AS. 2561 - If the PIM Join/Prune message must travel through several ASes, 2562 it is possible that the ASBRs will not have routes to he PE 2563 routers. For example, in an inter-AS VPN constructed according 2564 to "option b" of section 10 of [RFC4364], the ASBRs do not 2565 necessarily have routes to the PE routers. 2567 If either of these two conditions obtains, then "ordinary" PIM 2568 Join/Prune messages cannot be routed to the upstream PE. Therefore, 2569 in that case the PIM Join/Prune messages MUST contain the "PIM MVPN 2570 Join Attribute". This allows the multicast distribution tree to be 2571 properly constructed even if routes to PEs in other ASes do not exist 2572 in the given AS's IGP, and even if the routes to those PEs do not 2573 exist in BGP. The use of an PIM MVPN Join Attribute in the PIM 2574 messages allows the inter-AS trees to be built. 2576 The use of the PIM MVPN Join Attribute allows the following 2577 information needs to be added to the PIM Join/Prune messages: a 2578 "Proxy Address", which contains the address of the next ASBR on the 2579 path to the upstream PE. When the PIM Join/Prune arrives at the ASBR 2580 that is identified by the "proxy address", that ASBR must change the 2581 proxy address to identify the next hop ASBR. 2583 This information allows the PIM Join/Prune to be routed through an AS 2584 even if the P routers of that AS do not have routes to the upstream 2585 PE. However, this information is not sufficient to enable the ASBRs 2586 to route the Join/Prune if the ASBRs themselves do not have routes to 2587 the upstream PE. 2589 However, even if the ASBRs do not have routes to the upstream PE, the 2590 procedures of this draft ensure that they will have Inter-AS I-PMSI 2591 A-D routes that lead to the upstream PE. If non-segmented inter-AS 2592 P-tunnels are being used, the ASBRs (and PEs) will have Intra-AS I- 2593 PMSI A-D routes that have been distributed inter-AS. 2595 So rather than having the PIM Join/Prune messages routed by the ASBRs 2596 along a route to the upstream PE, the PIM Join/Prune messages MUST be 2597 routed along the path determined by the Intra-AS I-PMSI A-D routes. 2599 If the only intra-AS A-D route for a given MVPN is the "Intra-AS I- 2600 PMSI Route", the PIM Join/Prunes will be routed along that. However, 2601 if the PIM Join/Prune message is for a particular P-group address, 2602 and there is an "Intra-AS S-PMSI Route" specifying that particular P- 2603 group address as the P-tunnel for a particular S-PMSI, then the PIM 2604 Join/Prunes MUST be routed along the path determined by those intra- 2605 AS A-D routes. 2607 The basic format of a PIM Join Attribute is specified in [PIM- 2608 ATTRIB]. The details of the PIM MVPN Join Attribute are specified in 2609 the next section. 2611 8.1.3.2. The PIM MVPN Join Attribute 2613 8.1.3.2.1. Definition 2615 In [PIM-ATTRIB], the notion of a "join attribute" is defined, and a 2616 format for included join attributes in PIM Join/Prune messages is 2617 specified. We now define a new join attribute, which we call the 2618 "MVPN Join Attribute". 2620 0 1 2 3 2621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 | Type | Length | Proxy IP address 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | RD 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 2628 The Type field of the MVPN Join Attribute is set to 1. 2630 The F bit is set to 0. 2632 Two information fields are carried in the MVPN Join attribute: 2634 - Proxy: The IP address of the node towards which the PIM 2635 Join/Prune message is to be forwarded. This will either be an 2636 IPv4 or an IPv6 address, depending on whether the PIM Join/Prune 2637 message itself is IPv4 or IPv6. 2639 - RD: An eight-byte RD. This immediately follows the proxy IP 2640 address. 2642 The PIM message also carries the address of the upstream PE. 2644 In the case of an intra-AS MVPN, the proxy and the upstream PE are 2645 the same. In the case of an inter-AS MVPN, proxy will be the ASBR 2646 that is the exit point from the local AS on the path to the upstream 2647 PE. 2649 8.1.3.2.2. Usage 2651 When a PE router creates a PIM Join/Prune message in order to set up 2652 an inter-AS I-PMSI, it does so as a result of having received a 2653 particular Intra-AS A-D route. It includes an MVPN Join attribute 2654 whose fields are set as follows: 2656 - If the upstream PE is in the same AS as the local PE, then the 2657 proxy field contains the address of the upstream PE. Otherwise, 2658 it contains the address of the BGP next hop on the route to the 2659 upstream PE. 2661 - The Rd field contains the RD from the NLRI of the Intra-AS A-D 2662 route. 2664 - The upstream PE field contains the address of the PE that 2665 originated the Intra-AS A-D route (obtained from the NLRI of that 2666 route). 2668 When a PIM router processes a PIM Join/Prune message with an MVPN 2669 Join Attribute, it first checks to see if the proxy field contains 2670 one of its own addresses. 2672 If not, the router uses the proxy IP address in order to determine 2673 the RPF interface and neighbor. The MVPN Join Attribute must be 2674 passed upstream, unchanged. 2676 If the proxy address is one of the router's own IP addresses, then 2677 the router looks in its BGP routing table for an Intra-AS A-D route 2678 whose NLRI consists of the upstream PE address prepended with the RD 2679 from the Join attribute. If there is no match, the PIM message is 2680 discarded. If there is a match the IP address from the BGP next hop 2681 field of the matching route is used in order to determine the RPF 2682 interface and neighbor. When the PIM Join/Prune is forwarded 2683 upstream, the proxy field is replaced with the address of the BGP 2684 next hop, and the RD and upstream PE fields are left unchanged. 2686 The use of non-segmented inter-AS trees constructed via BIDIR-PIM is 2687 outside the scope of this document. 2689 8.2. Segmented Inter-AS P-Tunnels 2691 8.2.1. Inter-AS MVPN Auto-Discovery Routes 2693 The BGP based MVPN membership discovery procedures of section 4 are 2694 used to auto-discover the intra-AS MVPN membership. This section 2695 describes the additional procedures for inter-AS MVPN membership 2696 discovery. It also describes the procedures for constructing 2697 segmented inter-AS P-tunnels. 2699 In this case, for a given MVPN in an AS, the objective is to form a 2700 spanning tree of MVPN membership, rooted at the AS. The nodes of this 2701 tree are ASes. The leaves of this tree are only those ASes that have 2702 at least one PE with a member in the MVPN. The inter-AS P-tunnel used 2703 to instantiate an inter-AS PMSI must traverse this spanning tree. A 2704 given AS needs to announce to another AS only the fact that it has 2705 membership in a given MVPN. It doesn't need to announce the 2706 membership of each PE in the AS to other ASes. 2708 This section defines an inter-AS auto-discovery route as a route that 2709 carries information about an AS that has one or more PEs (directly) 2710 connected to the site(s) of that MVPN. Further it defines an inter-AS 2711 leaf auto-discovery route in the following way: 2712 - Consider a node that is the root of an an intra-AS segment of an 2713 inter-AS P-tunnel. An inter-AS leaf autodiscovery route is used 2714 to inform such a node of a leaf of that intra-AS segment. 2716 8.2.1.1. Originating Inter-AS MVPN A-D Information 2718 A PE in a given AS advertises its MVPN membership to all its IBGP 2719 peers. This IBGP peer may be a route reflector that in turn 2720 advertises this information to only its IBGP peers. In this manner 2721 all the PEs and ASBRs in the AS learn this membership information. 2723 An Autonomous System Border Router (ASBR) may be configured to 2724 support a particular MVPN. If an ASBR is configured to support a 2725 particular MVPN, the ASBR MUST participate in the intra-AS MVPN auto- 2726 discovery/binding procedures for that MVPN within the AS that the 2727 ASBR belongs to, as defined in this document. 2729 Each ASBR then advertises the "AS MVPN membership" to its neighbor 2730 ASBRs using EBGP. This inter-AS auto-discovery route must not be 2731 advertised to the PEs/ASBRs in the same AS as this ASBR. The 2732 advertisement carries the following information elements: 2734 a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR 2735 in the AS must use the same RD when advertising this 2736 information to other ASBRs. To accomplish this all the ASBRs 2737 within that AS, that are configured to support the MVPN, MUST 2738 be configured with the same RD for that MVPN. This RD MUST be 2739 of Type 0, MUST embed the autonomous system number of the AS. 2741 b. The announcing ASBR's local address as the next-hop for the 2742 above information elements. 2744 c. By default the BGP Update message MUST carry export Route 2745 Targets used by the unicast routing of that VPN. The default 2746 could be modified via configuration by having a set of Route 2747 Targets used for the inter-AS auto-discovery routes being 2748 distinct from the ones used by the unicast routing of that VPN. 2750 8.2.1.2. Propagating Inter-AS MVPN A-D Information 2752 As an inter-AS auto-discovery route originated by an ASBR within a 2753 given AS is propagated via BGP to other ASes, this results in 2754 creation of a data plane P-tunnel that spans multiple ASes. This P- 2755 tunnel is used to carry (multicast) traffic from the MVPN sites 2756 connected to the PEs of the AS to the MVPN sites connected to the PEs 2757 that are in the other ASes. Such a P-P-tunnel consists of multiple 2758 intra-AS segments (one per AS) stitched at ASBRs' boundaries by 2759 single hop LSP segments. 2761 An ASBR originates creation of an intra-AS segment when the ASBR 2762 receives an inter-AS auto-discovery route from an EBGP neighbor. 2763 Creation of the segment is completed as a result of distributing via 2764 IBGP this route within the ASBR's own AS. 2766 For a given inter-AS tunnel each of its intra-AS segments could be 2767 constructed by its own independent mechanism. Moreover, by using 2768 upstream labels within a given AS multiple intra-AS segments of 2769 different inter-AS tunnels of either the same or different MVPNs may 2770 share the same P-Multicast Tree. 2772 Since (aggregated) inter-AS auto-discovery routes have granularity of 2773 , an MVPN that is present in N ASes would have total of N 2774 inter-AS tunnels. Thus for a given MVPN the number of inter-AS 2775 tunnels is independent of the number of PEs that have this MVPN. 2777 The following sections specify procedures for propagation of 2778 (aggregated) inter-AS auto-discovery routes across ASes. 2780 8.2.1.2.1. Inter-AS Auto-Discovery Route received via EBGP 2782 When an ASBR receives from one of its EBGP neighbors a BGP Update 2783 message that carries the inter-AS auto-discovery route if (a) at 2784 least one of the Route Targets carried in the message matches one of 2785 the import Route Targets configured on the ASBR, and (b) the ASBR 2786 determines that the received route is the best route to the 2787 destination carried in the NLRI of the route, the ASBR: 2789 a) Re-advertises this inter-AS auto-discovery route within its own 2790 AS. 2792 If the ASBR uses ingress replication to instantiate the intra- 2793 AS segment of the inter-AS P-tunnel, the re-advertised route 2794 SHOULD carry a Tunnel attribute with the Tunnel Identifier set 2795 to Ingress Replication, but no MPLS labels. 2797 If a P-Multicast Tree is used to instantiate the intra-AS 2798 segment of the inter-AS P-tunnel, and in order to advertise the 2799 P-Multicast tree identifier the ASBR doesn't need to know the 2800 leaves of the tree beforehand, then the advertising ASBR SHOULD 2801 advertise the P-Multicast tree identifier in the P-Tunnel 2802 Identifier of the P-Tunnel attribute. This, in effect, creates 2803 a binding between the inter-AS auto-discovery route and the P- 2804 Multicast Tree. 2806 If a P-Multicast Tree is used to instantiate the intra-AS 2807 segment of the inter-AS P-tunnel, and in order to advertise the 2808 P-Multicast tree identifier the advertising ASBR needs to know 2809 the leaves of the tree beforehand, the ASBR first discovers the 2810 leaves using the Auto-Discovery procedures, as specified 2811 further down. It then advertises the binding of the tree to the 2812 inter-AS auto-discovery route using the the original auto- 2813 discovery route with the addition of carrying in the route the 2814 P-Tunnel attribute that contains the type and the identity of 2815 the tree (encoded in the P-Tunnel Identifier of the attribute). 2817 b) Re-advertises the received inter-AS auto-discovery route to its 2818 EBGP peers, other than the EBGP neighbor from which the best 2819 inter-AS auto-discovery route was received. 2821 c) Advertises to its neighbor ASBR, from which it received the 2822 best inter-AS autodiscovery route to the destination carried in 2823 the NLRI of the route, a leaf auto-discovery route that carries 2824 an ASBR-ASBR P-tunnel binding with the tunnel identifier set to 2825 ingress replication. This binding as described in section 6 can 2826 be used by the neighbor ASBR to send traffic to this ASBR. 2828 8.2.1.2.2. Leaf Auto-Discovery Route received via EBGP 2830 When an ASBR receives via EBGP a leaf auto-discovery route, the ASBR 2831 finds an inter-AS auto-discovery route that has the same RD as the 2832 leaf auto-discovery route. The MPLS label carried in the leaf auto- 2833 discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail 2834 of the intra-AS P-tunnel segment associated with the inter-AS auto- 2835 discovery route. 2837 8.2.1.2.3. Inter-AS Auto-Discovery Route received via IBGP 2839 If a given inter-AS auto-discovery route is advertised within an AS 2840 by multiple ASBRs of that AS, the BGP best route selection performed 2841 by other PE/ASBR routers within the AS does not require all these 2842 PE/ASBR routers to select the route advertised by the same ASBR - to 2843 the contrary different PE/ASBR routers may select routes advertised 2844 by different ASBRs. 2846 Further when a PE/ASBR receives from one of its IBGP neighbors a BGP 2847 Update message that carries a AS MVPN membership tree , if (a) the 2848 route was originated outside of the router's own AS, (b) at least one 2849 of the Route Targets carried in the message matches one of the import 2850 Route Targets configured on the PE/ASBR, and (c) the PE/ASBR 2851 determines that the received route is the best route to the 2852 destination carried in the NLRI of the route, if the router is an 2853 ASBR then the ASBR propagates the route to its EBGP neighbors. In 2854 addition the PE/ASBR performs the following. 2856 If the received inter-AS auto-discovery route carries the Tunnel 2857 attribute with the Tunnel Identifier set to LDP P2MP LSP, or PIM-SSM 2858 tree, or PIM-SM tree, the PE/ASBR SHOULD join the P-Multicast tree 2859 whose identity is carried in the Tunnel Identifier. 2861 If the received source auto-discovery route carries the Tunnel 2862 attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then 2863 the ASBR that originated the route MUST signal the local PE/ASBR as 2864 one of leaf LSRs of the RSVP-TE P2MP LSP. This signaling MAY have 2865 been completed before the local PE/ASBR receives the BGP Update 2866 message. 2868 If the NLRI of the route does not carry a label, then this tree is an 2869 intra-AS P-tunnel segment that is part of the inter-AS P-Tunnel for 2870 the MVPN advertised by the inter-AS auto-discovery route. If the NLRI 2871 carries a (upstream) label, then a combination of this tree and the 2872 label identifies the intra-AS segment. 2874 If this is an ASBR, this intra-AS segment may further be stitched to 2875 ASBR-ASBR inter-AS segment of the inter-AS P-tunnel. If the PE/ASBR 2876 has local receivers in the MVPN, packets received over the intra-AS 2877 segment must be forwarded to the local receivers using the local VRF. 2879 If the received inter-AS auto-discovery route either does not carry 2880 the Tunnel attribute, or carries the Tunnel attribute with the Tunnel 2881 Identifier set to ingress replication, then the PE/ASBR originates a 2882 new auto-discovery route to allow the ASBR from which the auto- 2883 discovery route was received, to learn of this ASBR as a leaf of the 2884 intra-AS tree. 2886 Thus the AS MVPN membership information propagates across multiple 2887 ASes along a spanning tree. BGP AS-Path based loop prevention 2888 mechanism prevents loops from forming as this information propagates. 2890 8.2.2. Inter-AS MVPN Routing Information Exchange 2892 All of the MVPN routing information exchange methods specified in 2893 section 5 can be supported across ASes. 2895 The objective in this case is to propagate the MVPN routing 2896 information to the remote PE that originates the unicast route to C- 2897 S/C-RP, in the reverse direction of the AS MVPN membership 2898 information announced by the remote PE's origin AS. This information 2899 is processed by each ASBR along this reverse path. 2901 To achieve this the PE that is generating the MVPN routing 2902 advertisement, first determines the source AS of the unicast route to 2903 C-S/C-RP. It then determines from the received AS MVPN membership 2904 information, for the source AS, the ASBR that is the next-hop for the 2905 best path of the source AS MVPN membership. The BGP MVPN routing 2906 update is sent to this ASBR and the ASBR then further propagates the 2907 BGP advertisement. BGP filtering mechanisms ensure that the BGP MVPN 2908 routing information updates flow only to the upstream router on the 2909 reverse path of the inter-AS MVPN membership tree. Details of this 2910 filtering mechanism and the relevant encoding will be specified in a 2911 separate document. 2913 8.2.3. Inter-AS I-PMSI 2915 All PEs in a given AS, use the same inter-AS heterogeneous P-tunnel, 2916 rooted at the AS, to instantiate an I-PMSI for an inter-AS MVPN 2917 service. As explained earlier the intra-AS P-tunnel segments that 2918 comprise this P-tunnel can be built using different tunneling 2919 technologies. To instantiate an MI-PMSI service for a MVPN there must 2920 be an inter-AS P-tunnel rooted at each AS that has at least one PE 2921 that is a member of the MVPN. 2923 A C-multicast data packet is sent using an intra-AS P-tunnel segment 2924 by the PE that first receives this packet from the MVPN customer 2925 site. An ASBR forwards this packet to any locally connected MVPN 2926 receivers for the multicast stream. If this ASBR has received a 2927 tunnel binding for the AS MVPN membership that it advertised to a 2928 neighboring ASBR, it also forwards this packet to the neighboring 2929 ASBR. In this case the packet is encapsulated in the downstream MPLS 2930 label received from the neighboring ASBR. The neighboring ASBR 2931 delivers this packet to any locally connected MVPN receivers for that 2932 multicast stream. It also transports this packet on an intra-AS P- 2933 tunnel segment, for the inter-AS MVPN P-tunnel, and the other PEs and 2934 ASBRs in the AS then receive this packet. The other ASBRs then 2935 repeat the procedure followed by the ASBR in the origin AS and the 2936 packet traverses the overlay inter-AS P-tunnel along a spanning tree. 2938 8.2.3.1. Support for Unicast VPN Inter-AS Methods 2940 The above procedures for setting up an inter-AS I-PMSI can be 2941 supported for each of the unicast VPN inter-AS models described in 2942 [RFC4364]. These procedures do not depend on the method used to 2943 exchange unicast VPN routes. For Option B and Option C they do 2944 require MPLS encapsulation between the ASBRs. 2946 8.2.3.2. Bandwidth Optimization by Filtering on ASBRs 2948 An ASBR that has a given inter-AS I-PMSI auto-discovery route MAY 2949 filter (discard) some of the traffic carried in the P-tunnel 2950 specified in the PMSI Tunnel attribute of this route if the ASBR 2951 determines that there are no downstream receivers for that traffic. 2953 The above-mentioned filtering MAY also apply to an ASBR that 2954 originates a given inter-AS I-PMSI auto-discovery route. In this case 2955 the ASBR applies them to the traffic carried over the P-tunnels 2956 specified in the PMSI Tunnel attribute of the intra-AS I-PMSI auto- 2957 discovery routes that the ASBR aggregates into the inter-AS I-PMSI 2958 auto-discovery route, and whose tails are stitched to the one-hop 2959 ASBR-ASBR P-tunnel specified in the inter-AS I-PMSI auto-discovery 2960 route. 2962 8.2.4. Inter-AS S-PMSI 2964 An inter-AS P-tunnel for an S-PMSI is constructed similar to an 2965 inter-AS P-tunnel for an I-PMSI. Namely, such a P-tunnel is 2966 constructed as a concatenation of P-tunnel segments. There are two 2967 types of P-tunnel segments: an intra-AS P-tunnel segment (a segment 2968 that spans ASBRs and PEs within the same AS), and inter-AS P-tunnel 2969 segment (a segment that spans adjacent ASBRs in adjacent ASes). ASes 2970 that are spanned by a P-tunnel are not required to use the same P- 2971 tunneling mechanism to construct the P-tunnel - each AS may pick up a 2972 tunneling mechanism to construct the intra-AS P-tunnel segment of the 2973 tunnel on its own. 2975 The PE that decides to set up a S-PMSI, advertises the S-PMSI tunnel 2976 binding using procedures in section 7.4.1 to the routers in its own 2977 AS. The membership for which the S-PMSI is instantiated, 2978 is propagated along an inter-AS spanning tree. This spanning tree 2979 traverses the same ASBRs as the AS MVPN membership spanning tree. In 2980 addition to the information elements described in section 7.4.1 2981 (Origin AS, RD, next-hop) the C-S and C-G is also advertised. 2983 An ASBR that receives the AS information from its upstream 2984 ASBR using EBGP sends back a tunnel binding for AS 2985 information if a) at least one of the Route Targets carried in the 2986 message matches one of the import Route Targets configured on the 2987 ASBR, and (b) the ASBR determines that the received route is the best 2988 route to the destination carried in the NLRI of the route. If the 2989 ASBR instantiates a S-PMSI for the AS it sends back a 2990 downstream label that is used to forward the packet along its intra- 2991 AS S-PMSI for the . However the ASBR may decide to use an 2992 AS MVPN membership I-PMSI instead, in which case it sends back the 2993 same label that it advertised for the AS MVPN membership I-PMSI. If 2994 the downstream ASBR instantiates a S-PMSI, it further propagates the 2995 membership to its downstream ASes, else it does not. 2997 An AS can instantiate an intra-AS S-PMSI for the inter-AS S-PMSI P- 2998 tunnel only if the upstream AS instantiates a S-PMSI. The procedures 2999 allow each AS to determine whether it wishes to setup a S-PMSI or not 3000 and the AS is not forced to setup a S-PMSI just because the upstream 3001 AS decides to do so. 3003 The leaves of an intra-AS S-PMSI P-tunnel will be the PEs that have 3004 local receivers that are interested in and the ASBRs that 3005 have received MVPN routing information for . Note that an 3006 AS can determine these ASBRs as the MVPN routing information is 3007 propagated and processed by each ASBR on the AS MVPN membership 3008 spanning tree. 3010 The C-multicast data traffic is sent on the S-PMSI by the originating 3011 PE. When it reaches an ASBR that is on the spanning tree, it is 3012 delivered to local receivers, if any, and is also forwarded to the 3013 neighbor ASBR after being encapsulated in the label advertised by the 3014 neighbor. The neighbor ASBR either transports this packet on the S- 3015 PMSI for the multicast stream or an I-PMSI, delivering it to the 3016 ASBRs in its own AS. These ASBRs in turn repeat the procedures of the 3017 origin AS ASBRs and the multicast packet traverses the spanning tree. 3019 9. Duplicate Packet Detection and Single Forwarder PE 3021 Consider the case of an egress PE that receives packets of a customer 3022 multicast stream (C-S,C-G) over a non-aggregated S-PMSI. The 3023 procedures described so far will never cause the PE to receive 3024 duplicate copies of any packet in that stream. It is possible that 3025 the (C-S,C-G) stream is carried in more than one S-PMSI; this may 3026 happen when the site that contains C-S is multihomed to more than one 3027 PE. However, a PE that needs to receive (C-S, C-G) packets only 3028 joins one of these S-PMSIs, and so only receives one copy of each 3029 packet. 3031 However, if the data packets of stream (C-S,C-G) are carried in 3032 either an I-PMSI or in an aggregated S-PMSI, then it the procedures 3033 specified so far make it possible for an egress PE to receive more 3034 than one copy of each data packet. In this section, we define 3035 additional procedures to that an MVPN customer sees no multicast data 3036 packet duplication. 3038 This section covers the situation where the C-trees are 3039 unidirectional, in either the ASM or SSM service models. The case 3040 where the C-trees are bidirectional is considered separately in 3041 section 11. 3043 The first case when an egress PE may receive duplicate multicast data 3044 packets, is the case where both (a) an MVPN site that contains C-S or 3045 C-RP is multihomed to more than one PE, and (b) either an I-PMSI, or 3046 an aggregated S-PMSI is used for carrying the packets originated by 3047 C-S. In this case, an egress PE may receive one copy of the packet 3048 from each PE to which the site is homed. 3050 The second case when an egress PE may receive duplicate multicast 3051 data packets is when all of the following is true: (a) the IP 3052 destination address of the customer packet is a C-G that is operating 3053 in ASM mode, and whose C-multicast tree is set up using PIM-SM, (b) 3054 an MI-PMSI is used for carrying the packets, and (c) a router or a CE 3055 in a site connected to the egress PE switches from the C-RP tree to 3056 C-S tree. In this case, it is possible to get one copy of a given 3057 packet from the ingress PE attached to the C-RP's site, and one from 3058 the ingress PE attached to the C-S's site. 3060 9.1. Multihomed C-S or C-RP 3062 In the first case for a given an egress PE, say PE1, 3063 expects to receive C-data packets from the upstream PE, say PE2, 3064 which PE1 identified as the upstream multicast hop in the C-Multicast 3065 Routing Update that PE1 sent in order to join . If PE1 can 3066 determine that a data packet for was received from the 3067 expected upstream PE, PE2, PE1 will accept and forward the packet. 3068 Otherwise, PE1 will drop the packet; this means that the PE will see 3069 a duplicate, but the duplicate will not get forwarded. (But see 3070 section 10 for an exception case where PE1 will accept a packet even 3071 if it is from an unexpected upstream PE.) 3073 The method used by an egress PE to determine the ingress PE for a 3074 particular packet, received over a particular PMSI, depends on the P- 3075 tunnel technology that is used to instantiate the PMSI. If the P- 3076 tunnel is a P2MP LSP, a PIM-SM or PIM-SSM tree, or a unicast P- 3077 tunnel, then the tunnel encapsulation contains information that can 3078 be used (possibly along with other state information in the PE) to 3079 determine the ingress PE, as long as the P-tunnel is instantiating an 3080 intra-AS PMSI, or an inter-AS PMSI which is supported by a non- 3081 segmented inter-AS tunnel. 3083 Even when inter-AS segmented P-tunnels are used, if an aggregated S- 3084 PMSI is used for carrying the packets, the tunnel encapsulation must 3085 have some information that can be used to identify the PMSI, and that 3086 in turn implicitly identifies the ingress PE. 3088 If an I-PMSI is used for carrying the packets, the I-PMSI spans 3089 multiple ASes, and the I-PMSI is realized via segmented inter-AS P- 3090 tunnels, if C-S or C-RP is multi-homed to different PEs, as long as 3091 each such PE is in a different AS, the egress PE can detect duplicate 3092 traffic as such duplicate traffic will arrive on a different (inter- 3093 AS) P-tunnel. Specifically, if the PE was expecting the traffic on an 3094 particular inter-AS P-tunnel, duplicate traffic will arrive either on 3095 an intra-AS P-tunnel [this is not an intra-AS P-tunnel segment, of an 3096 inter-AS P-tunnel], or on some other inter-AS P-tunnel. Therefore, 3097 to detect duplicates the PE has to keep track of which (inter-AS) 3098 auto-discovery route the PE uses for sending MVPN multicast routing 3099 information towards C-S/C-RP. Then the PE should receive (multicast) 3100 traffic originated by C-S/C-RP only from the (inter-AS) P-tunnel that 3101 was carried in the best Inter-AS auto-discovery route for the MVPN 3102 and was originated by the AS that contains C-S/C-RP (where "the best" 3103 is determined by the PE). The PE should discard, as duplicated, all 3104 other multicast traffic originated by C-S/C-RP, but received on any 3105 other P-tunnel. 3107 9.1.1. Single forwarder PE selection 3109 When for a given MVPN (a) MI-PMSI is used for carrying multicast data 3110 packets, (b) the MI-PMSI is instantiated by a segmented Inter-AS P- 3111 tunnel, (c) C-S or C-RP is multi-homed to different PEs, and (d) at 3112 least two of such PEs are in the same AS, then depending on the 3113 tunneling technology used to instantiate the MI-PMSI, it may not 3114 always be possible for the egress PE to determine the upstream PE. 3115 Therefore, when this determination may not be possible, procedures 3116 are needed to ensure that packets are received on an MI-PMSI at an 3117 egress PE only from a single upstream PE. Furthermore, even if the 3118 determination is possible, it may be preferable to send only one copy 3119 of each packet to each egress PE, rather than sending multiple copies 3120 and having the egress PE discard all but one. 3122 Section 5.1 specifies a procedure for choosing a "default upstream PE 3123 selection", such that (except during routing transients) all PEs will 3124 choose the same default upstream PE. To ensure that duplicate 3125 packets are not sent through the backbone (except during routing 3126 transients), an ingress PE does not forward to the backbone any (C- 3127 S,C-G) multicast data packet it receives from a CE, unless the PE is 3128 the default upstream PE selection. 3130 This procedure is optional whenever the P-tunnel technology that is 3131 being used to carry the multicast stream in question allows the 3132 egress PEs to determine the identity of the ingress PE. This 3133 procedure is mandatory if the P-tunnel technology does not make this 3134 determination possible. 3136 The above procedure ensures that if C-S or C-RP is multi-homed to PEs 3137 within a single AS, a PE will not receive duplicate traffic as long 3138 as all the PEs are on either the C-S or C-RP tree. If some PEs are on 3139 the C-S tree and some on the C-RP tree, however, packet duplication 3140 is still possible. This is discussed in the next section. 3142 9.2. Switching from the C-RP tree to C-S tree 3144 If some PEs are on the C-S tree and some on the R-RP tree then a PE 3145 may also receive duplicate traffic during a to 3146 switch. The issue and the solution are described next. 3148 When for a given MVPN (a) MI-PMSI is used for carrying multicast data 3149 packets, (b) C-S and C-RP are connected to PEs within the same AS, 3150 and (c) the MI-PMSI tunneling technology in use does not allow the 3151 egress PEs to identify the ingress PE, then having all the PEs select 3152 the same PE to be the upstream multicast hop for C-S or C-RP is not 3153 sufficient to prevent packet duplication. 3155 The reason is that a single P-tunnel used by MI-PMSI may be carrying 3156 traffic on both the (C-*,C-G) tree and the (C-S,C-G) tree. If some of 3157 the egress PEs have joined the source tree, but others expect to 3158 receive (C-S,C-G) packets from the shared tree, then two copies of 3159 data packet will travel on the P-tunnel, and since due to the choice 3160 of the tunneling technology the egress PEs have no way to identify 3161 the ingress PE, the egress PEs will have no way to determine that 3162 only one copy should be accepted. 3164 To avoid this, it is necessary to ensure that once any PE joins the 3165 (C-S, C-G) tree, any other PE that has joined the (C-*, C- G) tree 3166 also switches to the (C-S,C-G) tree (selecting, of course, the same 3167 upstream multicast hop, as specified above). 3169 Whenever a PE creates an state as a result of receiving a 3170 C-multicast route for from some other PE, and the C-G 3171 group is an ASM group, the PE that creates the state MUST originate a 3172 Source Active auto-discovery route (see [MVPN-BGP] section 4.5) as 3173 specified below. The route is advertised using the same procedures as 3174 the MVPN auto-discovery/binding (both intra-AS and inter-AS) 3175 specified in this document with the following modifications: 3177 1. The Multicast Source field MUST be set to C-S. The Multicast 3178 Source Length field is set appropriately to reflect this. 3180 2. The Multicast Group field MUST be set to C-G. The Multicast 3181 Group Length field is set appropriately to reflect this. 3183 The route goes to all the PEs of the MVPN. When as a result of 3184 receiving a new Source Active auto-discovery route a PE updates its 3185 VRF with the route, the PE MUST check if the newly received route 3186 matches any entries. If (a) there is a matching entry, (b) 3187 the PE does not have (C-S,C-G) state in its MVPN-TIB for (C-S,C-G) 3188 carried in the route, and (c) the received route is selected as the 3189 best (using the BGP route selection procedures), then the PE sets up 3190 its forwarding path to receive (C-S,C-G) traffic from the P-tunnel 3191 the originator of the selected Source Active auto-discovery route 3192 uses for sending (C-S,C-G). This procedures forces all the PEs (in 3193 all ASes) to switch from the C-RP tree to the C-S tree for . 3196 (Additional uses of the Source Active A-D route are discussed in 3197 section 10.) 3199 Note that when a PE thus joins the tree, it may need to 3200 send a PIM (S,G,RPT-bit) prune to one of its CE PIM neighbors, as 3201 determined by ordinary PIM procedures. (This will be the case if the 3202 incoming interface for the (C-*,C-G) tree is one of the VRF 3203 interfaces.) However, before doing this, it SHOULD run a timer to 3204 help ensure that the source is not pruned from the shared tree until 3205 all PEs have had time to receive the Source Active route. 3207 Whenever the PE deletes the state that was previously 3208 created as a result of receiving a C-multicast route for 3209 from some other PE, the PE that deletes the state also withdraws the 3210 auto-discovery route that was advertised when the state was created. 3212 N.B.: SINCE ALL PEs WITH RECEIVERS FOR GROUP C-G WILL JOIN THE C-S 3213 SOURCE TREE IF ANY OF THEM DO, IT IS NEVER NECESSARY TO DISTRIBUTE A 3214 BGP C-MULTICAST ROUTE FOR THE PURPOSE OF PRUNING SOURCES FROM THE 3215 SHARED TREE. 3217 It is worth nothing that if a PE joins a source tree as a result of 3218 this procedure, the UMH is not necessarily the same as it would be if 3219 the PE had joined the source tree as a result of receiving a PIM Join 3220 for the same source tree from a directly attached CE. 3222 10. Eliminating PE-PE Distribution of (C-*,C-G) State 3224 In the ASM service model, a node that wants to become a receiver for 3225 a particular multicast group G first joins a shared tree, rooted at a 3226 rendezvous point. When the receiver detects traffic from a 3227 particular source it has the option of joining a source tree, rooted 3228 at that source. If it does so, it has to prune that source from the 3229 shared tree, to ensure that it receives packets from that source on 3230 only one tree. 3232 Maintaining the shared tree can require considerable state, as it is 3233 necessary not only to know who the upstream and downstream nodes are, 3234 but to know which sources have been pruned off which branches of the 3235 share tree. 3237 The BGP-based signaling procedures defined in this document and in 3238 [MVPN-BGP] eliminate the need for PEs to distribute to each other any 3239 state having to do with which sources have been pruned off a shared 3240 C-tree. Those procedures do still allow multicast data traffic to 3241 travel on a shared C-tree, but they do not allow a situation in which 3242 some CEs receive (S,G) traffic on a shared tree and some on a source 3243 tree. This results in a considerable simplification of the PE-PE 3244 procedures with minimal change to the multicast service seen within 3245 the VPN. However, shared C-trees are still supported across the VPN 3246 backbone. That is, (C-*,C-G) state is distributed PE-PE, but (C-*, 3247 C-G, RPT-bit) state is not. 3249 In this section, we specify a number of optional procedures which go 3250 further, and which completely eliminate the support for shared C- 3251 trees across the VPN backbone. In these procedures, the PEs keep 3252 track of the active sources for each C-G. As soon as a CE tries to 3253 join the (*,G) tree, the PEs instead join the (S,G) trees for all the 3254 active sources. Thus all distribution of (C-*,C-G) state is 3255 eliminated. These procedures are optional because they require some 3256 additional support on the part of the VPN customer, and because they 3257 are not always appropriate. (E.g., a VPN customer may have his own 3258 policy of always using shared trees for certain multicast groups.) 3259 There are several different options, described in the following sub- 3260 sections. 3262 10.1. Co-locating C-RPs on a PE 3264 [MVPN-REQ] describes C-RP engineering as an issue when PIM-SM (or 3265 BIDIR-PIM) is used in "Any Source Multicast (ASM) mode" [RFC4607] on 3266 the VPN customer site. To quote from [MVPN-REQ]: 3268 "In some cases this engineering problem is not trivial: for instance, 3269 if sources and receivers are located in VPN sites that are different 3270 than that of the RP, then traffic may flow twice through the SP 3271 network and the CE-PE link of the RP (from source to RP, and then 3272 from RP to receivers) ; this is obviously not ideal. A multicast VPN 3273 solution SHOULD propose a way to help on solving this RP engineering 3274 issue." 3276 One of the C-RP deployment models is for the customer to outsource 3277 the RP to the provider. In this case the provider may co-locate the 3278 RP on the PE that is connected to the customer site [MVPN-REQ]. This 3279 section describes how anycast-RP can be used for achieving this. This 3280 is described below. 3282 10.1.1. Initial Configuration 3284 For a particular MVPN, at least one or more PEs that have sites in 3285 that MVPN, act as an RP for the sites of that MVPN connected to these 3286 PEs. Within each MVPN all these RPs use the same (anycast) address. 3287 All these RPs use the Anycast RP technique. 3289 10.1.2. Anycast RP Based on Propagating Active Sources 3291 This mechanism is based on propagating active sources between RPs. 3293 10.1.2.1. Receiver(s) Within a Site 3295 The PE that receives C-Join for (*,G) does not send the information 3296 that it has receiver(s) for G until it receives information about 3297 active sources for G from an upstream PE. 3299 On receiving this (described in the next section), the downstream PE 3300 will respond with Join for C-(S,G). Sending this information could be 3301 done using any of the procedures described in section 5. Only the 3302 upstream PE will process this information. 3304 10.1.2.2. Source Within a Site 3306 When a PE receives PIM-Register from a site that belongs to a given 3307 VPN, PE follows the normal PIM anycast RP procedures. It then 3308 advertises the source and group of the multicast data packet carried 3309 in PIM-Register message to other PEs in BGP using the following 3310 information elements: 3312 - Active source address 3314 - Active group address 3316 - Route target of the MVPN. 3318 This advertisement goes to all the PEs that belong to that MVPN. When 3319 a PE receives this advertisement, it checks whether there are any 3320 receivers in the sites attached to the PE for the group carried in 3321 the source active advertisement. If yes, then it generates an 3322 advertisement for C-(S,G) as specified in the previous section. 3324 Note that the mechanism described in section 7.4.1 can be leveraged 3325 to advertise a S-PMSI binding along with the source active messages. 3326 This is accomplished by using the same BGP Update message to carry 3327 both the NLRI of the S-PMSI A-D route and the NLRI of the Source 3328 Active A-D route. 3330 10.1.2.3. Receiver Switching from Shared to Source Tree 3332 No additional procedures are required when multicast receivers in 3333 customer's site shift from shared tree to source tree. 3335 10.2. Using MSDP between a PE and a Local C-RP 3337 Section 10.1 describes the case where each PE is a C-RP. This 3338 enables the PEs to know the active multicast sources for each MVPN, 3339 and they can then use BGP to distribute this information to each 3340 other. As a result, the PEs do not have to join any shared C-trees, 3341 and this results in a simplification of the PE operation. 3343 In another deployment scenario, the PEs are not themselves C-RPs, but 3344 use MSDP [RFC3618] to talk to the C-RPs. In particular, a PE that 3345 attaches to a site that contains a C-RP becomes an MSDP peer of that 3346 C-RP. That PE then uses BGP to distribute the information about the 3347 active sources to the other PEs. When the PE determines, by MSDP, 3348 that a particular source is no longer active, then it withdraws the 3349 corresponding BGP update. Then the PEs do not have to join any 3350 shared C-trees, but they do not have to be C-RPs either. 3352 MSDP provides the capability for a Source Active (SA) message to 3353 carry an encapsulated data packet. This capability can be used to 3354 allow an MSDP speaker to receive the first (or first several) 3355 packet(s) of an (S,G) flow, even though the MSDP speaker hasn't yet 3356 joined the (S,G) tree. (Presumably it will join that tree as a 3357 result of receiving the SA message that carries the encapsulated data 3358 packet.) If this capability is not used, the first several data 3359 packets of an (S,G) stream may be lost. 3361 A PE that is talking MSDP to an RP may receive such an encapsulated 3362 data packet from the RP. The data packet should be decapsulated and 3363 transmitted to the other PEs in the MVPN. If the packet belongs to a 3364 particular (S,G) flow, and if the PE is a transmitter for some S-PMSI 3365 to which (S,G) has already been bound, the decapsulated data packet 3366 should be transmitted on that S-PMSI. Otherwise, if an I-PMSI exists 3367 for that MVPN, the decapsulated data packet should be transmitted on 3368 it. (If a MI-PMSI exists, this would typically be used.) If neither 3369 of these conditions hold, the decapsulated data packet is not 3370 transmitted to the other PEs in the MVPN. The decision as to whether 3371 and how to transmit the decapsulated data packet does not effect the 3372 processing of the SA control message itself. 3374 Suppose that PE1 transmits a multicast data packet on a PMSI, where 3375 that data packet is part of an (S,G) flow, and PE2 receives that 3376 packet from that PMSI. According to section 9, if PE1 is not the PE 3377 that PE2 expects to be transmitting (S,G) packets, then PE2 must 3378 discard the packet. If an MSDP-encapsulated data packet is 3379 transmitted on a PMSI as specified above, this rule from section 9 3380 would likely result in the packet's getting discarded. Therefore, if 3381 MSDP-encapsulated data packets being decapsulated and transmitted on 3382 a PMSI, we need to modify the rules of section 9 as follows: 3384 1. If the receiving PE, PE2, has already joined the (S,G) tree, 3385 and has chosen PE1 as the upstream PE for the (S,G) tree, but 3386 this packet does not come from PE1, PE2 must discard the 3387 packet. 3389 2. If the receiving PE, PE2, has not already joined the (S,G) 3390 tree, but is a PIM adjacency to a CE that is downstream on the 3391 (*,G) tree, the packet should be forwarded to the CE. 3393 11. Support for PIM-BIDIR C-Groups 3395 In BIDIR-PIM, each multicast group is associated with an RPA 3396 (Rendezvous Point Address). The Rendezvous Point Link (RPL) is the 3397 link that attaches to the RPA. Usually it's a LAN where the RPA is 3398 in the IP subnet assigned to the LAN. The root node of a BIDIR-PIM 3399 tree is a node that has an interface on the RPL. 3401 On any LAN (other than the RPL) that is a link in a PIM-bidir tree, 3402 there must be a single node that has been chosen to be the DF. (More 3403 precisely, for each RPA there is a single node that is the DF for 3404 that RPA.) A node that receives traffic from an upstream interface 3405 may forward it on a particular downstream interface only if the node 3406 is the DF for that downstream interface. A node that receives 3407 traffic from a downstream interface may forward it on an upstream 3408 interface only if that node is the DF for the downstream interface. 3410 If, for any period of time, there is a link on which each of two 3411 different nodes believes itself to be the DF, data forwarding loops 3412 can form. Loops in a bidirectional multicast tree can be very 3413 harmful. However, any election procedure will have a convergence 3414 period. The BIDIR-PIM DF election procedures is very complicated, 3415 because it goes to great pains to ensure that if convergence is not 3416 extremely fast, then there is no forwarding at all until convergence 3417 has taken place. 3419 Other variants of PIM also have a DF election procedure for LANs. 3420 However, as long as the multicast tree is unidirectional, 3421 disagreement about who the DF is can result only in duplication of 3422 packets, not in loops. Therefore the time taken to converge on a 3423 single DF is of much less concern for unidirectional trees and it is 3424 for bidirectional trees. 3426 In the MVPN environment, if PIM signaling is used among the PEs, the 3427 the standard LAN-based DF election procedure can be used. However, 3428 election procedures that are optimized for a LAN may not work as well 3429 in the MVPN environment. So an alternative to DF election would be 3430 desirable. 3432 If BGP signaling is used among the PEs, an alternative to DF election 3433 is necessary. One might think that use the "single forwarder 3434 selection" procedures described in sections 5 and 9 could be used to 3435 choose a single PE "DF" for the backbone (for a given RPA in a given 3436 MVPN). However, that is still likely to leave a convergence period 3437 of at least several seconds during which loops could form, and there 3438 could be a much longer convergence period if there is anything 3439 disrupting the smooth flow of BGP updates. So a simple procedure 3440 like that is not sufficient. 3442 The remainder of this section describes two different methods that 3443 can be used to support BIDIR-PIM while eliminating the DF election. 3445 11.1. The VPN Backbone Becomes the RPL 3447 On a per MVPN basis, this method treats the whole service provider(s) 3448 infrastructure as a single RPL (RP Link). We refer to such an RPL as 3449 an "MVPN-RPL". This eliminates the need for the PEs to engage in any 3450 "DF election" procedure, because PIM-bidir does not have a DF on the 3451 RPL. 3453 However, this method can only be used if the customer is 3454 "outsourcing" the RPL/RPA functionality to the SP. 3456 An MVPN-RPL could be realized either via an I-PMSI (this I-PMSI is on 3457 a per MVPN basis and spans all the PEs that have sites of a given 3458 MVPN), or via a collection of S-PMSIs, or even via a combination of 3459 an I-PMSI and one or more S-PMSIs. 3461 11.1.1. Control Plane 3463 Associated with each MVPN-RPL is an address prefix that is 3464 unambiguous within the context of the MVPN associated with the MVPN- 3465 RPL. 3467 For a given MVPN, each VRF connected to an MVPN-RPL of that MVPN is 3468 configured to advertise to all of its connected CEs the address 3469 prefix of the MVPN-RPL. 3471 Since in PIM Bidir there is no Designated Forwarder on an RPL, in the 3472 context of MVPN-RPL there is no need to perform the Designated 3473 Forwarder election among the PEs (note there is still necessary to 3474 perform the Designated Forwarder election between a PE and its 3475 directly attached CEs, but that is done using plain PIM Bidir 3476 procedures). 3478 For a given MVPN a PE connected to an MVPN-RPL of that MVPN should 3479 send multicast data (C-S,C-G) on the MVPN-RPL only if at least one 3480 other PE connected to the MVPN-RPL has a downstream multicast state 3481 for C-G. In the context of MVPN this is accomplished by requiring a 3482 PE that has a downstream state for a particular C-G of a particular 3483 VRF present on the PE to originate a C-multicast route for (*, C-G). 3484 The RD of this route should be the same as the RD associated with the 3485 VRF. The RT(s) carried by the route should be the same as the one(s) 3486 used for VPN-IPv4 routes. This route will be distributed to all the 3487 PEs of the MVPN. 3489 11.1.2. Data Plane 3491 A PE that receives (C-S,C-G) multicast data from a CE should forward 3492 this data on the MVPN-RPL of the MVPN the CE belongs to only if the 3493 PE receives at least one C-multicast route for (*, C-G). Otherwise, 3494 the PE should not forward the data on the RPL/I-PMSI. 3496 When a PE receives a multicast packet with (C-S,C-G) on an MVPN-RPL 3497 associated with a given MVPN, the PE forwards this packet to every 3498 directly connected CE of that MVPN, provided that the CE sends Join 3499 (*,C-G) to the PE (provided that the PE has the downstream (*,C-G) 3500 state). The PE does not forward this packet back on the MVPN-RPL. If 3501 a PE has no downstream (*,C-G) state, the PE does not forward the 3502 packet. 3504 11.2. Partitioned Sets of PEs 3506 This method does not require the use of the MVPN-RPL, and does not 3507 require the customer to outsource the RPA/RPL functionality to the 3508 SP. 3510 11.2.1. Partitions 3512 Consider a particular C-RPA, call it C-R, in a particular MVPN. 3513 Consider the set of PEs that attach to sites that have senders or 3514 receivers for a BIDIR-PIM group C-G, where C-R is the RPA for C-G. 3515 (As always we use the "C-" prefix to indicate that we are referring 3516 to an address in the VPN's address space rather than in the 3517 provider's address space.) 3519 Following the procedures of section 5.1, each PE in the set 3520 independently chooses some other PE in the set to be its "upstream 3521 PE" for those BIDIR-PIM groups with RPA C-R. Optionally, they can 3522 all choose the "default selection" (described in section 5.1), to 3523 ensure that each PE to choose the same upstream PE. Note that if a 3524 PE has a route to C-R via a VRF interface, then the PE may choose 3525 itself as the upstream PE. 3527 The set of PEs can now be partitioned into a number of subsets. 3528 We'll say that PE1 and PE2 are in the same partition if and only if 3529 there is some PE3 such that PE1 and PE2 have each chosen PE3 as the 3530 upstream PE for C-R. Note that each partition has exactly one 3531 upstream PE. So it is possible to identify the partition by 3532 identifying its upstream PE. 3534 Consider packet P, and let PE1 be its ingress PE. PE1 will send the 3535 packet on a PMSI so that it reaches the other PEs that need to 3536 receive it. This is done by encapsulating the packet and sending it 3537 on a P-tunnel. If the original packet is part of a PIM-BIDIR group 3538 (its ingress PE determines this from the packet's destination address 3539 C-G), and if the VPN backbone is not the RPL, then the encapsulation 3540 MUST carry information that can be used to identify the partition to 3541 which the ingress PE belongs. 3543 When PE2 receives a packet from the PMSI, PE2 must determine, by 3544 examining the encapsulation, whether the packet's ingress PE belongs 3545 to the same partition (relative to the C-RPA of the packet's C-G) 3546 that PE2 itself belongs to. If not, PE2 discards the packet. 3547 Otherwise PE2 performs the normal BIDIR-PIM data packet processing. 3548 With this rule in place, harmful loops cannot be introduced by the 3549 PEs into the customer's bidirectional tree. 3551 Note that if there is more than one partition, the VPN backbone will 3552 not carry a packet from one partition to another. The only way for a 3553 packet to get from one partition to another is for it to go up 3554 towards the RPA and then to go down another path to the backbone. If 3555 this is not considered desirable, then all PEs should choose the same 3556 upstream PE for a given C-RPA. Then multiple partitions will only 3557 exist during routing transients. 3559 11.2.2. Using PE Distinguisher Labels 3561 If a given P-tunnel is to be used to carry packets traveling along a 3562 bidirectional C-tree, then, EXCEPT for the case described in sections 3563 11.1 and 11.2.3, the packets that travel on that P-tunnel MUST carry 3564 a PE Distinguisher Label (defined in section 4), using the 3565 encapsulation discussed in section 12.3. 3567 When a given PE transmits a given packet of a bidirectional C-group 3568 to the P-tunnel, the packet will carry the PE Distinguisher Label 3569 corresponding to the partition, for the C-group's C-RPA, that 3570 contains the transmitting PE. This is the PE Distinguisher Label 3571 that has been bound to the upstream PE of that partition; it is not 3572 necessarily the label that has been bound to the transmitting PE. 3574 Recall that the PE Distinguisher Labels are upstream-assigned labels 3575 that are assigned and advertised by the node that is at the root of 3576 the P-tunnel. The information about PE Distinguisher labels is 3577 distributed with Intra-AS I-PMSI A-D routes and/or S-PMSI A-D routes 3578 by encoding it into the PE Distinguisher Label attribute carried by 3579 these routes 3581 When a PE receives a packet with a PE label that does not identify 3582 the partition of the receiving PE, then the receiving PE discards the 3583 packet. 3585 Note that this procedure does not necessarily require the root of a 3586 P-tunnel to assign a PE Distinguisher Label for every PE that belongs 3587 to the tunnel. The the root of the P-tunnel is the only PE that can 3588 transmit packets to the P-tunnel, then the root needs to assign PE 3589 Distinguisher Labels only for those PEs that the root has selected to 3590 be the UMHs for the particular C-RPAs known to the root. 3592 11.2.3. Partial Mesh of MP2MP P-Tunnels 3594 There is one case in which support for BIDIR-PIM C-groups does not 3595 require the use of a PE Distinguisher Label. For a given C-RPA, 3596 suppose a distinct MP2MP LSP is used as the P-tunnel serving that 3597 partition. Then for a given packet, a PE receiving the packet from a 3598 P-tunnel can be inferred the partition from the tunnel. So PE 3599 Distinguisher Labels are not needed in this case. 3601 12. Encapsulations 3603 The BGP-based auto-discovery procedures will ensure that the PEs in a 3604 single MVPN only use tunnels that they can all support, and for a 3605 given kind of tunnel, that they only use encapsulations that they can 3606 all support. 3608 12.1. Encapsulations for Single PMSI per P-Tunnel 3610 12.1.1. Encapsulation in GRE 3612 GRE encapsulation can be used for any PMSI that is instantiated by a 3613 mesh of unicast P-tunnels, as well as for any PMSI that is 3614 instantiated by one or more PIM P-tunnels of any sort. 3616 Packets received Packets in transit Packets forwarded 3617 at ingress PE in the service by egress PEs 3618 provider network 3620 +---------------+ 3621 | P-IP Header | 3622 +---------------+ 3623 | GRE | 3624 ++=============++ ++=============++ ++=============++ 3625 || C-IP Header || || C-IP Header || || C-IP Header || 3626 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 3627 || C-Payload || || C-Payload || || C-Payload || 3628 ++=============++ ++=============++ ++=============++ 3630 The IP Protocol Number field in the P-IP Header MUST be set to 47. 3631 The Protocol Type field of the GRE Header is set to either 0x800 or 3632 0x86dd, depending on whether the C-IP Header is IPv4 or IPv6 3633 respectively.. 3635 When an encapsulated packet is transmitted by a particular PE, the 3636 source IP address in the P-IP header must be the same address that 3637 the PE uses to identify itself in the VRF Route Import Extended 3638 Communities that it attaches to any of VPN-IP routes eligible for UMH 3639 determination that it advertises via BGP (see section 5.1). 3641 If the PMSI is instantiated by a PIM tree, the destination IP address 3642 in the P-IP header is the group P-address associated with that tree. 3643 The GRE key field value is omitted. 3645 If the PMSI is instantiated by unicast P-tunnels, the destination IP 3646 address is the address of the destination PE, and the optional GRE 3647 Key field is used to identify a particular MVPN. In this case, each 3648 PE would have to advertise a key field value for each MVPN; each PE 3649 would assign the key field value that it expects to receive. 3651 [RFC2784] specifies an optional GRE checksum, and [RFC2890] specifies 3652 an optional GRE sequence number fields. 3654 The GRE sequence number field is not needed because the transport 3655 layer services for the original application will be provided by the 3656 C-IP Header. 3658 The use of GRE checksum field must follow [RFC2784]. 3660 To facilitate high speed implementation, this document recommends 3661 that the ingress PE routers encapsulate VPN packets without setting 3662 the checksum, or sequence fields. 3664 12.1.2. Encapsulation in IP 3666 IP-in-IP [RFC1853] is also a viable option. The following diagram 3667 shows the progression of the packet as it enters and leaves the 3668 service provider network. 3670 Packets received Packets in transit Packets forwarded 3671 at ingress PE in the service by egress PEs 3672 provider network 3674 +---------------+ 3675 | P-IP Header | 3676 ++=============++ ++=============++ ++=============++ 3677 || C-IP Header || || C-IP Header || || C-IP Header || 3678 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 3679 || C-Payload || || C-Payload || || C-Payload || 3680 ++=============++ ++=============++ ++=============++ 3682 When the P-IP Header is an IPv4 header, its Protocol Number field is 3683 set to either 4 or 41, depending on whether the C-IP header is an 3684 IPv4 header or an IPv6 header, respectively. 3686 When the P-IP Header is an IPv6 header, its Next Header field is set 3687 to either 4 or 41, depending on whether the C-IP header is an IPv4 3688 header or an IPv6 header, respectively. 3690 When an encapsulated packet is transmitted by a particular PE, the 3691 source IP address in the P-IP header must be the same address that 3692 the PE uses to identify itself in the VRF Route Import Extended 3693 Communities that it attaches to any of VPN-IP routes eligible for UMH 3694 determination that it advertises via BGP (see section 5.1). 3696 12.1.3. Encapsulation in MPLS 3698 If the PMSI is instantiated as a P2MP MPLS LSP or a MP2MP LSP, MPLS 3699 encapsulation is used. Penultimate-hop-popping MUST be disabled for 3700 the LSP. 3702 If other methods of assigning MPLS labels to multicast distribution 3703 trees are in use, these multicast distribution trees may be used as 3704 appropriate to instantiate PMSIs, and appropriate additional MPLS 3705 encapsulation procedures may be used. 3707 Packets received Packets in transit Packets forwarded 3708 at ingress PE in the service by egress PEs 3709 provider network 3711 +---------------+ 3712 | P-MPLS Header | 3713 ++=============++ ++=============++ ++=============++ 3714 || C-IP Header || || C-IP Header || || C-IP Header || 3715 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 3716 || C-Payload || || C-Payload || || C-Payload || 3717 ++=============++ ++=============++ ++=============++ 3719 12.2. Encapsulations for Multiple PMSIs per P-Tunnel 3721 The encapsulations for transmitting multicast data messages when 3722 there are multiple PMSIs per P-tunnel are based on the encapsulation 3723 for a single PMSI per P-tunnel, but with an MPLS label used for 3724 demultiplexing. 3726 The label is upstream-assigned and distributed via BGP as specified 3727 in section 4. The label must enable the receiver to select the 3728 proper VRF, and may enable the receiver to select a particular 3729 multicast routing entry within that VRF. 3731 12.2.1. Encapsulation in GRE 3733 Rather than the IP-in-GRE encapsulation discussed in section 12.1.1, 3734 we use the MPLS-in-GRE encapsulation. This is specified in [MPLS- 3735 IP]. The GRE protocol type MUST be set to 0x8847. [The reason for 3736 using the unicast rather than the multicast value is specified in 3737 [MPLS-MCAST-ENCAPS]. 3739 12.2.2. Encapsulation in IP 3741 Rather than the IP-in-IP encapsulation discussed in section 12.1.2, 3742 we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP]. 3743 The IP protocol number MUST be set to the value identifying the 3744 payload as an MPLS unicast packet. (There is no "MPLS multicast 3745 packet" protocol number.) 3747 12.3. Encapsulations Identifying a Distinguished PE 3749 12.3.1. For MP2MP LSP P-tunnels 3751 As discussed in section 9, if a multicast data packet is traveling on 3752 a unidirectional C-tree, it is highly desirable for the PE that 3753 receives the packet from a PMSI to be able to determine the identity 3754 of the PE that transmitted the data packet onto the PMSI. The 3755 encapsulations of the previous sections all provide this information, 3756 except in one case. If a PMSI is being instantiated by a MP2MP LSP, 3757 then the encapsulations discussed so far do not allow one to 3758 determine the identity of the PE that transmitted the packet onto the 3759 PMSI. 3761 Therefore, when a packet traveling on a unidirectional C-tree is 3762 traveling on a MP2MP LSP P-tunnel, it MUST carry, as its second 3763 label, a label that has been bound to the packet's ingress PE. This 3764 label is an upstream-assigned label that the LSP's root node has 3765 bound to the ingress PE and has distributed via the PE Distinguisher 3766 Labels attribute of a PMSI A-D Route (see section 4). This label 3767 will appear immediately beneath the labels that are discussed in 3768 sections 12.1.3 and 12.2. 3770 A full specification of the procedures for advertising and for using 3771 the PE Distinguisher Labels in this case is outside the scope of this 3772 document. 3774 12.3.2. For Support of PIM-BIDIR C-Groups 3776 As will be discussed in section 11, when a packet belongs to a PIM- 3777 BIDIR multicast group, the set of PEs of that packet's VPN can be 3778 partitioned into a number of subsets, where exactly one PE in each 3779 partition is the upstream PE for that partition. When such packets 3780 are transmitted on a PMSI, then unless the procedures of section 3781 12.2.3 are being used, it is necessary for the packet to carry 3782 information identifying a particular partition. This is done by 3783 having the packet carry the PE Distinguisher Label corresponding to 3784 the upstream PE of one partition. For a particular P-tunnel, this 3785 label will have been advertised by the node that is the root of that 3786 P-tunnel. (A full specification of the procedures for advertising PE 3787 Distinguisher Labels is out of the scope of this document.) 3789 This label needs to be used whenever a packet belongs to a PIM-BIDIR 3790 C-group, no matter what encapsulation is used by the P-tunnel. Hence 3791 the encapsulations of section 11.2 MUST be used. If the P-tunnel 3792 contains only one PMSI, the PE label replaces the label discussed in 3793 section 12.2 If the P-tunnel contains multiple PMSIs, the PE label 3794 follows the label discussed in section 12.2. 3796 In general, PE Distinguisher Labels can be carried if the 3797 encapsulation is MPLS or MPLS-in-IP or MPLS-in-GRE. However, 3798 procedures for advertising and using PE Distinguisher Labels when the 3799 encapsulation is LDP-based MP2P MPLS is outside the scope of this 3800 specification. 3802 12.4. General Considerations for IP and GRE Encaps 3804 These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations. 3806 12.4.1. MTU (Maximum Transmission Unit) 3808 It is the responsibility of the originator of a C-packet to ensure 3809 that the packet is small enough to reach all of its destinations, 3810 even when it is encapsulated within IP or GRE. 3812 When a packet is encapsulated in IP or GRE, the router that does the 3813 encapsulation MUST set the DF bit in the outer header. This ensures 3814 that the decapsulating router will not need to reassemble the 3815 encapsulating packets before performing decapsulation. 3817 In some cases the encapsulating router may know that a particular C- 3818 packet is too large to reach its destinations. Procedures by which 3819 it may know this are outside the scope of the current document. 3820 However, if this is known, then: 3822 - If the DF bit is set in the IP header of a C-packet that is known 3823 to be too large, the router will discard the C-packet as being 3824 "too large", and follow normal IP procedures (which may require 3825 the return of an ICMP message to the source). 3827 - If the DF bit is not set in the IP header of a C-packet that is 3828 known to be too large, the router MAY fragment the packet before 3829 encapsulating it, and then encapsulate each fragment separately. 3830 Alternatively, the router MAY discard the packet. 3832 If the router discards a packet as too large, it should maintain OAM 3833 information related to this behavior, allowing the operator to 3834 properly troubleshoot the issue. 3836 Note that if the entire path of the P-tunnel does not support an MTU 3837 that is large enough to carry the a particular encapsulated C-packet, 3838 and if the encapsulating router does not do fragmentation, then the 3839 customer will not receive the expected connectivity. 3841 12.4.2. TTL (Time to Live) 3843 The ingress PE should not copy the TTL field from the payload IP 3844 header received from a CE router to the delivery IP or MPLS header. 3845 The setting of the TTL of the delivery header is determined by the 3846 local policy of the ingress PE router. 3848 12.4.3. Avoiding Conflict with Internet Multicast 3850 If the SP is providing Internet multicast, distinct from its VPN 3851 multicast services, and using PIM based P-multicast trees, it must 3852 ensure that the group P-addresses that it used in support of MPVN 3853 services are distinct from any of the group addresses of the Internet 3854 multicasts it supports. This is best done by using administratively 3855 scoped addresses [ADMIN-ADDR]. 3857 The group C-addresses need not be distinct from either the group P- 3858 addresses or the Internet multicast addresses. 3860 12.5. Differentiated Services 3862 The setting of the DS (Differentiated Services) field in the delivery 3863 IP header should follow the guidelines outlined in [RFC2983]. 3864 Setting the EXP field in the delivery MPLS header should follow the 3865 guidelines in [RFC3270]. An SP may also choose to deploy any of 3866 additional Differentiated Services mechanisms that the PE routers 3867 support for the encapsulation in use. Note that the type of 3868 encapsulation determines the set of Differentiated Services 3869 mechanisms that may be deployed. 3871 13. Security Considerations 3873 This document describes an extension to the procedures of [RFC4364], 3874 and hence shares the security considerations described in [RFC4364] 3875 and [RFC4365]. 3877 When GRE encapsulation is used, the security considerations of [MPLS- 3878 IP] are also relevant. The security considerations of [RFC4797] are 3879 also relevant as it discusses implications on packet spoofing in the 3880 context of 2547 VPNs. 3882 The security considerations of [MPLS-HDR] apply when MPLS 3883 encapsulation is used. 3885 This document makes use of a number of control protocols: PIM [PIM- 3886 SM], BGP MVPN-BGP], mLDP [MLDP], and RSVP-TE [RSVP-P2MP]. Security 3887 considerations relevant to each protocol are discussed in the 3888 respective protocol specifications. 3890 If one uses the UDP-based protocol for switching to S-PMSI (as 3891 specified in Section 7.2.1), then by default each PE router MUST 3892 install packet filters that would result in discarding all UDP 3893 packets with the destination port 3232 that the PE router receives 3894 from the CE routers connected to the PE router. 3896 The various procedures for P-tunnel construction have security issues 3897 that are specific to the way in that the P-tunnels are used in this 3898 document. When P-tunnels are constructed via such techniques as as 3899 PIM, mLDP, or RSVP-TE, it is important for each P or PE router 3900 receiving a control message to be sure that the control message comes 3901 from another P or PE router, not from a CE router. This should not 3902 be a problem, because mLDP or PIM or RSVP-TE control messages from CE 3903 routers will never be interpreted as referring to P-tunnels. 3905 An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE 3906 control message that attempts to extend a multicast distribution tree 3907 from one SP's domain into another SP's domain. The ASBR should not 3908 allow this unless explicitly configured to do so. 3910 14. IANA Considerations 3912 Section 7.2.1.1 defines the "S-PMSI Join Message", which is carried 3913 in a UDP datagram whose port number is 3232. This port number is 3914 already assigned by IANA to "MDT port". IANA should now have that 3915 assignment reference this document. 3917 IANA should create a registry for the "S-PMSI Join Message Type 3918 Field". The value 1 should be registered with a reference to this 3919 document. The description should read "PIM IPv4 S-PMSI 3920 (unaggregated)". 3922 [PIM-ATTRIB] establishes a registry for "PIM Join Attribute Types". 3923 IANA should assign the value 1 to the "MVPN Join Attribute", and 3924 should reference this document. 3926 15. Other Authors 3928 Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, IJsbrands 3929 Wijnands, Seisho Yasukawa 3931 16. Other Contributors 3933 Significant contributions were made Arjen Boers, Toerless Eckert, 3934 Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Guiliano, Shankar 3935 Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony 3936 Speakman, Dan Tappan. 3938 17. Authors' Addresses 3940 Rahul Aggarwal (Editor) 3941 Juniper Networks 3942 1194 North Mathilda Ave. 3943 Sunnyvale, CA 94089 3944 Email: rahul@juniper.net 3945 Sarveshwar Bandi 3946 Motorola 3947 Vanenburg IT park, Madhapur, 3948 Hyderabad, India 3949 Email: sarvesh@motorola.com 3951 Yiqun Cai 3952 Cisco Systems, Inc. 3953 170 Tasman Drive 3954 San Jose, CA, 95134 3955 E-mail: ycai@cisco.com 3957 Thomas Morin 3958 France Telecom R & D 3959 2, avenue Pierre-Marzin 3960 22307 Lannion Cedex 3961 France 3962 Email: thomas.morin@francetelecom.com 3964 Yakov Rekhter 3965 Juniper Networks 3966 1194 North Mathilda Ave. 3967 Sunnyvale, CA 94089 3968 Email: yakov@juniper.net 3970 Eric C. Rosen (Editor) 3971 Cisco Systems, Inc. 3972 1414 Massachusetts Avenue 3973 Boxborough, MA, 01719 3974 E-mail: erosen@cisco.com 3976 IJsbrand Wijnands 3977 Cisco Systems, Inc. 3978 170 Tasman Drive 3979 San Jose, CA, 95134 3980 E-mail: ice@cisco.com 3981 Seisho Yasukawa 3982 NTT Corporation 3983 9-11, Midori-Cho 3-Chome 3984 Musashino-Shi, Tokyo 180-8585, 3985 Japan 3986 Phone: +81 422 59 4769 3987 Email: yasukawa.seisho@lab.ntt.co.jp 3989 18. Normative References 3991 [MLDP] I. Minei, K., Kompella, I. Wijnands, B. Thomas, "Label 3992 Distribution Protocol Extensions for Point-to-Multipoint and 3993 Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- 3994 p2mp-05.txt, May 2008 3996 [MPLS-HDR] E. Rosen, et. al., "MPLS Label Stack Encoding", RFC 3032, 3997 January 2001 3999 [MPLS-IP] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP 4000 or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005 4002 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 4003 "MPLS Multicast Encapsulations", draft-ietf-mpls-multicast- 4004 encaps-10.txt, June 2008 4006 [MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS 4007 Upstream Label Assignment and Context Specific Label Space", draft- 4008 ietf-mpls-upstream-label-06.txt, June 2008 4010 [MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. 4011 Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP VPNs", draft- 4012 ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008 4014 [OSPF] J. Moy, "OSPF Version 2", RFC 2328, April 1998 4016 [OSPF-MT} P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- 4017 Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007 4019 [PIM-ATTRIB], A. Boers, IJ. Wijnands, E. Rosen, "The PIM Join 4020 Attribute Format", draft-ietf-pim-join-attributes-04, June 2008 4022 [PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 4023 Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 4025 [RFC2119] "Key words for use in RFCs to Indicate Requirement 4026 Levels.", Bradner, March 1997 4028 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 4030 [RFC4659] "BGP-MPLS IP Virtual Private Network (VPN) Extension for 4031 IPv6 VPN", De Clercq, et. al., RFC 4659, September 2006 4033 [RSVP-OOB] Z. Ali, G. Swallow, R. Aggarwal, "Non PHP behavior and 4034 Out-of-Band Mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no- 4035 php-oob-mapping-01.txt, June 2008 4037 [RSVP-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al., 4038 "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", RFC 4875, 4039 May 2007 4041 19. Informative References 4043 [ADMIN-ADDR] D. Meyer, "Administratively Scoped IP Multicast", RFC 4044 2365, July 1998 4046 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast (BIDIR- 4047 PIM)" M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, RFC 5015, 4048 October 2007 4050 [BSR] "Bootstrap Router (BSR) Mechanism for PIM", N. Bhaskar, et. 4051 al., RFC 5059, January 2008 4053 [MVPN-REQ] T. Morin, Ed., "Requirements for Multicast in L3 Provider- 4054 Provisioned VPNs", RFC 4834, April 2007 4056 [RFC1853] W. Simpson, "IP in IP Tunneling", October 1995 4058 [RFC2784] D. Farinacci, et. al., "Generic Routing Encapsulation", 4059 March 2000 4061 [RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 4062 September 2000 4064 [RFC2983] D. Black, "Differentiated Services and Tunnels", October 4065 2000 4067 [RFC3270] F. Le Faucheur, et. al., "MPLS Support of Differentiated 4068 Services", May 2002 4070 [RFC3618] B. Fenner D. Meyer, "Multicast Source Discovery Protocol", 4071 October 2003 4073 [RFC4365], E. Rosen, " Applicability Statement for BGP/MPLS IP 4074 Virtual Private Networks (VPNs)", February 2006 4076 [RFC4607] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", 4077 August 2006 4079 [RFC4797] Y. Rekhter, R. Bonica, E. Rosen, "Use of Provider Edge to 4080 Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in 4081 BGP/MPLS IP Virtual Private Networks", January 2007 4083 20. Full Copyright Statement 4085 Copyright (C) The IETF Trust (2008). 4087 This document is subject to the rights, licenses and restrictions 4088 contained in BCP 78, and except as set forth therein, the authors 4089 retain all their rights. 4091 This document and the information contained herein are provided on an 4092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4094 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4095 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4096 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4099 21. Intellectual Property 4101 The IETF takes no position regarding the validity or scope of any 4102 Intellectual Property Rights or other rights that might be claimed to 4103 pertain to the implementation or use of the technology described in 4104 this document or the extent to which any license under such rights 4105 might or might not be available; nor does it represent that it has 4106 made any independent effort to identify any such rights. Information 4107 on the procedures with respect to rights in RFC documents can be 4108 found in BCP 78 and BCP 79. 4110 Copies of IPR disclosures made to the IETF Secretariat and any 4111 assurances of licenses to be made available, or the result of an 4112 attempt made to obtain a general license or permission for the use of 4113 such proprietary rights by implementers or users of this 4114 specification can be obtained from the IETF on-line IPR repository at 4115 http://www.ietf.org/ipr. 4117 The IETF invites any interested party to bring to its attention any 4118 copyrights, patents or patent applications, or other proprietary 4119 rights that may cover technology that may be required to implement 4120 this standard. Please address the information to the IETF at 4121 ietf-ipr@ietf.org.