idnits 2.17.1 draft-ietf-l2vpn-vpls-mcast-04.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1801. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the Selective Tree is instantiated by a source-initiated P-multicast tree (e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree MUST establish the source-initiated P-multicast tree to the leaves. This tree MAY have been established before the leaves receive the Selective Tree binding, or MAY be established after the leaves receives the binding. The leaves MUST not switch to the Selective Tree until they receive both the binding and the tree signaling message. -- 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 (June 02, 2008) is 5806 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 (-08) exists of draft-ietf-l2vpn-vpls-bgp-02 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-00 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-multicast-encaps-00 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-05 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-03 -- No information found for draft-ietf-mpls-rsvp-te-no-php-obb-mapping - is the name correct? == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-02 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-mcast-reqts-05 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal (Editor) 3 Internet Draft Juniper Networks 4 Category: Standards Track 5 Expiration Date: December 2008 Y. Kamite 6 NTT Communications 8 L. Fang 9 Cisco Systems, Inc 11 June 02, 2008 13 Multicast in VPLS 15 draft-ietf-l2vpn-vpls-mcast-04.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes a solution for overcoming a subset of the 43 limitations of existing VPLS multicast solutions. It describes 44 procedures for VPLS multicast that utilize multicast trees in the 45 sevice provider (SP) network. One such multicast tree can be shared 46 between multiple VPLS instances. Procedures by which a single 47 multicast tree in the SP network can be used to carry traffic 48 belonging only to a specified set of one or more IP multicast streams 49 from one or more VPLSs are also described. 51 Table of Contents 53 1 Specification of requirements ......................... 4 54 2 Contributors .......................................... 4 55 3 Terminology ........................................... 5 56 4 Introduction .......................................... 5 57 5 Existing Limitations of VPLS Multicast ................ 5 58 6 Overview .............................................. 6 59 6.1 Inclusive and Selective Multicast Trees ............... 6 60 6.2 BGP-Based VPLS Membership Auto-Discovery .............. 7 61 6.3 IP Multicast Group Membership Discovery ............... 8 62 6.4 Advertising P-Tree to VPLS / C-Multicast Binding ...... 8 63 6.5 Aggregation ........................................... 9 64 6.6 Inter-AS VPLS Multicast ............................... 9 65 7 Intra-AS Inclusive Multicast Tree A-D/Binding ......... 10 66 7.1 Originating (intra-AS) auto-discovery routes .......... 11 67 7.2 Receiving (intra-AS) auto-discovery routes ............ 12 68 8 Demultiplexing Multicast Tree Traffic ................. 13 69 8.1 One Multicast Tree - One VPLS Mapping ................. 13 70 8.2 One Multicast Tree - Many VPLS Mapping ................ 13 71 9 Establishing Multicast Trees .......................... 14 72 9.1 RSVP-TE P2MP LSPs ..................................... 14 73 9.1.1 P2MP TE LSP - VPLS Mapping ............................ 15 74 9.1.2 Demultiplexing C-Multicast Data Packets ............... 15 75 9.2 Receiver Initiated MPLS Trees ......................... 16 76 9.2.1 P2MP LSP - VPLS Mapping ............................... 16 77 9.2.2 Demultiplexing C-Multicast Data Packets ............... 16 78 9.3 Encapsulation of the Aggregate Inclusive and Selective Tree 17 79 10 Inter-AS Inclusive Multicast Tree A-D/Binding ......... 17 80 10.1 VSIs on the ASBRs ..................................... 17 81 10.1.1 Option (a) ............................................ 18 82 10.1.2 Option (e) ............................................ 18 83 10.2 Option (b) - Segmented Inter-AS Trees ................. 18 84 10.2.1 Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding .... 19 85 10.2.2 Propagating VPLS BGP A-D routes to other ASes - Overview ..19 86 10.2.2.1 Propagating Intra-AS VPLS A-D routes in E-BGP ......... 21 87 10.2.2.2 A-D route received via E-BGP .......................... 21 88 10.2.2.3 Leaf A-D Route received via E-BGP ..................... 23 89 10.2.2.4 Inter-AS A-D Route received via I-BGP ................. 23 90 10.3 Option (c) ............................................ 25 91 11 Optimizing Multicast Distribution via Selective Trees . 25 92 11.1 Protocol for Switching to Selective Trees ............. 27 93 11.2 Advertising C-(S, G) Binding to a Selective Tree using BGP 27 94 11.2.1 Explicit Tracking ..................................... 28 95 11.3 Inter-AS Selective Tree ............................... 29 96 11.3.1 VSIs on the ASBRs ..................................... 29 97 11.3.1.1 VPLS Inter-AS Selective Tree A-D Binding .............. 29 98 11.3.2 Inter-AS Segmented Selective Trees .................... 29 99 11.3.3 Inter-AS Non-Segmented Selective Trees ................ 31 100 12 BGP Extensions ........................................ 32 101 12.1 Inclusive Tree/Selective Tree Identifier .............. 32 102 12.2 MCAST-VPLS NLRI ....................................... 33 103 12.2.1 Selective Tree auto-discovery route ................... 34 104 12.2.2 Leaf auto-discovery route ............................. 35 105 13 Aggregation Methodology ............................... 35 106 14 Data Forwarding ....................................... 36 107 14.1 MPLS Tree Encapsulation ............................... 36 108 15 VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment 37 109 16 Security Considerations ............................... 38 110 17 IANA Considerations ................................... 38 111 18 Acknowledgments ....................................... 39 112 19 Normative References .................................. 39 113 20 Informative References ................................ 39 114 21 Author's Address ...................................... 40 115 22 Intellectual Property Statement ....................... 41 116 23 Full Copyright Statement .............................. 42 118 1. Specification of requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Contributors 126 Rahul Aggarwal 127 Yakov Rekhter 128 Juniper Networks 129 Yuji Kamite 130 NTT Communications 131 Luyuan Fang 132 AT&T 133 Chaitanya Kodeboniya 135 3. Terminology 137 This document uses terminology described in [RFC4761] and [RFC4762]. 139 4. Introduction 141 [RFC4761] and [RFC4762] describe a solution for VPLS multicast that 142 relies on ingress replication. This solution has certain limitations 143 for certain VPLS multicast traffic profiles. 145 This document describes procedures for overcoming the limitations of 146 existing VPLS multicast solutions. It describes procedures for VPLS 147 multicast that utilize multicast trees in the Sevice Provider (SP) 148 network. The procedures described in this document are applicable to 149 both [RFC4761] and [RFC4762]. 151 It provides mechanisms that allow a single multicast distribution 152 tree in the Service Provider (SP) network to carry all the multicast 153 traffic from one or VPLS sites connected to a given PE, irrespective 154 of whether these sites belong to the same or different VPLSs. Such a 155 tree is referred to as an "Inclusive Tree" and more specifically as 156 an "Aggregate Inclusive Tree" when the tree is used to carry 157 multicast traffic from more than one VPLS. 159 This document also provides procedures by which a single multicast 160 distribution tree in the SP network can be used to carry traffic 161 belonging only to a specified set of IP multicast streams, originated 162 in one or more VPLS sites connected to a given PE, irrespective of 163 whether these sites belong to the same or different VPLSs. Such a 164 tree is referred to as a "Selective Tree" and more specifically as an 165 "Aggregate Selective Tree" when the IP multicast streams belong to 166 different VPLSs. So traffic from most multicast streams could be 167 carried by an Inclusive Tree, while traffic from, e.g., high 168 bandwidth streams could be carried in one of the "Selective Trees". 170 5. Existing Limitations of VPLS Multicast 172 One of the limitations of existing VPLS multicast solutions described 173 in [RFC4761] and [RFC4762] is that they rely on ingress replication. 174 Thus the ingress PE replicates the multicast packet for each egress 175 PE and sends it to the egress PE using a unicast tunnel. 177 This is a reasonable model when the bandwidth of the multicast 178 traffic is low or/and the number of replications performed on an 179 average on each outgoing interface for a particular customer VPLS 180 multicast packet is small. If this is not the case it is desirable to 181 utilize multicast trees in the SP network to transmit VPLS multicast 182 packets [MCAST-VPLS-REQ]. Note that unicast packets that are flooded 183 to each of the egress PEs, before the ingress PE performs learning 184 for those unicast packets, MAY still use ingress replication. 186 6. Overview 188 This document describes procedures for using multicast trees in the 189 SP network to transport VPLS multicast data packets. RSVP-TE P2MP 190 LSPs described in [RFC4875] are an example of such multicast trees. 191 The use of multicast trees in the SP network can be beneficial when 192 the bandwidth of the multicast traffic is high or when it is 193 desirable to optimize the number of copies of a multicast packet 194 transmitted by the ingress. This comes at a cost of state in the SP 195 network to build multicast trees and overhead to maintain this state. 196 This document describes procedures for using multicast trees for VPLS 197 multicast when the provider tunneling technology is either P2MP RSVP- 198 PE or mLDP [MLDP]. The protocol architecture described herein is 199 considered to be flexible to support other P-tunneling technologies 200 as well. 202 This document uses the prefix 'C' to refer to the customer control or 203 data packets and 'P' to refer to the provider control or data 204 packets. An IP (multicast source, multicast group) tuple is 205 abbreviated to (S, G). 207 6.1. Inclusive and Selective Multicast Trees 209 Multicast trees used for VPLS can be of two types: 211 1. Inclusive Trees. A single multicast distribution tree in the 212 SP network is used to carry all the multicast traffic from a 213 specified set of VPLS sites connected to a given PE. A particular 214 multicast distribution tree can be set up to carry the traffic 215 originated by sites belonging to a single VPLS, or to carry the 216 traffic originated by sites belonging to different VPLSs. The ability 217 to carry the traffic of more than one VPLS on the same tree is termed 218 'Aggregation'. The tree will include every PE that is a member of any 219 of the VPLSs that are using the tree. This implies that a PE may 220 receive multicast traffic for a multicast stream even if it doesn't 221 have any receivers on the path of that stream. 223 An Inclusive tree as defined in this document is a source tree. A 224 source tree is used to carry traffic only for VPLS sites that are 225 connected to the PE that is the root. 227 2. Selective Trees. A Selective Tree is used by a PE to send IP 228 multicast traffic for one or IP more multicast streams, originated 229 within sites connected to the PE, that belong to the same or 230 different VPLSs, to a subset of the PEs that belong to those VPLSs. 231 Each of the PEs in the subset should be on the path to a receiver of 232 one or more multicast streams that are mapped onto the tree. The 233 ability to use the same tree for multicast streams that belong to 234 different VPLSs is termed have the ability to create separate SP 235 multicast trees for high bandwidth multicast groups. This allows 236 traffic for these multicast groups to reach only those PE routers 237 that have receivers in these groups. This avoids flooding other PE 238 routers in the VPLS. 240 A SP can use both Inclusive Trees and Selective Trees or either of 241 them for a given VPLS on a PE, based on local configuration. 242 Inclusive Trees can be used for both IP and non-IP data multicast 243 traffic, while Selective Trees can be used only for IP multicast data 244 traffic. 246 A variety of transport technologies may be used in the SP network. 247 For inclusive trees, these transport technologies include point-to- 248 multipoint LSPs created by RSVP-TE or mLDP. For selective trees, only 249 unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation) and 250 unidirectional single-source trees are supported, and the supported 251 tree signaling protocols are RSVP-TE, and mLDP. 253 This document also describes the data plane encapsulations for 254 supporting the various SP multicast transport options. 256 6.2. BGP-Based VPLS Membership Auto-Discovery 258 In order to establish Inclusive P-trees for one or more VPLSs, when 259 Aggregation is performed or when the tunneling technology is P2MP 260 RSVP-TE, the root of the tree must be able to discover the other PEs 261 that have membership in one or more of these VPLSs. This document 262 uses the BGP-based procedures described in [RFC4761] and [L2VPN-SIG] 263 for discovering the VPLS membership of all PEs. 265 The leaves of the Inclusive P-trees must also be able to auto- 266 discover the identifier of the tree. This is described in section 267 6.4. 269 6.3. IP Multicast Group Membership Discovery 271 The setup of a Selective P-tree for one or more IP multicast (S, G)s, 272 when aggregation is used or when the tunneling technology is P2MP 273 RSVP-TE, requires the ingress PE to learn the PEs that have receivers 274 in one or more of these (C-S, C-G)s. For discovering the IP multicast 275 group membership, procedures described in [VPLS-CTRL] should be used. 276 Procedures in [VPLS-CTRL] can also be used with ingress replication 277 to send traffic for an IP multicast stream to only those PEs that are 278 on the path to receivers for that stream. 280 The leaves of the Selective P-trees must also be able to discover the 281 identifier of the tree. This is described in section 6.4. 283 6.4. Advertising P-Tree to VPLS / C-Multicast Binding 285 This document also describes procedures based on BGP VPLS Auto- 286 Discovery (A-D) that are used by the root of an Aggregate Tree to 287 advertise the Inclusive or Selective tree binding and the de- 288 multiplexing information to the leaves of the tree. This document 289 uses the PMSI Tunnel Attribute [BGP-MVPN] for this purpose. 291 Once a PE decides to bind a set of VPLSes or customer multicast 292 groups to an Inclusive Tree or a Selective Tree, it needs to announce 293 this binding to other PEs in the network. This procedure is referred 294 to as Inclusive Tree or Selective Tree binding distribution and is 295 performed using BGP. 297 For an Inclusive Tree this discovery implies announcing the binding 298 of all VPLSs bound to the Inclusive Tree. The inner label assigned by 299 the ingress PE for each VPLS MUST be included, if more than one VPLS 300 is bound to the same tree. The Inclusive Tree Identifier MUST be 301 included. 303 For a Selective Tree this discovery implies announcing all the 304 specific entries bound to this tree along with 305 the Selective Tree Identifier. The inner label assigned for each MUST be included if s from 307 different VPLSes are bound to the same tree. The labels MUST be 308 distinct on a per VPLS basis and MAY be distinct on a per basis. The Selective Tree Identifier MUST be included. 311 6.5. Aggregation 313 As described above the ability to carry the traffic of more than one 314 VPLS on the same tree is termed 'Aggregation'. Both Inclusive and 315 Selective trees support aggregation. 317 Aggregation enables the SP to place a bound on the amount of 318 multicast tree forwarding and control plane state which the P routers 319 must have. Let us call the number of VPLSes aggregated onto a single 320 P-tree as the "Aggregation Factor". When Inclusive source trees are 321 used the number of trees that a PE is the root of is proportional to: 323 + (Number of VPLSes on the PE / Aggregation Factor). 325 In this case the state maintained by a P router, is proportional to: 327 + ((Average number of VPLSes on a PE / Aggregation Factor) * number 328 of PEs) / (Average number of trees that transit a given P router) 330 Thus the state does not grow linearly with the number of VPLSes. 332 Aggregation requires a mechanism for the egresses of the tree to 333 demultiplex the multicast traffic received over the tree. This 334 document describes how upstream-assigned labels can be assigned and 335 distributed by the root of aggregate tree and then used by the 336 egresses to perform this demultiplexing. 338 6.6. Inter-AS VPLS Multicast 340 This document supports three models of inter-AS VPLS service, option 341 (a), (b) and (c) which are very similar conceptually to option (a), 342 (b) and (c) specified in [RFC4364] for IP VPNs. The three options 343 described here are also similar to the three options described in in 344 [RFC4761], which in turn extends the concepts of [RFC4364] to inter- 345 AS VPLS. 347 For option (a) and option (b) support this document specifies a model 348 where Inter-AS VPLS service can be offered without requiring a single 349 P-multicast tree to span multiple ASes. There are two variants of 350 this model. 352 In the first variant, the Autonomous System Border Routers (ASBRs) 353 perform a MAC lookup, in addition to any MPLS lookups, to determine 354 the forwarding decision on a VPLS packet. In this variant the 355 multicast trees are confined to an AS. Hence each AS may use a 356 different P-tunneling technology. An ASBR on receiving a VPLS packet 357 from another ASBR is required to perform a MAC lookup to determine 358 how to forward the packet. Thus an ASBR is required to keep a VPLS 359 Switching Instance (VSI) for the VPLS. This variant is applicable to 360 option (a). In the case of option (a) an ASBR in one AS treats an 361 adjoining ASBR in another AS as a CE and determines the VSI for 362 packets received from another ASBR based on the incoming ethernet 363 interface. It is possible to extend this model by using a PW, per 364 VPLS instance, to interconnect the adjoining ASBRs in what is called 365 as option (e). 367 In the second variant, an inter-AS multicast tree, rooted at a 368 particular PE for a particular VPLS instance, consists of a number of 369 "segments", one per AS, which are stitched together at Autonomous 370 System Border Routers (ASBRs). These are known as "segmented inter-AS 371 trees". Each segment of a segmented inter-AS tree may use a 372 different multicast transport technology. In this variant, an ASBR is 373 not required to keep a a VSI for the VPLS and is not required to 374 perform a MAC lookup in order to forward the VPLS packet. This 375 variant is applicable to option (b) as in the case of option (b) the 376 BGP-VPLS NLRIs or A-D routes are redistributed by the ASBRs. 378 For option (c) support this document specifies a model where Inter-AS 379 VPLS service is offered by requiring a single P-multicast tree to 380 span multiple ASs. This is because in the case of option (c) the 381 ASBRs do not exchange BGP-VPLS NLRIs or A-D routes. 383 7. Intra-AS Inclusive Multicast Tree A-D/Binding 385 This section specifies procedures for the intra-AS auto-discovery (A- 386 D) of VPLS membership and the distribution of information used to 387 instantiate P-Multicast Tunnels. 389 VPLS auto-discovery/binding consists of two components: intra-AS and 390 inter-AS. The former provides VPLS auto-discovery/binding within a 391 single AS. The latter provides VPLS auto-discovery/binding across 392 multiple ASes. Inter-AS auto-discovery/binding is described in 393 section 11. 395 VPLS auto-discovery using BGP as described in [RFC4761, L2VPN-SIG] 396 enables a PE to learn the VPLS membership of other PEs. A PE that 397 belongs to a particular VPLS announces a BGP Network Layer 398 Reachability Information (NLRI) that identifies the Virtual Switch 399 Instance (VSI). This NLRI is constructed from the tuple. The 401 NLRI defined in [RFC4761] comprises the tuple and label 402 blocks for PW signaling. The VE-ID in this case is a two octet 403 number. The NLRI defined in [L2VPN-SIG] comprises only the where the VE-ID is a four octet number. 406 The procedures for constructing Inclusive intra-AS and inter-AS trees 407 as specified in this document require the BGP A-D NLRI to carry only 408 the . Hence these procedures can be used for both BGP-VPLS 409 and LDP-VPLS with BGP A-D. 411 7.1. Originating (intra-AS) auto-discovery routes 413 To participate in the VPLS auto-discovery/binding a PE router that 414 has a given VSI of a given VPLS originates an auto-discovery route 415 and advertises this route in I-BGP. The route is constructed as 416 described in [RFC4761] and [L2VPN-SIG]. 418 The route carries a single L2VPN NLRI with the RD set to the RD of 419 the VSI, and the VE-ID set to the VE-ID of the VSI. 421 If a P-Multicast tree is used to instantiate the provider tunnel for 422 VPLS multicast on the PE, and either (a) this tree exists at the time 423 of discovery, or (b) the PE doesn't need to know the leaves of the 424 tree before hand in order to advertise the P-Multicast tree 425 identifier, then the advertising PE MUST advertise the type and the 426 identity of the P-Multicast tree in the the PMSI Tunnel attribute 427 [BGP-MVPN]. This attribute is described in section 13.1. 429 If a P-Multicast tree is used to instantiate the provider tunnel for 430 VPLS multicast on the PE, and in order to advertise the P-Multicast 431 tree identifier the advertising PE needs to know the leaves of the 432 tree beforehand, then the PE obtains this information from the intra- 433 AS auto-discovery routes received from other PEs. Once the PE obtains 434 the information about the leaves (this information is obtained from 435 the auto-discovery routes received by the PE), the PE then advertises 436 the binding of the tree to the VPLS using the same route as the one 437 used for the auto-discovery, with the addition of carrying in the 438 route the PMSI Tunnel attribute that contains the type and the 439 identity of the P-Multicast tree. If at some later point a new PE 440 advertises participation in the same VPLS, the initial binding P- 441 Tunnel binding information SHOULD NOT change (though the leaves of 442 the corresponding P-Multicast tree may change). 444 A PE that uses a P-Multicast tree to instantiate the provider tunnel 445 MAY aggregate two or more VPLSs present on the PE onto the same tree. 446 If the PE already advertises intra-AS auto-discovery routes for these 447 VPLSs, then aggregation requires the PE to re-advertise these routes. 448 The re-advertised routes MUST be the same as the original ones, 449 except for the PMSI Tunnel attribute. If the PE has not previously 450 advertised intra-AS auto-discovery routes for these VPLSs, then the 451 aggregation requires the PE to advertise (new) intra-AS auto- 452 discovery routes for these VPLSs. The P-Tunnel attribute in the 453 newly advertised/re-advertised routes MUST carry the identity of the 454 P-Multicast tree that aggregates the VPLSs, as well as an MPLS 455 upstream-assigned label [MPLS-UPSTREAM]. Each re-advertised route 456 MUST have a distinct label. 458 Discovery of PE capabilities in terms of what tunnels types they 459 support is outside the scope of this document. Within a given AS PEs 460 participating in a VPLS are expected to advertise tunnel bindings 461 whose tunnel types are supported by all other PEs that are 462 participating in this VPLS and are part of the same AS. 464 7.2. Receiving (intra-AS) auto-discovery routes 466 When a PE receives a BGP Update message that carries an A-D route 467 such that (a) the route was originated by some other PE within the 468 same AS as the local PE, (b) at least one of the Route Targets of the 469 route matches one of the import Route Targets configured for a 470 particular VSI on the local PE, (c) the BGP route selection 471 determines that this is the best route with respect to the NLRI 472 carried by the route, and (d) the route carries the PMSI Tunnel 473 attribute, the PE performs the following. 475 If the route carries the PMSI Tunnel attribute then: 477 + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP 478 P2MP LSP, the PE SHOULD join the P-Multicast tree whose identity 479 is carried in the PMSI Tunnel Attribute. 481 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 482 P2MP LSP, the receiving PE has to establish the appropriate state 483 to properly handle the traffic received over that LSP. The PE 484 that originated the route MUST establish an RSVP-TE P2MP LSP with 485 the local PE as a leaf. This LSP MAY have been established before 486 the local PE receives the route. 488 + If the PMSI Tunnel attribute does not carry a label, then all 489 packets that are received on the P-Multicast tree, as identified 490 by the PMSI Tunnel attribute, are forwarded using the VSI that 491 has at least one of its import Route Targets that matches one of 492 the Route Targets of the received auto-discovery route. 494 + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP 495 LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS 496 label, then the egress PE MUST treat this as an upstream-assigned 497 label, and all packets that are received on the P-Multicast tree, 498 as identified by the PMSI Tunnel attribute, with that upstream 499 label are forwarded using the VSI that has at least one of its 500 import Route Target that matches one of the Route Targets of the 501 received auto-discovery route. 503 If the local PE uses RSVP-TE P2MP LSP for sending (multicast) 504 traffic, originated by VPLS sites connected to the PE, to the 505 sites attached to other PEs, then the local PE uses the 506 Originating Router's IP address information carried in the Intra- 507 AS A-D route to add the PE that originated the route as a leaf 508 node to the LSP. This is done irrespective of whether the 509 received Intra-AS A-D route carries the PMSI Tunnel attribute or 510 not. 512 8. Demultiplexing Multicast Tree Traffic 514 Demultiplexing received VPLS traffic requires the receiving PE to 515 determine the VPLS instance the packet belongs to. The egress PE can 516 then perform a VPLS lookup to further forward the packet. It also 517 requires the egress PE to determine the identity of the ingress PE 518 for MAC learning, as described in section 7. 520 8.1. One Multicast Tree - One VPLS Mapping 522 When a multicast tree is mapped to only one VPLS, determining the 523 tree on which the packet is received is sufficient to determine the 524 VPLS instance on which the packet is received. The tree is determined 525 based on the tree encapsulation. If MPLS encapsulation is used, eg: 526 RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the 527 tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP- 528 TE P2MP LSP or LDP P2MP LSP). 530 8.2. One Multicast Tree - Many VPLS Mapping 532 As traffic belonging to multiple VPLSs can be carried over the same 533 tree, there is a need to identify the VPLS the packet belongs to. 534 This is done by using an inner label that determines to the VPLS for 535 which the packet is intended. The ingress PE uses this label as the 536 inner label while encapsulating a customer multicast data packet. 537 Each of the egress PEs must be able to associate this inner label 538 with the same VPLS and use it to demultimplex the traffic received 539 over the Aggregate Inclusive Tree or the Aggregate Selective Tree. 541 This document requires the use of upstream label assignment by the 542 ingress PE [MPLS-UPSTREAM]. Hence the inner label is assigned by the 543 ingress PE. When the egress PE receives a packet over an Aggregate 544 Tree, the outer encapsulation [in the case of MPLS P2MP LSPs, the 545 outer MPLS label] specifies the label space to perform the inner 546 label lookup. The same label space MUST be used by the egress PE for 547 all P-multicast trees that have the same root [MPLS-UPSTREAM]. 549 If the tree uses MPLS encapsulation the outer MPLS label and the 550 incoming interface provides the label space of the label beneath it. 551 This assumes that penultimate-hop-popping is disabled. An example of 552 this is RSVP-TE P2MP LSPs. The outer label and incoming interface 553 effectively identifies the Tree [MPLS-UPSTREAM, MPLS-MCAST]. 555 The ingress PE informs the egress PEs about the inner label as part 556 of the tree binding procedures described in section 12. 558 9. Establishing Multicast Trees 560 This document does not place any fundamental restrictions on the 561 multicast technology used to setup P-multicast trees. However 562 specific procedures are specified currently only for RSVP-TE P2MP 563 LSPs and LDP P2MP LSPs. An implementation that supports this document 564 MUST support RSVP-TE P2MP LSPs and MAY support LDP P2MP LSPs. 566 The P-multicast trees supported in this document are source trees. A 567 source tree is used to carry traffic originated in sites connected to 568 the PE which is the root of the tree, irrespective of whether these 569 sites belong to the same or different VPLSs. 571 9.1. RSVP-TE P2MP LSPs 573 This section describes procedures that are specific to the usage of 574 RSVP-TE P2MP LSPs for instantiating a multicast tree. Procedures in 575 [RFC4875] are used to signal the P2MP LSP. The LSP is signaled after 576 the root of the P2MP LSP discovers the leaves. The egress PEs are 577 discovered using the procedures described in section 9. Aggregation 578 as described in this document is supported. 580 9.1.1. P2MP TE LSP - VPLS Mapping 582 P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP 583 based advertisements of the P2MP TE LSP - VPLS mapping. They require 584 that the root of the tree include the P2MP TE LSP identifier as the 585 tunnel identifier in the BGP advertisements. This identifier contains 586 the following information elements: 587 - The type of the tunnel is set to RSVP-TE P2MP LSP 588 - RSVP-TE P2MP LSP's SESSION Object 590 This Tunnel Identifier is described in section 13.1. 592 9.1.2. Demultiplexing C-Multicast Data Packets 594 Demultiplexing the C-multicast data packets at the egress PE requires 595 that the PE must be able to determine the P2MP TE LSP that the 596 packets are received on. This enables the egress PE to determine the 597 VPLS that the packet belongs to. To achieve this the LSP MUST be 598 signaled with penultimate-hop-popping (PHP) off as described in 599 section 9. In other words an egress PE MUST NOT advertise IMPLICIT 600 NULL or EXPLICIT NULL for a RSVP-TE P2MP LSP that is carrying traffic 601 for one or more VPLSs. This is because the egress PE needs to rely on 602 the MPLS label, that it advertises to its upstream neighbor, to 603 determine the P2MP LSP that a C-multicast data packet is received on. 605 The egress PE also needs to identify the ingress PE to perform MAC 606 learning. When P2MP LSPs are used as source trees, determining the 607 P2MP LSP that the packets are received on, is sufficient to determine 608 the ingress PE. This is because the ingress PE is the root of the 609 P2MP LSP. 611 The egress PE relies on receiving the PMSI Tunnel Attribute in BGP to 612 determine the VPLS instance to P2MP TE LSP mapping. 614 Once the egress PE receives this mapping: 616 + If the egress PE already has RSVP-TE state for the P2MP TE LSP, 617 it MUST begin to assign a MPLS label from the non-reserved label 618 range, for the P2MP TE LSP and signal this to the previous hop of 619 the P2MP TE LSP. Further it MUST create forwarding state to 620 forward packets received on the P2MP LSP. 622 + If the egress PE does not have RSVP-TE state for the P2MP TE LSP, 623 it MUST retain this mapping. Subsequently when the egress PE 624 receives the RSVP-TE P2MP signaling message, it creates the RSVP- 625 TE P2MP LSP state. It MUST then assign a MPLS label from the 626 non-reserved label range, for the P2MP TE LSP, and signal this to 627 the previous hop of the P2MP TE LSP. 629 Note that if the signaling to set up an RSVP-TE P2MP LSPis 630 completed before a given egress PE learns, via a PMSI Tunnel 631 attribute, of the VPLS or set of VPLSs to which the LSP is bound, 632 the PE MUST discard any traffic received on that LSP until the 633 binding is received. In order for the egress PE to be able to 634 discard such traffic it needs to know that the LSP is associated 635 with one or more VPLSs and that the A-D route that binds the LSP 636 to a VPLS has not yet been received. This is provided by 637 extending [RFC4875] with [RSVP-OBB]. 639 9.2. Receiver Initiated MPLS Trees 641 Receiver initiated MPLS trees can also be used. An example of such 642 trees are LDP setup P2MP MPLS Trees [MLDP]. 644 Procedures in [MLDP] are used to signal the LSP. The LSP is signaled 645 once the leaves receive the LDP FEC for the tree from the root. The 646 egress PEs are discovered using the procedures described in section 647 9. Aggregation as described in this document is supported. 649 9.2.1. P2MP LSP - VPLS Mapping 651 P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based 652 advertisements of the P2MP LSP - VPLS mapping. They require that the 653 root of the tree include the P2MP LSP identifier as the tunnel 654 identifier in the BGP advertisements. This identifier contains the 655 following information elements: 656 - The type of the tunnel is set to LDP P2MP LSP 657 - LDP P2MP FEC which includes an identifier generated by the 658 root. 660 Each egress PE "joins" the P2MP MPLS tree by sending LDP label 661 mapping messages for the LDP P2MP FEC, that was learned in the BGP 662 advertisement, using procedures described in [MLDP]. 664 9.2.2. Demultiplexing C-Multicast Data Packets 666 This follows the same procedures described above for RSVP-TE P2MP 667 LSPs. 669 9.3. Encapsulation of the Aggregate Inclusive and Selective Tree 671 An Aggregate Inclusive Tree or an Aggregate Selective Tree MUST use a 672 MPLS encapsulation. The protocol type in the data link header is as 673 described in [MPLS-MCAST]. 675 10. Inter-AS Inclusive Multicast Tree A-D/Binding 677 This document supports three models of inter-AS VPLS service, option 678 (a), (b) and (c) which are very similar conceptually to option (a), 679 (b) and (c) specified in [RFC4364] for IP VPNs. The three options 680 described here are also similar to the three options described in 681 [RFC4761], which in turn extends the concepts of [RFC4364] to inter- 682 AS VPLS. An implementation MUST support all three of these models. 683 When there are multiple options for implementing one of these models, 684 this section specifies which option is mandatory. 686 For option (a) and option (b) support this section specifies a model 687 where inter-AS VPLS service can be offered without requiring a single 688 P-multicast tree to span multiple ASes. This allows individual ASes 689 to potentially use different P-tunneling technologies.There are two 690 variants of this model. One that requires MAC lookup on the ASBRs and 691 another that does not require MAC lookup on the ASBRs and instead 692 builds segmented inter-AS trees. This applies to both Inclusive and 693 Selective trees. 695 For option (c) support this document specifies a model where Inter-AS 696 VPLS service is offered by requiring a single Inclusive P-multicast 697 tree to span multiple ASs. This is referred to as a non-segmented P- 698 multicast tree. This is because in the case of option (c) the ASBRs 699 do not exchange BGP-VPLS NLRIs or A-D routes. Selective inter-AS 700 trees for option (c) support may be segmented or non-segmented. 702 10.1. VSIs on the ASBRs 704 In this variant, the ASBRs MUST perform a MAC lookup, in addition to 705 any MPLS lookups, to determine the forwarding decision on a VPLS 706 packet. The multicast trees are confined to an AS. An ASBR on 707 receiving a VPLS packet from another ASBR is required to perform a 708 MAC lookup to determine how to forward the packet. Thus an ASBR is 709 required to keep a VSI for the VPLS and MUST be configured with its 710 own VE ID for the VPLS. In this variant the BGP A-D routes generated 711 by PEs in an AS MUST NOT be propagated outside the AS. 713 10.1.1. Option (a) 715 When this variant is used with option (a) an ASBR in one AS treats an 716 adjoining ASBR in another AS as a CE and determines the VSI for 717 packets received from another ASBR based on the incoming ethernet 718 interface. In the case of option (a) the ASBRs do not exchange A-D 719 routes. 721 An implementation MUST support this variant for option (a). 723 10.1.2. Option (e) 725 The VSIs on the ASBRs variant can be used such that the interconnect 726 between the ASBRs is a PW and MPLS encapsulation is used between the 727 ASBRs. An ASBR in one AS treats an adjoining ASBR in another AS as a 728 CE and determines the VSI for packets received from another ASBR 729 based on the incoming MPLS encapsulation. The only A-D routes that 730 are propagated outside the AS are the ones originated by ASBRs. This 731 MPLS PW connects the VSIs on the ASBRs and MUST be signaled using the 732 procedures defined in [RFC4761] or [RFC4762]. 734 The multicast trees for a VPLS are confined to each AS and the VPLS 735 auto-discovery/binding MUST follow the intra-AS procedures described 736 in section 8. 738 10.2. Option (b) - Segmented Inter-AS Trees 740 In this variant, an inter-AS multicast tree, rooted at a particular 741 PE for a particular VPLS instance, consists of a number of 742 "segments", one per AS, which are stitched together at ASBRs. These 743 are known as "segmented inter-AS trees". Each segment of a segmented 744 inter-AS tree may use a different multicast transport technology. In 745 this variant, an ASBR is not required to keep a VSI for the VPLS and 746 is not required to perform a MAC lookup in order to forward the VPLS 747 packet. This implies that an ASBR is not required to be configured 748 with a VE ID for the VPLS. This variant is applicable to option (b). 749 An implementation MUST support this variant. 751 The construction of segmented Inter-AS trees requires the BGP-VPLS A- 752 D NLRI described in [RFC4761, RFC4762]. A BGP-VPLS A-D route for a 753 tuple advertised outside the AS, to which the originating 754 PE belongs, will be referred to as an inter-AS auto-discovery route 755 (Though this route is originated by a PE as an intra-AS route and is 756 referred to as an inter-AS route outside the AS). 758 In addition to this, segmented inter-AS trees require support for the 759 PMSI Tunnel Attribute described in section 13.1. They also require 760 additional procedures in BGP to signal leaf A-D routes between ASBRs 761 as explained in subsequent sections. 763 10.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding 765 This section specifies the procedures for inter-AS VPLS A-D/binding 766 for segmented inter-AS trees. 768 An ASBR must be configured to support a particular VPLS as follows: 770 + An ASBR MUST be be configured with a set of (import) Route 771 Targets (RTs) that specifies the set of VPLSes supported by the 772 ASBR. These Route Targets control acceptance of BGP VPLS auto- 773 discovery routes by the ASBR. Note that instead of being 774 configured, the ASBR MAY obtain this set of (import) Route 775 Targets (RTs) by using Route Target Constrain [RFC4684]. 777 + The ASBR MUST be configured with the tunnel types for the intra- 778 AS segments of the VPLSes supported by the ASBR, as well as 779 (depending on the tunnel type) the information needed to create 780 the PMSI Tunnel attribute for these tunnel types. Note that 781 instead of being configured, the ASBR MAY derive the tunnel types 782 from the intra-AS auto-discovery routes received by the ASBR from 783 the PEs in its own AS. 785 If an ASBR is configured to support a particular VPLS, the ASBR MUST 786 participate in the intra-AS VPLS auto-discovery/binding procedures 787 for that VPLS within the ASBR's own AS, as defined in this document. 789 Moreover, in addition to the above the ASBR performs procedures 790 specified in the next section. 792 10.2.2. Propagating VPLS BGP A-D routes to other ASes - Overview 794 An auto-discovery route for a given VPLS, originated by an ASBR 795 within a given AS, is propagated via BGP to other ASes. The precise 796 rules for distributing and processing the inter-AS auto-discovery 797 routes are given in subsequent sections. 799 Suppose that an ASBR A receives and installs an auto-discovery route 800 for VPLS "X" and VE ID "V" that originated at a particular PE, PE1. 801 The BGP next hop of that received route becomes A's "upstream 802 neighbor" on a multicast distribution tree for (X, V) that is rooted 803 at PE1. When the auto-discovery routes have been distributed to all 804 the necessary ASes, they define a "reverse path" from any AS that 805 supports VPLS X and VE ID V back to PE1. For instance, if AS2 806 supports VPLS X, then there will be a reverse path for VPLS X and VE 807 ID V from AS2 to AS1. This path is a sequence of ASBRs, the first of 808 which is in AS2, and the last of which is in AS1. Each ASBR in the 809 sequence is the BGP next hop of the previous ASBR in the sequence on 810 the given auto-discovery route. 812 This reverse path information can be used to construct a 813 unidirectional multicast distribution tree for VPLS X and VE ID V, 814 containing all the ASes that support X, and having PE1 at the root. 815 We call such a tree an "inter-AS tree". Multicast data originating in 816 VPLS sites for VPLS X connected to PE1 will travel downstream along 817 the tree which is rooted at PE1. 819 The path along an inter-AS tree is a sequence of ASBRs. It is still 820 necessary to specify how the multicast data gets from a given ASBR to 821 the set of ASBRs which are immediately downstream of the given ASBR 822 along the tree. This is done by creating "segments": ASBRs in 823 adjacent ASes will be connected by inter-AS segments, ASBRs in the 824 same AS will be connected by "intra-AS segments". 826 For a given inter-AS tree and a given AS there MUST be only one ASBR 827 within that AS that accepts traffic flowing on that tree. Further for 828 a given inter-AS tree and a given AS there MUST be only one ASBR in 829 that AS that sends the traffic flowing on that tree to a particular 830 adjacent AS. The precise rules for accomplishing this are given in 831 subsequent sections. 833 An ASBR initiates creation of an intra-AS segment when the ASBR 834 receives an auto-discovery route from an E-BGP neighbor. Creation of 835 the segment is completed as a result of distributing, via I-BGP, this 836 route within the ASBR's own AS. 838 For a given inter-AS tunnel each of its intra-AS segments could be 839 constructed by its own independent mechanism. Moreover, by using 840 upstream-assigned labels within a given AS multiple intra-AS segments 841 of different inter-AS tunnels of either the same or different VPLSs 842 may share the same P-Multicast tree. 844 If the P-Multicast tree instantiating a particular segment of an 845 inter-AS tunnel is created by a multicast control protocol that uses 846 receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does 847 not aggregate multiple segments, then all the information needed to 848 create that segment will be present in the inter-AS auto-discovery 849 routes received by the ASBR from the neighboring ASBR. But if the P- 850 Multicast tree instantiating the segment is created by a protocol 851 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 852 unicast replication), or if this P-Multicast tree aggregates multiple 853 segments (irrespective of the multicast control protocol used to 854 create the tree), then the ASBR needs to learn the leaves of the 855 segment. These leaves are learned from A-D routes received from other 856 PEs in the AS, for the same VPLS (i.e. same VE-ID) as the one that 857 the segment belongs to. 859 The following sections specify procedures for propagation of auto- 860 discovery routes across ASes in order to construct inter-AS segmented 861 trees. 863 10.2.2.1. Propagating Intra-AS VPLS A-D routes in E-BGP 865 For a given VPLS configured on an ASBR when the ASBR receives intra- 866 AS A-D routes originated PEs in its own AS, the ASBR MUST propagate 867 each of these route in E-BGP. This procedure MUST be performed for 868 each of the VPLSs configurd on the ASBR. Each of these routes is 869 constructed as follows: 871 + The route carries a single BGP VPLS A-D NLRI with the RD and VE 872 ID being the same as the NLRI in the received intra-AS A-D route. 874 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 875 routable IP address of the ASBR. 877 + The route carries the PMSI Tunnel attribute with the Tunnel Type 878 set to Ingress Replication; the attribute carries no MPLS labels. 880 + The route MUST carry the export Route Target used by the VPLS. 882 10.2.2.2. A-D route received via E-BGP 884 When an ASBR receives from one of its E-BGP neighbors a BGP Update 885 message that carries an auto-discovery route, if (a) at least one of 886 the Route Targets carried in the message matches one of the import 887 Route Targets configured on the ASBR, and (b) the ASBR determines 888 that the received route is the best route to the destination carried 889 in the NLRI of the route, the ASBR re-advertises this auto-discovery 890 route to other PEs and ASBRs within its own AS. The best route 891 selection procedures MUST ensure that for the same destination, all 892 ASBRs in an AS pick the same route as the best route. This ensures 893 that if multiple ASBRs, in an AS, receive the same inter-AS A-D route 894 from their E-BGP neighbors, only one of these ASBRs propagates this 895 route in I-BGP. This ASBR becomes the root of the intra-AS segment of 896 the inter-AS tree and ensures that this is the only ASBR that accepts 897 traffic into this AS from the inter-AS tree. 899 When re-advertising an inter-AS auto-discovery route the ASBR MUST 900 set the Next Hop field of the MP_REACH_NLRI attribute to a routable 901 IP address of the ASBR. 903 Depending on the type of a P-Multicast tree used to instantiate the 904 intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of 905 the re-advertised inter-AS auto-discovery route is constructed as 906 follows: 908 + If the ASBR uses ingress replication to instantiate the intra-AS 909 segment of the inter-AS tunnel, the re-advertised route MUST NOT 910 carry the PMSI Tunnel attribute. 912 + If the ASBR uses a P-Multicast tree to instantiate the intra-AS 913 segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST 914 contain the identity of the tree that is used to instantiate the 915 segment (note that the ASBR could create the identity of the tree 916 prior to the actual instantiation of the segment). If in order to 917 instantiate the segment the ASBR needs to know the leaves of the 918 tree, then the ASBR obtains this information from the auto- 919 discovery routes received from other PEs/ASBRs in ASBR's own AS. 921 + An ASBR that uses a P-Multicast tree to instantiate the intra-AS 922 segment of the inter-AS tunnel MAY aggregate two or more VPLSs 923 present on the ASBR onto the same tree. If the ASBR already 924 advertises inter-AS auto-discovery routes for these VPLSs, then 925 aggregation requires the ASBR to re-advertise these routes. The 926 re-advertised routes MUST be the same as the original ones, 927 except for the PMSI Tunnel attribute. If the ASBR has not 928 previously advertised inter-AS auto-discovery routes for these 929 VPLSs, then the aggregation requires the ASBR to advertise (new) 930 inter-AS auto-discovery routes for these VPLSs. The PMSI Tunnel 931 attribute in the newly advertised/re-advertised routes MUST carry 932 the identity of the P-Multicast tree that aggregates the VPLSs, 933 as well as an MPLS upstream-assigned label [MPLS-UPSTREAM]. Each 934 re-advertised route MUST have a distinct label. 936 In addition the ASBR MUST send to the E-BGP neighbor, from whom it 937 receives the inter-AS auto-discovery route, a BGP Update message that 938 carries a "leaf auto-discovery route". The exact encoding of this 939 route is described in section 13. This route contains the following 940 information elements: 942 + The route carries a single NLRI with the Route Key field set to 943 the tuple of the BGP VPLS A-D NLRI of the inter-AS 944 auto-discovery route received from that neighbor. The NLRI also 945 carries the IP address of the ASBR (this MUST be a routable IP 946 address). 948 + The leaf auto-discovery route MUST include the PMSI Tunnel 949 attribute with the Tunnel Type set to Ingress Replication, and 950 the Tunnel Identifier set to a routable address of the 951 advertising router. The PMSI Tunnel attribute MUST carry a 952 downstream assigned MPLS label that is used to demultiplex the 953 VPLS traffic received over a unicast tunnel by the advertising 954 router. 956 + The Next Hop field of the MP_REACH_NLRI attribute of the route 957 SHOULD be set to the same IP address as the one carried in the 958 Originating Router's IP Address field of the route. 960 + To constrain the distribution scope of this route the route MUST 961 carry the NO_ADVERTISE BGP community ([RFC1997]). 963 + The Route Targets associated with the VPLS MUST be included in 964 the route. 966 10.2.2.3. Leaf A-D Route received via E-BGP 968 When an ASBR receives via E-BGP a leaf auto-discovery route, the ASBR 969 accepts the route only if if (a) at least one of the Route Targets 970 carried in the message matches one of the import Route Targets 971 configured on the ASBR, and (b) the ASBR determines that the received 972 route is the best route to the destination carried in the NLRI of the 973 route. 975 If the ASBR accepts the leaf auto-discovery route, the ASBR finds an 976 auto-discovery route whose BGP-VPLS A-D NLRI has the same value as 977 the field of the the leaf auto-discovery route. 979 The MPLS label carried in the PMSI Tunnel attribute of the leaf auto- 980 discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail 981 of the intra-AS tunnel segment associated with the found auto- 982 discovery route. 984 10.2.2.4. Inter-AS A-D Route received via I-BGP 986 In the context of this section we use the term "PE/ASBR router" to 987 denote either a PE or an ASBR router. 989 Note that a given inter-AS auto-discovery route is advertised within 990 a given AS by only one ASBR as described above. 992 When a PE/ASBR router receives from one of its I-BGP neighbors a BGP 993 Update message that carries an inter-AS auto-discovery route, if (a) 994 at least one of the Route Targets carried in the message matches one 995 of the import Route Targets configured on the PE/ASBR, and (b) the 996 PE/ASBR determines that the received route is the best route to the 997 destination carried in the NLRI of the route, the PE/ASBR performs 998 the following operations. 1000 If the router is an ASBR then the ASBR propagates the route to its E- 1001 BGP neighbors. When propagating the route to the E-BGP neighbors the 1002 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1003 routable IP address of the ASBR. 1005 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1006 attribute with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR 1007 SHOULD join the P-Multicast tree whose identity is carried in the 1008 PMSI Tunnel Attribute. 1010 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1011 attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then 1012 the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP 1013 with the local PE/ASBRas a leaf. This LSP MAY have been established 1014 before the local PE/ASBR receives the route, or MAY be established 1015 after the local PE receives the route. 1017 If the received inter-AS auto-discovery route carries the PMSI Tunnel 1018 attribute with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP 1019 LSP, but the attribute does not carry a label, then the P-Multicast 1020 tree, as identified by the PMSI Tunnel Attribute, is an intra-AS LSP 1021 segment that is part of the inter-AS Tunnel for the 1022 advertised by the inter-AS auto-discovery route and rooted at the PE 1023 that originated the auto-discovery route. If the PMSI Tunnel 1024 attribute carries a (upstream-assigned) label, then a combination of 1025 this tree and the label identifies the intra-AS segment. If the 1026 received router is an ASBR, this intra-AS segment may further be 1027 stitched to ASBR-ASBR inter-AS segment of the inter-AS tunnel. If the 1028 PE/ASBR has local receivers in the VPLS, packets received over the 1029 intra-AS segment must be forwarded to the local receivers using the 1030 local VSI. 1032 10.3. Option (c) 1034 In this method, there is a multi-hop E-BGP peering between the PEs 1035 (or a Route Reflector) in one AS and the PEs (or Route Reflector) in 1036 another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI, 1037 along with PMSI Tunnel Attribute, as in the intra-AS case described 1038 in section 8. An implementation MUST support this method. 1040 The PEs in different ASs use a non-segmented inter-AS P2MP tunnel for 1041 VPLS multicast. A non-segmented inter-AS tunnel is a single tunnel 1042 which spans AS boundaries. The tunnel technology cannot change from 1043 one point in the tunnel to the next, so all ASes through which the 1044 tunnel passes must support that technology. In essence, AS boundaries 1045 are of no significance to a non-segmented inter-AS 1047 This method requires no VPLS information (in either the control or 1048 the data plane) on the ASBRs. The ASBRs only need to participate in 1049 the non-segmented P2MP tunnel setup in the control plane, and do MPLS 1050 label forwarding in the data plane. 1052 The setup of non-segmented inter-AS P2MP tunnels MAY require the P- 1053 routers in one AS to have IP reachability to the loopback addresses 1054 of the PE routers in another AS, depending on the tunneling 1055 technology chosen. If this is the case, reachability to the loopback 1056 addresses of PE routers in one AS MUST be present in the IGP in 1057 another AS. 1059 The data forwarding in this model is the same as in the intra-AS case 1060 described in section 8. 1062 11. Optimizing Multicast Distribution via Selective Trees 1064 Whenever a particular multicast stream is being sent on an Inclusive 1065 Tree, it is likely that the data of that stream is being sent to PEs 1066 that do not require it as the sites connected to these PEs may have 1067 no receivers for the stream. If a particular stream has a significant 1068 amount of traffic, it may be beneficial to move it to a Selective 1069 Tree which has at its leaves only those PEs, connected to sites that 1070 have receivers for the multicast stream (or at least includes fewer 1071 PEs that are attached to sites with no receivers compared to an 1072 Inclusive tree). 1074 A PE connected to the multicast source of a particular multicast 1075 stream may be performing explicit tracking i.e. it may know the PEs 1076 that have receivers in the multicast stream. Section 12.2.1 describes 1077 procedures that enable explicit tracking. If this is the case 1078 Selective Trees can also be triggered on other criteria. For instance 1079 there could be a "pseudo wasted bandwidth" criteria: switching to a 1080 Selective Tree would be done if the bandwidth multiplied by the 1081 number of uninterested PEs (PE that are receiving the stream but have 1082 no receivers) is above a specified threshold. The motivation is that 1083 (a) the total bandwidth wasted by many sparsely subscribed low- 1084 bandwidth groups may be large, and (b) there's no point to moving a 1085 high-bandwidth group to a Selective Tree if all the PEs have 1086 receivers for it. 1088 Switching a (C-S, C-G) stream to a Selective Tree may require the 1089 root of the tree to determine the egress PEs that need to receive the 1090 (C-S, C-G) traffic. This is true in the following cases: 1092 + If the tunnel is a source initiated tree, such as a RSVP-TE P2MP 1093 Tunnel, the PE needs to know the leaves of the tree before it can 1094 instantiate the Selective Tree. 1096 + If a PE decides to send traffic for multicast streams, belonging 1097 to different VPLSs, using one P-multicast Selective Tree, such a 1098 tree is termed an Aggregate Tree with a selective mapping. The 1099 setting up of such an Aggregate Tree requires the ingress PE to 1100 know all the other PEs that have receivers for multicast groups 1101 that are mapped onto the tree. 1103 For discovering the IP multicast group membership, for the above 1104 two cases, procedures described in [VPLS-CTRL] SHOULD be used. 1105 These cases require that explicit tracking be done for the (C-S, 1106 C-G) stream. The root of the Selective P-tree MAY decide to do 1107 explicit tracking of this stream only after it has determined to 1108 move the stream to a Selective tree, or it MAY have been doing 1109 explicit tracking all along. 1111 The PE at the root of the tree MUST signal the leaves of the tree 1112 that the (C-S, C-G) stream is now bound to the to the Selective 1113 Tree. Note that the PE could create the identity of the P- 1114 multicast tree prior to the actual instantiation of the tunnel. 1116 If the Selective Tree is instantiated by a source-initiated P- 1117 multicast tree (e.g., an RSVP-TE P2MP tunnel), the PE at the root 1118 of the tree MUST establish the source-initiated P-multicast tree 1119 to the leaves. This tree MAY have been established before the 1120 leaves receive the Selective Tree binding, or MAY be established 1121 after the leaves receives the binding. The leaves MUST not 1122 switch to the Selective Tree until they receive both the binding 1123 and the tree signaling message. 1125 11.1. Protocol for Switching to Selective Trees 1127 Selective Trees provide a PE the ability to create separate P- 1128 multicast trees for certain streams. The source PE, that 1129 originates the Selective Tree, and the egress PEs, MUST switch to the 1130 Selective Tree for the streams that are mapped to it. 1132 Once a source PE decides to setup an Selective Tree, it MUST announce 1133 the mapping of the streams (which may be in different 1134 VPLSs) that are mapped to the tree to the other PEs using BGP. 1135 Depending on the P-multicast technology used, this announcement may 1136 be done before or after setting up the Selective Tree. After the 1137 egress PEs receive the announcement they setup their forwarding path 1138 to receive traffic on the Selective Tree if they have one or more 1139 receivers interested in the streams mapped to the tree. 1140 Setting up the forwarding path requires setting up the demultiplexing 1141 forwarding entries based on the top MPLS label (if there is no inner 1142 label) or the inner label (if present) as described in section 9. The 1143 egress PEs may perform this switch to the Selective Tree once the 1144 advertisement from the ingress PE is received or wait for a 1145 preconfigured timer to do so. 1147 A source PE MUST use the following approach to decide when to start 1148 transmitting data on the Selective tree. A certain pre-configured 1149 delay after advertising the streams mapped to an Selective 1150 Tree, the source PE begins to send traffic on the Selective Tree. At 1151 this point it stops to send traffic for the streams, that 1152 are mapped on the Selective Tree, on the Inclusive Tree. This traffic 1153 is instead transmitted on the Selective Tree. 1155 11.2. Advertising C-(S, G) Binding to a Selective Tree using BGP 1157 The ingress PE informs all the PEs that are on the path to receivers 1158 of the C-(S, G) of the binding of the Selective Tree to the C-(S, G). 1159 The BGP announcement is done by sending update for the MCAST-VPLS 1160 address family. A Selective Tree A-D route is used, containing the 1161 following information: 1163 + a) IP address of the originating PE 1165 b) The RD configured locally for the MVPN. This is required to 1166 uniquely identify the as the addresses could 1167 overlap between different VPLSs. This is the same RD value used 1168 in the VPLS auto-discovery process. 1170 c) The C-Source address. 1172 d) The C-Group address. 1174 e) A PE MAY aggregate two or more (C-S, C-G)s originated by the 1175 PE onto the same P-Multicast tree. If the PE already advertises 1176 Selective Tree auto-discovery routes for these Selective Trees, 1177 then aggregation requires the PE to re-advertise these routes. 1178 The re-advertised routes MUST be the same as the original ones, 1179 except for the PMSI tunnel attribute. If the PE has not 1180 previously advertised Selective Tree auto-discovery routes for 1181 these (C-S, C-G)s, then the aggregation requires the PE to 1182 advertise (new) Selective Tree auto-discovery routes for these 1183 (C-S, C-G)s. The PMSI Tunnel attribute in the newly 1184 advertised/re-advertised routes MUST carry the identity of the P- 1185 Multicast tree that aggregates the (C-S, C-G)s. If at least some 1186 of the (C-S, C-G)s aggregated onto the same P-Multicast tree 1187 belong to different VPLSs, then all these routes MUST carry an 1188 MPLS upstream assigned label [MPLS-UPSTREAM]. If all these 1189 aggregated (C-S, C-G)s belong to the same VPLS, then the routes 1190 MAY carry an MPLS upstream assigned label [MPLS-UPSTREAM]. The 1191 labels MUST be distinct on a per VPLS basis, and MAY be distinct 1192 on a per route basis. 1194 When a PE distributes this information via BGP, it must include the 1195 following: 1196 + 1. A PMSI Tunnel Attribute to identify the Selective Tree to 1197 which the stream is bound. 1199 + Route Target Extended Communities attribute. This is used as 1200 described in section 8. 1202 11.2.1. Explicit Tracking 1204 If the PE wants to enable explicit tracking for the specified flow, 1205 it also indicates this in the A-D route it uses to bind the flow to a 1206 particular Selective Tree. Then any PE which receives the A-D route 1207 will respond with a "Leaf A-D Route" in which it identifies itself as 1208 a receiver of the specified flow. The Leaf A-D route will be 1209 withdrawn when the PE is no longer a receiver for the flow. 1211 If the PE needs to enable explicit tracking for a flow before binding 1212 the flow to an Selective Tree, it can do so by sending an A-D route 1213 identifying the flow but not specifying an Selective Tree. This will 1214 elicit the Leaf A-D Routes. This is useful when the PE needs to know 1215 the receivers before selecting an Selective Tree. 1217 11.3. Inter-AS Selective Tree 1219 Inter-AS Selective Trees support all three models of inter-AS VPLS 1220 service, option (a), (b) and (c), that are supported by Inter-AS 1221 Inclusive Trees. They are constructed in a manner that is very 1222 similar to Inter-AS Inclusive Trees. 1224 For option (a) and option (b) support inter-AS Selective Trees are 1225 constructed without requiring a single P-multicast tree to span 1226 multiple ASes. This allows individual ASes to potentially use 1227 different P-tunneling technologies.There are two variants of this 1228 model. One that requires MAC and IP multicast lookup on the ASBRs and 1229 another that does not require MAC/IP multicast lookup on the ASBRs 1230 and instead builds segmented inter-AS Selective trees. 1232 Segmented Inter-AS Selective trees can also be used with option (c) 1233 unlike Segmented Inter-AS Inclusive trees. This is because the 1234 Selective tree A-D routes can be exchanged via ASBRs (even though 1235 BGP-VPLS NLRI or A-D routes are not exchanged via ASBRs). 1237 In the case of Option (c) an Inter-AS Selective tree may also be a 1238 non-segmented P-multicast tree that spans multiple ASs. 1240 11.3.1. VSIs on the ASBRs 1242 The requirements on ASBRs in this model include the requirements 1243 presented in section 11. The source ASBR (that receives traffic from 1244 another AS) may independently decide whether it wishes to use 1245 Selective Trees or not. If it uses Selective Trees the source ASBR 1246 MUST perform an IP multicast lookup to determine the Selective Tree 1247 to forward the VPLS packet on. 1249 11.3.1.1. VPLS Inter-AS Selective Tree A-D Binding 1251 The mechanisms for propagating Selective Tree A-D routes are the same 1252 as the intra-AS case described in section 12.2. The BGP Selective 1253 Tree A-D routes generated by PEs in an AS MUST NOT be propagated 1254 outside the AS. 1256 11.3.2. Inter-AS Segmented Selective Trees 1258 Inter-AS Segmented Selective trees MUST be used when option (b) is 1259 used to provide the inter-AS VPLS service. They MAY be used when 1260 option (c) is used to provide the inter-AS VPLS service. 1262 A Segmented inter-AS Selective Tunnel is constructed similar to an 1263 inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is 1264 constructed as a concatenation of tunnel segments. There are two 1265 types of tunnel segments: an intra-AS tunnel segment (a segment that 1266 spans ASBRs within the same AS), and inter-AS tunnel segment (a 1267 segment that spans adjacent ASBRs in adjacent ASes). ASes that are 1268 spanned by a tunnel are not required to use the same tunneling 1269 mechanism to construct the tunnel - each AS may pick up a tunneling 1270 mechanism to construct the intra-AS tunnel segment of the tunnel, in 1271 its AS. 1273 The PE that decides to set up a Selective Tree, advertises the 1274 Selective Tree to (C-S, C-G) binding using a Selective Tree A-D route 1275 as per procedures in section 12.2, to the routers in its own AS. 1277 A Selective Tree A-D route advertised outside the AS, to which the 1278 originating PE belongs, will be referred to as an inter-AS Selective 1279 Tree A-D route (Although this route is originated by a PE as an 1280 intra-AS route it is referred to as an inter-AS route outside the 1281 AS). 1283 An ASBR that receives the information from its upstream ASBR using E- 1284 BGP sends back a tunnel binding for AS information if: 1286 a) At least one of the Route Targets carried in the message 1287 matches one of the import Route Targets configured on the ASBR, 1288 and 1290 b) The ASBR determines that the received route is the best route 1291 to the destination carried in the NLRI of the route. 1293 If the ASBR instantiates a Selective Tree for the AS it 1294 sends back a downstream label that is used to forward the packet 1295 along its intra-AS Selective Tree segment for . However, in 1296 the case of option (b) the ASBR may decide to use an AS Inclusive 1297 Tree segment instead, in which case it sends back the same label that 1298 it advertised for the AS-AS segment of the inter-AS segmented 1299 Inclusive tree. (This is not possible in option (c) as in option (c) 1300 the ASBRs do not participate in inter-AS Inclusive tree setup). If 1301 the downstream ASBR instantiates a Selective Tree, it further 1302 propagates the Selective Tree A-D route to its downstream ASes. 1304 An AS can instantiate an intra-AS Selective Tree segment for the 1305 inter-AS Selective tunnel only if the upstream AS instantiates a 1306 Selective Tree. The procedures allow each AS to determine whether it 1307 wishes to setup a Selective Tree or not and the AS is not forced to 1308 setup a Selective Tree just because the upstream AS decides to do so. 1310 The leaves of an intra-AS Selective Tree will be the PEs that have 1311 local receivers that are interested in and the ASBRs that 1312 have received VPLS control information for . 1314 The C-multicast data traffic is sent on the Selective Tree by the 1315 originating PE. When it reaches an ASBR that is on the spanning tree, 1316 it is delivered to local receivers, if any, and is also forwarded to 1317 the neighbor ASBR after being encapsulated in the label advertised by 1318 the neighbor. The neighbor ASBR either transports this packet on the 1319 Selective Tree segment for the multicast stream or an Inclusive Tree 1320 segment, delivering it to the ASBRs in its own AS. These ASBRs in 1321 turn repeat the procedures of the origin AS ASBRs and the multicast 1322 packet traverses the spanning tree. 1324 The (C-S, C-G) membership for which the Selective Tree is 1325 instantiated, is propagated inter-AS using procedures in [VPLS-CTRL]. 1327 11.3.3. Inter-AS Non-Segmented Selective Trees 1329 Inter-AS Non-segmented Selective trees may be used in the case of 1330 option (c). 1332 In this method, there is a multi-hop E-BGP peering between the PEs 1333 (or a Route Reflector) in one AS and the PEs (or Route Reflector) in 1334 another AS. The PEs exchange BGP Selective tree A-D routes, along 1335 with PMSI Tunnel Attribute, as in the intra-AS case described in 1336 section 12.2. 1338 The PEs in different ASs use a non-segmented Selective inter-AS P2MP 1339 tunnel for VPLS multicast. 1341 This method requires no VPLS information (in either the control or 1342 the data plane) on the ASBRs. The ASBRs only need to participate in 1343 the non-segmented P2MP tunnel setup in the control plane, and do MPLS 1344 label forwarding in the data plane. 1346 The data forwarding in this model is the same as in the intra-AS case 1347 described in section 9. 1349 12. BGP Extensions 1351 This section describes the encoding of the BGP extensions required by 1352 this document. 1354 12.1. Inclusive Tree/Selective Tree Identifier 1356 Inclusive Tree and Selective Tree advertisements carry the Tree 1357 identifier. 1359 This document defines and uses a new BGP attribute, called PMSI 1360 Tunnel Attribute. This is an optional transitive BGP attribute. The 1361 format of this attribute is defined as follows: 1363 +---------------------------------+ 1364 | Flags (1 octet) | 1365 +---------------------------------+ 1366 | Tunnel Type (1 octets) | 1367 +---------------------------------+ 1368 | MPLS Label (3 octets) | 1369 +---------------------------------+ 1370 | Tunnel Identifier (variable) | 1371 +---------------------------------+ 1373 The Flags field has the following format: 1375 0 1 2 3 4 5 6 7 1376 +-+-+-+-+-+-+-+-+ 1377 | reserved |L| 1378 +-+-+-+-+-+-+-+-+ 1380 This document defines the following flags: 1382 + Leaf Information Required (L) 1384 The Tunnel Type identifies the type of the tunneling technology used 1385 to establish the P-tunnel. The type determines the syntax and 1386 semantics of the Tunnel Identifier field. This document defines the 1387 following Tunnel Types: 1389 + 1 - RSVP-TE P2MP LSP 1390 + 2 - LDP P2MP LSP 1391 + 6 - Ingress Replication 1393 If the MPLS Label field is non-zero, then it contains an MPLS 1394 label encoded as 3 octets, where the high-order 20 bits contain 1395 the label value. Absence of MPLS Label is indicated by setting 1396 the MPLS Label field to zero. 1398 When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier 1399 contains the RSVP-TE P2MP LSP's SESSION Object. 1401 When the type is set to LDP P2MP LSP, the Tunnel Identifier is 1402 . 1404 When the type is set to Ingress Replication the Tunnel Identifier 1405 carries the unicast tunnel endpoint. 1407 12.2. MCAST-VPLS NLRI 1409 This document defines a new BGP NLRI, called the MCAST-VPLS NLRI. 1411 Following is the format of the MCAST-VPLS NLRI: 1413 +-----------------------------------+ 1414 | Route Type (1 octet) | 1415 +-----------------------------------+ 1416 | Length (1 octet) | 1417 +-----------------------------------+ 1418 | Route Type specific (variable) | 1419 +-----------------------------------+ 1421 The Route Type field defines encoding of the rest of MCAST-VPLS NLRI 1422 (Route Type specific MCAST-VPLS NLRI). 1424 The Length field indicates the length in octets of the Route Type 1425 specific field of MCAST-VPLS NLRI. 1427 This document defines the following Route Types for auto-discovery 1428 routes: 1429 + 3 - Selective Tree auto-discovery route; 1430 + 4 - Leaf auto-discovery route. 1432 The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol 1433 Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of 1434 MCAST-VPLS. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 1435 attribute contains the MCAST-VPLS NLRI (encoded as specified above). 1437 In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI, 1438 they must use BGP Capabilities Advertisement to ensure that they both 1439 are capable of properly processing such NLRI. This is done as 1440 specified in [RFC4760], by using capability code 1 (multiprotocol 1441 BGP) with an AFI of 25 and an SAFI of MCAST-VPLS. 1443 The following describes the format of the Route Type specific MCAST- 1444 VPLS NLRI for various Route Types defined in this document. 1446 12.2.1. Selective Tree auto-discovery route 1448 An Selective Tree A-D route type specific MCAST-VPLS NLRI consists of 1449 the following: 1451 +-----------------------------------+ 1452 | RD (8 octets) | 1453 +-----------------------------------+ 1454 | Multicast Source Length (1 octet) | 1455 +-----------------------------------+ 1456 | Multicast Source (Variable) | 1457 +-----------------------------------+ 1458 | Multicast Group Length (1 octet) | 1459 +-----------------------------------+ 1460 | Multicast Group (Variable) | 1461 +-----------------------------------+ 1462 | Originating Router's IP Addr | 1463 +-----------------------------------+ 1465 The RD is encoded as described in [RFC4364]. 1467 The Multicast Source field contains the C-S address. If the Multicast 1468 Source field contains an IPv4 address, then the value of the 1469 Multicast Source Length field is 32. If the Multicast Source field 1470 contains an IPv6 address, then the value of the Multicast Source 1471 Length field is 128. 1473 The Multicast Group field contains the C-G address. If the Multicast 1474 Group field contains an IPv4 address, then the value of the Multicast 1475 Group Length field is 32. If the Multicast Group field contains an 1476 IPv6 address, then the value of the Multicast Group Length field is 1477 128. 1479 Usage of Selective Tree auto-discovery routes is described in Section 1480 12. 1482 12.2.2. Leaf auto-discovery route 1484 A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of 1485 the following: 1487 +-----------------------------------+ 1488 | Route Key (variable) | 1489 +-----------------------------------+ 1490 | Originating Router's IP Addr | 1491 +-----------------------------------+ 1493 Usage of Leaf auto-discovery routes is described in sections "Inter- 1494 AS Inclusive Multicast Tree A-D/Binding" and "Optimizing Multicast 1495 Distribution via Selective Trees". 1497 13. Aggregation Methodology 1499 In general the herustics used to decide which VPLS instances or entries to aggregate is implementation dependent. It is also 1501 conceivable that offline tools can be used for this purpose. This 1502 section discusses some tradeoffs with respect to aggregation. 1504 The "congruency" of aggregation is defined by the amount of overlap 1505 in the leaves of the client trees that are aggregated on a SP tree. 1506 For Aggregate Inclusive Trees the congruency depends on the overlap 1507 in the membership of the VPLSs that are aggregated on the Aggregate 1508 Inclusive Tree. If there is complete overlap aggregation is perfectly 1509 congruent. As the overlap between the VPLSs that are aggregated 1510 reduces, the congruency reduces. 1512 If aggregation is done such that it is not perfectly congruent a PE 1513 may receive traffic for VPLSs to which it doesn't belong. As the 1514 amount of multicast traffic in these unwanted VPLSs increases 1515 aggregation becomes less optimal with respect to delivered traffic. 1516 Hence there is a tradeoff between reducing state and delivering 1517 unwanted traffic. 1519 An implementation should provide knobs to control the congruency of 1520 aggregation. This will allow a SP to deploy aggregation depending on 1521 the VPLS membership and traffic profiles in its network. If 1522 different PEs or shared roots' are setting up Aggregate Inclusive 1523 Trees this will also allow a SP to engineer the maximum amount of 1524 unwanted VPLSs that a particular PE may receive traffic for. 1526 The state/bandwidth optimality trade-off can be further improved by 1527 having a versatile many-to-many association between client trees and 1528 provider trees. Thus a VPLS can be mapped to multiple Aggregate 1529 Trees. The mechanisms for achieving this are for further study. Also 1530 it may be possible to use both ingress replication and an Aggregate 1531 Tree for a particular VPLS. Mechanisms for achieving this are also 1532 for further study. 1534 14. Data Forwarding 1536 14.1. MPLS Tree Encapsulation 1538 The following diagram shows the progression of the VPLS IP multicast 1539 packet as it enters and leaves the SP network when MPLS trees are 1540 being used for multiple VPLS instances. RSVP-TE P2MP LSPs are 1541 examples of such trees. 1543 Packets received Packets in transit Packets forwarded 1544 at ingress PE in the service by egress PEs 1545 provider network 1547 +---------------+ 1548 |MPLS Tree Label| 1549 +---------------+ 1550 | VPLS Label | 1551 ++=============++ ++=============++ ++=============++ 1552 ||C-Ether Hdr || || C-Ether Hdr || || C-Ether Hdr || 1553 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1554 || C-IP Header || || C-IP Header || || C-IP Header || 1555 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 1556 || C-Payload || || C-Payload || || C-Payload || 1557 ++=============++ ++=============++ ++=============++ 1559 The receiver PE does a lookup on the outer MPLS tree label and 1560 determines the MPLS forwarding table in which to lookup the inner 1561 MPLS label. This table is specific to the tree label space. The inner 1562 label is unique within the context of the root of the tree (as it is 1563 assigned by the root of the tree, without any coordination with any 1564 other nodes). Thus it is not unique across multiple roots. So, to 1565 unambiguously identify a particular VPLS one has to know the label, 1566 and the context within which that label is unique. The context is 1567 provided by the outer MPLS label [MPLS-UPSTREAM]. 1569 The outer MPLS label is stripped. The lookup of the resulting MPLS 1570 label determines the VSI in which the receiver PE needs to do the C- 1571 multicast data packet lookup. It then strips the inner MPLS label and 1572 sends the packet to the VSI for multicast data forwarding. 1574 15. VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment 1576 If the destination MAC address of a VPLS packet received by a PE from 1577 a VPLS site is a multicast adddress, a multicast tree SHOULD be used 1578 to transport the packet, if possible. If the packet is an IP 1579 multicast packet and a Selective tree exists for that multicast 1580 stream, the Selective tree SHOULD be used. Else if an Inclusive tree 1581 exists for the VPLS, it SHOULD be used. 1583 If the destination MAC address of a VPLS packet is a broadcast 1584 address, it is flooded. If Inclusive tree is already established, PE 1585 SHOULD flood over it. If Inclusive Tree cannot be used for some 1586 reason, PE MUST flood over multiple PWs, based on [RFC4761] or 1587 [RFC4762]. 1589 If the destination MAC address of a packet is a unicast address and 1590 it has not been learned, the packet MUST be sent to all PEs in the 1591 VPLS. Inclusive multicast trees SHOULD be used for sending unknown 1592 unicast MAC packets to all PEs. When this is the case the receiving 1593 PEs MUST support the ability to perform MAC address learning for 1594 packets received on a multicast tree. In order to perform such 1595 learning, the receiver PE MUST be able to determine the sender PE 1596 when a VPLS packet is received on a multicast tree. This further 1597 implies that the MPLS multicast tree technology MUST allow the egress 1598 PE to determine the sender PE from the received MPLS packet. 1600 When a receiver PE receives a VPLS packet with a source MAC address, 1601 that has not yet been learned, on a multicast tree, the receiver PE 1602 determines the PW to the sender PE. The receiver PE then creates 1603 forwarding state in the VPLS instance with a destination MAC address 1604 being the same as the source MAC address being learned, and the PW 1605 being the PW to the sender PE. 1607 It should be noted that when a sender PE that is sending packets 1608 destined to an unknown unicast MAC address over a multicast tree 1609 learns the PW to use for forwarding packets destined to this unicast 1610 MAC address, it might immediately switch to transport such packets 1611 over this particular PW. Since the packets were initially being 1612 forwarded using a multicast tree, this could lead to packet 1613 reordering. This constraint should be taken into consideration if 1614 unknown unicast frames are forwarded using a Inclusive Tree, instead 1615 of multiple PWs based on [RFC4761] or [RFC4762]. 1617 An implementation MUST support the ability to transport unknown 1618 unicast traffic over Inclusive multicast trees. Further an 1619 implementation MUST support the ability to perform MAC address 1620 learning for packets received on a multicast tree. 1622 16. Security Considerations 1624 Security considerations discussed in [RFC4761] and [RFC4762] apply to 1625 this document. This section describes additional considerations. 1627 As mentioned in [RFC4761], there are two aspects to achieving data 1628 privacy in a VPLS: securing the control plane and protecting the 1629 forwarding path. Compromise of the control plane could result in a PE 1630 sending multicast data belonging to some VPLS to another VPLS, or 1631 blackholing VPLS multicast data, or even sending it to an 1632 eavesdropper; none of which are acceptable from a data privacy point 1633 of view. The mechanisms in this document use BGP for the control 1634 plane. Hence techniques such as in [RFC2385] help authenticate BGP 1635 messages, making it harder to spoof updates (which can be used to 1636 divert VPLS traffic to the wrong VPLS) or withdraws (denial-of- 1637 service attacks). In the multi-AS methods (b) and (c) described in 1638 Section 11, this also means protecting the inter-AS BGP sessions, 1639 between the ASBRs, the PEs, or the Route Reflectors. 1641 Note that [RFC2385] will not help in keeping MPLS labels, associated 1642 with P2MP LSPs or the upstream MPLS labels used for aggregation, 1643 private -- knowing the labels, one can eavesdrop on VPLS traffic. 1644 However, this requires access to the data path within a Service 1645 Provider network. 1647 One of the requirements for protecting the data plane is that the 1648 MPLS labels are accepted only from valid interfaces. This applies 1649 both to MPLS labels associated with P2MP LSPs and also applies to the 1650 upstream assigned MPLS labels. For a PE, valid interfaces comprise 1651 links from P routers. For an ASBR, a valid interface is a link from 1652 another ASBR in an AS that is part of a given VPLS. It is especially 1653 important in the case of multi-AS VPLSs that one accept VPLS packets 1654 only from valid interfaces. 1656 17. IANA Considerations 1658 This document defines a new NLRI, called MCAST-VPLS, to be carried in 1659 BGP using multiprotocol extensions. It requires assignment of a new 1660 SAFI. This is to be assigned by IANA. 1662 This document defines a BGP optional transitive attribute, called 1663 PMSI Attribute. This is the same attribute as the one defined in 1664 [BGP-MVPN] and the code point for this attribute has already been 1665 assigned by IANA as 22 [BGP-IANA]. Hence no further action is 1666 required from IANA regarding this attribute. 1668 18. Acknowledgments 1670 Many thanks to Thomas Morin for his support of this work. We would 1671 also like to thank authors of [BGP-MVPN] and [MVPN] as the details of 1672 the inter-AS segmented tree procedures in this document have 1673 benefited from those in [BGP-MVPN] and [MVPN]. 1675 19. Normative References 1677 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1678 Levels.", Bradner, March 1997 1680 [RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service", 1681 draft-ietf-l2vpn-vpls-bgp-02.txt 1683 [RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services 1684 over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt 1686 [RFC4760] T. Bates, et. al., "Multiprotocol Extensions for BGP-4", 1687 January 2007 1689 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 1690 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 1691 upstream-label-00.txt 1693 20. Informative References 1695 [VPLS-CTRL] R. Aggarwal, Y. Kamite, L. Fang, "Propagation of VPLS IP 1696 Multicast Group Membership Information", draft-raggarwa-l2vpn-vpls- 1697 mcast-ctrl-00.txt 1699 [L2VPN-SIG] E. Rosen et. al., "Provisioning, Autodiscovery, and 1700 Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt 1702 [MPLS-MCAST] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS 1703 Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-00.txt 1705 [MVPN] E. Rosen, R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf- 1706 l3vpn-2547bis-mcast-05.txt" 1708 [BGP-MVPN] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, C. 1709 Kodeboniya. "BGP Encodings for Multicast in 2547 VPNs", draft-ietf- 1710 l3vpn-2547bis-mcast-bgp-03.txt 1712 [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to 1713 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt 1715 [RSVP-OBB] Z. Ali, G. Swallow, R. Aggarwal, "Non PHP behavior and 1716 out-of-band mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no- 1717 php-obb-mapping-00.txt 1719 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 1720 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 1721 Paths", draft-ietf-mpls-ldp-p2mp-02.txt 1723 [RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, February 2006 1725 [MCAST-VPLS-REQ] Y. kamite, et. al., "Requirements for Multicast 1726 Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- 1727 mcast-reqts-05.txt 1729 [RFC1997] R. Chandra, et. al., "BGP Communities Attribute", August 1730 1996 1732 [BGP-IANA] http://www.iana.org/assignments/bgp-parameters 1734 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1735 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1736 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1737 November 2006 1739 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1740 Signature Option", RFC 2385, August 1998. 1742 21. Author's Address 1744 Rahul Aggarwal 1745 Juniper Networks 1746 1194 North Mathilda Ave. 1747 Sunnyvale, CA 94089 1748 USA 1749 Phone: +1-408-936-2720 1750 Email: rahul@juniper.net 1752 Yuji Kamite 1753 NTT Communications Corporation 1754 Tokyo Opera City Tower 1755 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1756 Tokyo 163-1421, 1757 Japan 1759 Email: y.kamite@ntt.com 1761 Luyuan Fang 1762 Cisco Systems 1763 300 Beaver Brook Road 1764 BOXBOROUGH, MA 01719 1765 USA 1767 Email: lufang@cisco.com 1769 Yakov Rekhter 1770 Juniper Networks 1771 1194 North Mathilda Ave. 1772 Sunnyvale, CA 94089 1773 USA 1775 Email: yakov@juniper.net 1777 Chaitanya Kodeboniya 1779 22. Intellectual Property Statement 1781 The IETF takes no position regarding the validity or scope of any 1782 Intellectual Property Rights or other rights that might be claimed to 1783 pertain to the implementation or use of the technology described in 1784 this document or the extent to which any license under such rights 1785 might or might not be available; nor does it represent that it has 1786 made any independent effort to identify any such rights. Information 1787 on the procedures with respect to rights in RFC documents can be 1788 found in BCP 78 and BCP 79. 1790 Copies of IPR disclosures made to the IETF Secretariat and any 1791 assurances of licenses to be made available, or the result of an 1792 attempt made to obtain a general license or permission for the use of 1793 such proprietary rights by implementers or users of this 1794 specification can be obtained from the IETF on-line IPR repository at 1795 http://www.ietf.org/ipr. 1797 The IETF invites any interested party to bring to its attention any 1798 copyrights, patents or patent applications, or other proprietary 1799 rights that may cover technology that may be required to implement 1800 this standard. Please address the information to the IETF at ietf- 1801 ipr@ietf.org. 1803 23. Full Copyright Statement 1805 Copyright (C) The IETF Trust (2007). This document is subject to the 1806 rights, licenses and restrictions contained in BCP 78, and except as 1807 set forth therein, the authors retain all their rights. 1809 This document and the information contained herein are provided on an 1810 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1811 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1812 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1813 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1814 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.