idnits 2.17.1 draft-raggarwa-l2vpn-vpls-mcast-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 796. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2005) is 6854 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP-TE-P2MP' is mentioned on line 363, but not defined == Unused Reference: 'RFC3107' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 743, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == 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 (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-04 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-AUTO') -- Possible downref: Normative reference to a draft: ref. 'VPLS-CTRL' == Outdated reference: A later version (-01) exists of draft-raggarwa-mpls-upstream-label-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-UPSTREAM' == Outdated reference: A later version (-01) exists of draft-rosen-mpls-multicast-encaps-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-MCAST' == Outdated reference: A later version (-01) exists of draft-kamite-l2vpn-vpls-mcast-reqts-00 -- Possible downref: Normative reference to a draft: ref. 'VPLS-MCAST-REQ' == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-02 == Outdated reference: A later version (-01) exists of draft-minei-mpls-ldp-p2mp-00 Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Aggarwal 2 Internet Draft Juniper Networks 3 Expiration Date: January 2006 4 Y. Kamite 5 NTT Communications 7 L. Fang 8 AT&T 10 July 2005 12 Multicast in VPLS 14 draft-raggarwa-l2vpn-vpls-mcast-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes a solution for overcoming the limitations of 42 existing VPLS multicast solutions. It describes procedures for VPLS 43 multicast that utilize multicast trees in the sevice provider (SP) 44 network. One such multicast tree can be shared between multiple VPLS 45 instances. Procedures by which a single multicast tree in the 46 backbone can be used to carry traffic belonging only to a specified 47 set of one or more multicast groups from one or more VPLSs are also 48 described. 50 Table of Contents 52 1 Specification of requirements ......................... 4 53 2 Contributors .......................................... 4 54 3 Terminology ........................................... 4 55 4 Introduction .......................................... 4 56 5 Existing Limitation of VPLS Multicast ................. 5 57 6 Overview .............................................. 5 58 7 VPLS Multicast / Broadcast / Unknown Unicast Data Packet Treatment 7 59 8 Propagating Multicast Control Information ............. 7 60 9 Multicast Tree Leaf Discovery ......................... 8 61 9.1 Inclusive Tree Leaf Discovery ......................... 8 62 9.2 Selective Tree Leaf Discovery ......................... 8 63 10 Demultiplexing Multicast Tree Traffic ................. 8 64 10.1 One Multicast Tree - One VPLS Mapping ................. 8 65 10.1.1 One Multicast Tree - Many VPLS Mapping ................ 8 66 11 Establishing Multicast Trees .......................... 9 67 11.1 RSVP-TE P2MP LSPs ..................................... 10 68 11.1.1 P2MP TE LSP - VPLS Mapping ............................ 10 69 11.1.2 Demultiplexing C-Multicast Data Packets ............... 10 70 11.2 Receiver Initiated MPLS Trees ......................... 10 71 11.2.1 P2MP LSP - VPLS Mapping ............................... 11 72 11.2.2 Demultiplexing C-Multicast Data Packets ............... 11 73 11.3 PIM Based Trees ....................................... 11 74 11.4 Encapsulation of the Aggregate Inclusive Tree and Aggregate Selective Tree 11 75 12 Tree to VPLS / C-Multicast Stream Binding Distribution ....12 76 13 Switching to Aggregate Selective Trees ................ 12 77 14 BGP Advertisements .................................... 13 78 14.1 Information Elements .................................. 13 79 14.1.1 Inclusive Tree - VPLS Binding Advertisement ........... 13 80 14.1.2 Selective Tree - C-Multicast Stream Binding Advertisement .14 81 14.1.3 Inclusive Tree/Selective Tree Identifier .............. 14 82 14.2 Encoding .............................................. 15 83 15 Aggregation Methodology ............................... 15 84 16 Data Forwarding ....................................... 16 85 16.1 MPLS Tree Encapsulation ............................... 16 86 16.2 IP Tree Encapsulation ................................. 17 87 17 Security Considerations ............................... 18 88 18 Acknowledgments ....................................... 18 89 19 Normative References .................................. 18 90 20 Informative References ................................ 19 91 21 Author Information .................................... 19 92 22 Intellectual Property Statement ....................... 19 93 23 Full Copyright Statement .............................. 20 94 1. Specification of requirements 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Contributors 102 Rahul Aggarwal 103 Yakov Rekhter 104 Juniper Networks 105 Yuji Kamite 106 NTT Communications 107 Luyuan Fang 108 AT&T 109 Chaitanya Kodeboniya 110 Juniper Networks 112 3. Terminology 114 This document uses terminology described in [VPLS-BGP] and [VPLS- 115 LDP]. 117 4. Introduction 119 [VPLS-BGP] and [VPLS-LDP] describe a solution for VPLS multicast that 120 relies on ingress replication. This solution has certain limitations 121 for certain VPLS multicast traffic profiles. This document describes 122 procedures for overcoming the limitations of existing VPLS multicast 123 solutions. 125 It describes procedures for VPLS multicast that utilize multicast 126 trees in the sevice provider (SP) network. 128 It provides mechanisms that allow a single multicast distribution 129 tree in the backbone to carry all the multicast traffic from a speci- 130 fied set of one or more VPLSs. Such a tree is referred to as an 131 "Inclusive Tree" and more specifically as an "Aggregate Inclusive 132 Tree" when the tree is used to carry multicast traffic from more than 133 VPLS. 135 This document also provides procedures by which a single multicast 136 distribution tree in the backbone can be used to carry traffic 137 belonging only to a specified set of one or more multicast groups, 138 from one or more VPLSs. Such a tree is referred to as a "Selective 139 Tree" and more specifically as an "Aggregate Selective Tree" when the 140 multicast groups belong to different VPLSs. So traffic from most mul- 141 ticast groups could be carried by an Inclusive Tree, while traffic 142 from, e.g., high bandwidth groups could be carried in one of the 143 "Selective Trees". 145 5. Existing Limitation of VPLS Multicast 147 VPLS multicast solutions described in [VPLS-BGP] and [VPLS-LDP] rely 148 on ingress replication. Thus the ingress PE replicates the multicast 149 packet for each egress PE and sends it to the egress PE using a uni- 150 cast tunnel. 152 This is a reasonable model when the bandwidth of the multicast traf- 153 fic is low or/and the number of replications performed on an average 154 on each outgoing interface for a particular customer VPLS multicast 155 packet is small. If this is not the case it is desirable to utilize 156 multicast trees in the SP core to transmit VPLS multicast packets 157 [VPLS-MCAST-REQ]. Note that unicast packets that are flooded to each 158 of the egress PEs, before the ingress PE performs learning for those 159 unicast packets, MAY still use ingress replication. 161 6. Overview 163 This document describes procedures for using multicast trees in the 164 SP network to transport VPLS multicast data packets. RSVP-TE P2MP 165 LSPs described in [RSVP-P2MP] are an example of such multicast trees. 166 The use of multicast trees in the SP network can be beneficial when 167 the bandwidth of the multicast traffic is high or when it is desir- 168 able to optimize the number of copies of a multicast packet transmit- 169 ted by the ingress. This comes at a cost of state in the SP core to 170 build multicast trees and overhead to maintain this state. This docu- 171 ment places no restrictions on the protocols used to build SP multi- 172 cast trees. 174 Multicast trees used for VPLS can be of two types: 175 1. Inclusive Trees. A single multicast distribution tree in the 176 SP backbone is used to carry all the multicast traffic from a speci- 177 fied set of one or more VPLSs. These multicast distribution trees can 178 be set up to carry the traffic of a single VPLS, or to carry the 179 traffic of multiple VPLSs. The ability to carry the traffic of more 180 than one VPLS on the same tree is termed 'Aggregation'. The tree will 181 include every PE that is a member of any of the VPLSs that are using 182 the tree. This enables the SP to place a bound on the amount of mul- 183 ticast routing state which the P routers must have. This implies that 184 a PE may receive multicast traffic for a multicast stream even if it 185 doesn't have any receivers on the path of that stream. 187 2. Selective Trees. A Selective Tree is used by a PE to send mul- 188 ticast traffic for one or more multicast streams, that belong to the 189 same or different VPLSs, to a subset of the PEs that belong to those 190 VPLSs. Each of the PEs in the subset are on the path to a receiver of 191 one or more multicast streams that are mapped onto the tree. The 192 ability to use the same tree for multicast streams that belong to 193 different VPLSs is termed 'Aggregation'. The reason for having Selec- 194 tive Trees is to provide a PE to have the ability to create separate 195 SP multicast trees for high bandwidth multicast groups. This allows 196 traffic for these multicast groups to reach only those PE routers 197 that have receivers in these groups. This avoids flooding other PE 198 routers in the VPLS. 200 A SP can use both Inclusive Trees and Selective Trees or either of 201 them for a given VPLS on a PE, based on local configuration. Inclu- 202 sive Trees can be used for both IP and non-IP data multicast traffic, 203 while Selective Trees can be used only for IP multicast data traffic. 205 In order to establish Inclusive and Selective multicast trees the 206 root of the tree must be able to discover the VPLS membership of all 207 the PEs and/or the multicast groups that each PE has receivers in. 208 This document describes procedures for doing this for Inclusive mul- 209 ticast trees. For discovering the IP multicast group membership pro- 210 cedures described in [VPLS-CTRL] are used. Procedures in [VPLS-CTRL] 211 can also be used with ingress replication to send traffic for a mul- 212 ticast stream to only those PEs that are on the path to receivers for 213 that stream. Aggregation also requires a mechanism for the egresses 214 of the tree to demultiplex the multicast traffic received over the 215 tree. This document describes how upstream label allocation by the 216 root of the tree can be used to perform this demultiplexing. This 217 document also describes procedures based on BGP that are used by the 218 root of an Aggregate Tree to advertise the Inclusive or Selective 219 tree binding and the demultiplexing information to the leaves of the 220 tree 222 This document uses the prefix 'C' to refer to the customer control or 223 data packets and 'P' to refer to the provider control or data pack- 224 ets. 226 7. VPLS Multicast / Broadcast / Unknown Unicast Data Packet Treatment 228 If the destination MAC address of a VPLS packet received by a PE from 229 a VPLS site is a multicast adddress, a multicast tree SHOULD be used 230 to transport the packet, if possible. If the packet is an IP multi- 231 cast packet and a Selective tree exists for that multicast stream, 232 the Selective tree SHOULD be used. Else if an Inclusive tree exists 233 for the VPLS, it SHOULD be used. 235 If the destination MAC address of a VPLS packet is a broadcast 236 address, it is flooded. If Inclusive tree is already established, PE 237 floods over it. If Inclusive Tree cannot be used for some reason, PE 238 MUST flood over multiple unicast PWs, based on [VPLS-BGP] [VPLS-LDP]. 240 If the destination MAC address of the packet has not been learned, 241 the flooding of the packet also occurs. Unlike broadcast case, it 242 should be noted that when a PE learns the MAC it might immediately 243 switch to transport over one particular PW. This implies that flood- 244 ing unknown unicast traffic over Inclusive Tree might lead to packet 245 reordering. This contraint should be taken into consideration if 246 unknown unicast frames are flooded using a Inclusive Tree, instead of 247 multiple unicast PWs based on [VPLS-BGP] [VPLS-LDP]. 249 P-multicast trees are intended to be used only for VPLS C-multicast 250 data packets, not for control packets being used by a customer's 251 layer-2 and layer-3 control protocols. For instance, Bridge Protocol 252 Data Units (BPDUs) use an IEEE assigned all bridges multicast MAC 253 address, and OSPF uses OSPF routers multicast MAC address. P-multi- 254 cast trees SHOULD NOT be used for transporting these control packets. 256 8. Propagating Multicast Control Information 258 PEs participating in VPLS need to learn the information 259 for two reasons: 260 1. With ingress replication, this allows a PE to send the IP mul- 261 ticast packet for a only to other PEs in the VPLS 262 instance, that have receivers interested in that particular . This eliminates flooding. 265 2. It allows the construction of Aggregate Selective Trees. 267 Procedures for learning the information are described in 268 [VPLS-CTRL]. 270 9. Multicast Tree Leaf Discovery 272 9.1. Inclusive Tree Leaf Discovery 274 VPLS auto-discovery as described in [VPLS-BGP, BGP-AUTO] or another 275 VPLS auto-discovery mechanism enables a PE to learn the VPLS member- 276 ship of other PEs. This is used by the root of the Tree to learn the 277 egresses of the tree. 279 9.2. Selective Tree Leaf Discovery 281 This is done using the C-Multicast control information propagation 282 described in [VPLS-CTRL]. 284 10. Demultiplexing Multicast Tree Traffic 286 Demultiplexing received VPLS traffic requires the receiving PE to 287 determine the VPLS instance the packet belongs to. The egress PE can 288 then perform a VPLS lookup to further forward the packet. 290 10.1. One Multicast Tree - One VPLS Mapping 292 When a multicast tree is mapped to only one VPLS, determining the 293 tree on which the packet is received is sufficient to determine the 294 VPLS instance on which the packet is received. The tree is determined 295 based on the tree encapsulation. If MPLS encapsulation is used, eg: 296 RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the 297 tree. Penultimate-hop-popping MUST be disabled on the RSVP-TE P2MP 298 LSP. 300 10.1.1. One Multicast Tree - Many VPLS Mapping 302 As traffic belonging to multiple VPLSs can be carried over the same 303 tree, there is a need to identify the VPLS the packet belongs to. 304 This is done by using an inner label that corresponds to the VPLS for 305 which the packet is intended. The ingress PE uses this label as the 306 inner label while encapsulating a customer multicast data packet. 307 Each of the egress PEs must be able to associate this inner label 308 with the same VPLS and use it to demultimplex the traffic received 309 over the Aggregate Inclusive Tree or the Aggregate Selective Tree. If 310 downstream label assignment were used this would require all the 311 egress PEs in the VPLS to agree on a common label for the VPLS. 313 We propose a solution that uses upstream label assignment by the 314 ingress PE [MPLS-UPSTREAM]. Hence the inner label is allocated by the 315 ingress PE. Each egress PE maintains a separate label space for every 316 other PE. The egress PEs create a forwarding entry for the inner VPN 317 label, allocated by the ingress PE, in this label space. Hence when 318 the egress PE receives a packet over an Aggregate Tree, the Tree 319 identifier specifies the label space to perform the inner label 320 lookup. The same label space may be used for all P-multicast trees 321 rooted at the same ingress PE, or an implementation may decide to use 322 a separate label space for every P-multicast tree. 324 When PIM based IP/GRE trees are used the root PE source address and 325 the tree P-group address identifies the tree interface. The label 326 space corresponding to the tree interface is the label space to per- 327 form the inner label lookup in. A lookup in this label space identi- 328 fies the VPLS in which the customer multicast lookup needs to be 329 done. 331 If the tree uses MPLS encapsulation the outer MPLS label and the 332 incoming interface provides the label space of the label beneath it. 333 This assumes that penultimate-hop-popping is disabled. An example of 334 this is RSVP-TE P2MP LSPs. The outer label and incoming interface 335 effectively identifies the Tree interface [MPLS-UPSTREAM, MPLS- 336 MCAST]. 338 The ingress PE informs the egress PEs about the inner label as part 339 of the tree binding procedures described in section 12. 341 11. Establishing Multicast Trees 343 This document does not place any restrictions on the multicast tech- 344 nology used to setup P-multicast trees. However specific procedures 345 are specified currently only for RSVP-TE P2MP LSPs, LDP P2MP LSPs and 346 PIM-SM and PIM-SSM based trees. 348 A P-multicast tree can be either a source tree or a shared tree. A 349 source tree is used to carry traffic only for the VPLSs that exist 350 locally on the root of the tree i.e. for which the root has local 351 CEs. A shared tree on the other hand can be used to carry traffic 352 belonging to VPLSs that exist on other PEs as well. For example a RP 353 based PIM-SM Aggregate tree would be a shared tree. Another example 354 of a shared tree is a RSVP-TE P2MP LSP. The shared tree root partici- 355 pates in VPLS auto-discovery. Each of the PEs transport the VPLS 356 traffic to the shared tree root using ingress replication. The shared 357 root splices the traffic onto the shared tree. 359 11.1. RSVP-TE P2MP LSPs 361 This section describes procedures that are specific to the usage of 362 RSVP-TE P2MP LSPs for instantiating a tree. The RSVP-TE P2MP LSP can 363 be either a source tree or a shared tree. Procedures in [RSVP-TE- 364 P2MP] are used to signal the LSP. The LSP is signaled after the root 365 of the LSP discovers the leaves. The egress PEs are discovered using 366 the procedures described in section 9. Aggregation as described in 367 this document is supported. 369 11.1.1. P2MP TE LSP - VPLS Mapping 371 P2MP TE LSP to VPLS mapping can be learned at the egress PEs using 372 BGP based advertisements of the P2MP TE LSP - VPLS mapping. They 373 require that the root of the tree include the P2MP TE LSP identifier 374 as the tunnel identifier in the BGP advertisements. This identifier 375 contains the following information elements: 376 - The type of the tunnel is set to RSVP-TE P2MP LSP 377 - RSVP-TE P2MP LSP's SESSION Object 378 - Optionally RSVP-TE P2MP LSP's SENDER_TEMPLATE Object 380 11.1.2. Demultiplexing C-Multicast Data Packets 382 Demultiplexing the C-multicast data packets at the egress PE require 383 that the PE be able to determine the P2MP TE LSP that the packets are 384 received on. The egress PE needs to determine the P2MP LSP to deter- 385 mine the VPLS that the packet belongs to, as described in section 10. 386 To achieve this the LSP must be signaled with penultimate-hop-popping 387 (PHP) off. This is because the egress PE needs to rely on the MPLS 388 label, that it advertises to its upstream neighbor, to determine the 389 P2MP LSP that a C-multicast data packet is received on. 391 11.2. Receiver Initiated MPLS Trees 393 Receiver initiated MPLS trees can also be used. An example of such 394 trees are LDP setup P2MP MPLS Trees [LDP-P2MP1, LDP-P2MP2]. 396 The LDP P2MP LSP can be either a source tree or a shared tree. Proce- 397 dures in [LDP-P2MP1, LDP-P2MP2] are used to signal the LSP. The LSP 398 is signaled after the root of the LSP discovers the leaves and once 399 the leaves receive the LDP FEC for the tree from the root. The egress 400 PEs are discovered using the procedures described in section 9. 401 Aggregation as described in this document is supported. 403 11.2.1. P2MP LSP - VPLS Mapping 405 P2MP LSP to VPLS mapping can be learned at the egress PEs using BGP 406 based advertisements of the P2MP LSP - VPLS mapping. They require 407 that the root of the tree include the P2MP LSP identifier as the tun- 408 nel identifier in the BGP advertisements. This identifier contains 409 the following information elements: 410 - The type of the tunnel is set to LDP P2MP LSP 411 - LDP P2MP FEC which includes an identifier generated by the 412 root. 414 Each egress PE "joins" the P2MP MPLS tree by sending LDP label map- 415 ping messages for the LDP P2MP FEC, that was learned in the BGP 416 advertisement, using procedures described in [LDP-P2MP1, LDP-P2MP2]. 418 11.2.2. Demultiplexing C-Multicast Data Packets 420 This follows the same procedures described above for RSVP-TE P2MP 421 LSPs. 423 11.3. PIM Based Trees 425 When PIM is used to setup multicast trees in the SP core the Aggre- 426 gate Inclusive Tree may be a shared tree, rooted at the RP, or a 427 shortest path tree. Aggregate Selective Tree is rooted at the PE that 428 is connected to the multicast traffic source. The root of the Aggre- 429 gate Tree or the Aggregate Selective Tree has to advertise the P- 430 Group address chosen by it for the tree to the PEs that are leaves of 431 the tree. These other PEs can then Join this tree. The announcement 432 of this address is done as part of the tree binding procedures 433 described in section 12. 435 11.4. Encapsulation of the Aggregate Inclusive Tree and Aggregate Selec- 436 tive Tree 438 An Aggregate Inclusive Tree or an Aggregate Selective Tree may use an 439 IP/GRE encapsulation or a MPLS encapsulation. The protocol type in 440 the IP/GRE header in the former case and the protocol type in the 441 data link header in the latter case are as described in [MPLS-MCAST]. 443 12. Tree to VPLS / C-Multicast Stream Binding Distribution 445 Once a PE sets up an Aggregate Inclusive Tree or an Aggregate Selec- 446 tive Tree it needs to announce the customer multicast groups being 447 mapped to this tree to other PEs in the network. This procedure is 448 referred to as Inclusive Tree or Selective Tree binding distribution 449 and is performed using BGP. For an Inclusive Tree this discovery 450 implies announcing the mapping of all VPLSs mapped to the Inclusive 451 Tree. The inner label allocated by the ingress PE for each VPLS is 452 included. The Inclusive Tree Identifier is also included. For an 453 Selective Tree this discovery implies announcing all the specific entries mapped to this tree along with the Selective 455 Tree Identifier. The inner label allocated for each is included. The Selective Tree Identifier is also included. 458 An Inclusive Tree by definition maps to all the 459 entries belonging to all the VPLSs associated with the Inclusive 460 Tree. An Selective Tree maps to the specific 461 associated with it. 463 When PIM or LDP is used to setup SP multicast trees, the egress PE 464 also Joins the P-Group Address or the LDP P2MP FEC corresponding to 465 the Inclusive or Selective tree. This results in setup of the 466 receiver driven multicast tree with IP or MPLS encapsulation. 468 13. Switching to Aggregate Selective Trees 470 Selective Trees provide a PE the ability to create separate SP multi- 471 cast trees for certain entires. The source PE that origi- 472 nates the Selective Tree and the egress PEs have to switch to using 473 the Selective Tree for the entries that are mapped to it. 475 Once a source PE decides to setup an Selective Tree, it announces the 476 mapping of the entries that are mapped on the tree to the 477 other PEs using BGP. Depending on the SP multicast technology used, 478 this announcement may be done before or after setting up the Selec- 479 tive Tree. After the egress PEs receive the announcement they setup 480 their forwarding path to receive traffic on the Selective Tree if 481 they have one or more receivers interested in the entries 482 mapped to the tree. This implies setting up the demultiplexing for- 483 warding entries based on the inner label as described earlier. The 484 egress PEs may perform this switch to the Selective Tree once the 485 advertisement from the ingress PE is received or wait for a precon- 486 figured timer to do so. 488 A source PE may use one of two approaches to decide when to start 489 transmitting data on the Selective tree. In the first approach once 490 the source PE sets up the Selective Tree, it starts sending multicast 491 packets for entries mapped to the tree on both that tree 492 as well as on the Inclusive Tree. After some preconfigured timer the 493 PE stops sending multicast packets for entries mapped on 494 the Selective Tree on the default tree. In the second approach a cer- 495 tain pre-configured delay after advertising the entries 496 mapped to an Selective Tree, the source PE begins to send traffic on 497 the Selective Tree. At this point it stops to send traffic for the 498 entries, that are mapped on the Selective Tree, on the 499 Inclusive Tree. This traffic is instead transmitted on the Selective 500 Tree. 502 14. BGP Advertisements 504 The procedures required in this document use BGP for P-Tree - VPLS 505 binding advertisements and P-Tree - Multicast stream binding adver- 506 tisement. This section first describes the information that needs to 507 be propagated in BGP for achieving the functional requirements. It 508 then describes a suggested encoding. 510 14.1. Information Elements 512 14.1.1. Inclusive Tree - VPLS Binding Advertisement 514 The root of an Aggregate Inclusive Tree maps one or more VPLS 515 instances to the Inclusive Tree. It announces this mapping in BGP. 516 Along with the VPLS instances that are mapped to the Inclusive Tree, 517 the Inclusive Tree identifier is also advertised in BGP. 519 The following information is required in BGP to advertise the VPLS 520 instance that is mapped to the Inclusive Tree: 521 1. The address of the router that is the root of the Inclusive 522 Tree. 523 2. The inner label allocated by the Inclusive Tree root for the 524 VPLS instance. The usage of this label is described in section 10. 526 When a PE distributes this information via BGP, it must include the 527 following: 528 1. An identifier of the Inclusive Tree. 529 2. Route Target Extended Communities attribute. This RT must be an 530 "Import RT" of each VSI in the VPLS. The BGP distribution procedures 531 used by [VPLS-BGP] or [BGP-AUTO] will then ensure that the advertised 532 information gets associated with the right VSIs. 534 14.1.2. Selective Tree - C-Multicast Stream Binding Advertisement 536 The root of an Aggregate Selective Tree maps one or more entries to the tree. These entries are advertised in BGP 538 along with the the Selective Tree identifier to which these entries 539 are mapped. 541 The following information is required in BGP to advertise the entries that are mapped to the Selective Tree: 543 1. The RD configured for the VPLS instance. This is required to 544 uniquely identify the as the addresses could 545 overlap between different VPLS instances. 546 2. The inner label allocated by the Selective Tree root for the 547 . The usage of this label is described in section 548 10. 549 3. The C-Source address. This address can be a prefix in order to 550 allow a range of C-Source addresses to be mapped to the Selective 551 Tree. 552 4. The C-Group address. This address can be a range in order to 553 allow a range of C-Group addresses to be mapped to the Selective 554 Tree. 556 When a PE distributes this information via BGP, it must include the 557 following: 558 1. An identifier of the Selective Tree. 559 2. Route Target Extended Communities attribute. This is used as 560 described in section 14.1.1. 562 14.1.3. Inclusive Tree/Selective Tree Identifier 564 Inclusive Tree and Selective Tree advertisements carry the Tree iden- 565 tifier. The following information elements are needed in this identi- 566 fier. 567 1. Whether this is a shared Inclusive Tree or not. 568 2. The type of the tree. For example the tree may use PIM-SM or 569 PIM-SSM. 570 3. The identifier of the tree. For trees setup using PIM the 571 identifier is a (S, G) value. 573 14.2. Encoding 575 Encoding details will be described later. 577 15. Aggregation Methodology 579 In general the herustics used to decide which VPLS instances or entries to aggregate is implementation dependent. It is also 581 conceivable that offline tools can be used for this purpose. This 582 section discusses some tradeoffs with respect to aggregation. 584 The "congruency" of aggregation is defined by the amount of overlap 585 in the leaves of the client trees that are aggregated on a SP tree. 586 For Aggregate Inclusive Trees the congruency depends on the overlap 587 in the membership of the VPLSs that are aggregated on the Aggregate 588 Inclusive Tree. If there is complete overlap aggregation is perfectly 589 congruent. As the overlap between the VPLSs that are aggregated 590 reduces, the congruency reduces. 592 If aggregation is done such that it is not perfectly congruent a PE 593 may receive traffic for VPLSs to which it doesn't belong. As the 594 amount of multicast traffic in these unwanted VPLSs increases aggre- 595 gation becomes less optimal with respect to delivered traffic. Hence 596 there is a tradeoff between reducing state and delivering unwanted 597 traffic. 599 An implementation should provide knobs to control the congruency of 600 aggregation. This will allow a SP to deploy aggregation depending on 601 the VPLS membership and traffic profiles in its network. If differ- 602 ent PEs or shared roots' are setting up Aggregate Inclusive Trees 603 this will also allow a SP to engineer the maximum amount of unwanted 604 VPLSs that a particular PE may receive traffic for. 606 The state/bandwidth optimality trade-off can be further improved by 607 having a versatile many-to-many association between client trees and 608 provider trees. Thus a VPLS can be mapped to multiple Aggregate 609 Trees. The mechanisms for achieving this are for further study. Also 610 it may be possible to use both ingress replication and an Aggregate 611 Tree for a particular VPLS. Mechanisms for achieving this are also 612 for further study. 614 16. Data Forwarding 616 16.1. MPLS Tree Encapsulation 618 The following diagram shows the progression of the VPLS IP multicast 619 packet as it enters and leaves the SP network when MPLS trees are 620 being used for multiple VPLS instances. RSVP-TE P2MP LSPs are exam- 621 ples of such trees. 623 Packets received Packets in transit Packets forwarded 624 at ingress PE in the service by egress PEs 625 provider network 627 +---------------+ 628 |MPLS Tree Label| 629 +---------------+ 630 | VPN Label | 631 ++=============++ ++=============++ ++=============++ 632 || C-IP Header || || C-IP Header || || C-IP Header || 633 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 634 || C-Payload || || C-Payload || || C-Payload || 635 ++=============++ ++=============++ ++=============++ 637 The receiver PE does a lookup on the outer MPLS tree label and deter- 638 mines the MPLS forwarding table in which to lookup the inner MPLS 639 label. This table is specific to the tree label space. The inner 640 label is unique within the context of the root of the tree (as it is 641 assigned by the root of the tree, without any coordination with any 642 other nodes). Thus it is not unique across multiple roots. So, to 643 unambiguously identify a particular VPLS one has to know the label, 644 and the context within which that label is unique. The context is 645 provided by the outer MPLS label [MPLS-UPSTREAM]. 647 The outer MPLS label is stripped. The lookup of the resulting MPLS 648 label determines the VSI in which the receiver PE needs to do the C- 649 multicast data packet lookup. It then strips the inner MPLS label and 650 sends the packet to the VSI for multicast data forwarding. 652 16.2. IP Tree Encapsulation 654 The following diagram shows the progression of the packet as it 655 enters and leaves the SP network when the Aggregate MDT or Aggregate 656 Selective MDTs are being used for multiple VPLS instances. MPLS-in- 657 GRE [MPLS-IP] encapsulation is used to encapsulate the customer mul- 658 ticast packets. 660 Packets received Packets in transit Packets forwarded 661 at ingress PE in the service by egress PEs 662 provider network 664 +---------------+ 665 | P-IP Header | 666 +---------------+ 667 | GRE | 668 +---------------+ 669 | VPN Label | 670 ++=============++ ++=============++ ++=============++ 671 || C-IP Header || || C-IP Header || || C-IP Header || 672 ++=============++ >>>>> ++=============++ >>>>> ++=============++ 673 || C-Payload || || C-Payload || || C-Payload || 674 ++=============++ ++=============++ ++=============++ 676 The P-IP header contains the Aggregate Tree (or Aggregate Selective 677 Tree) P-group address as the destination address and the root PE 678 address as the source address. The receiver PE does a lookup on the 679 P-IP header and determines the MPLS forwarding table in which to 680 lookup the inner MPLS label. This table is specific to the Aggregate 681 Tree (or Aggregate Selective Tree) label space. The inner label is 682 unique within the context of the root of the Tree (as it is assigned 683 by the root of the Tree, without any coordination with any other 684 nodes). Thus it is not unique across multiple roots. So, to unam- 685 biguously identify a particular VPLS one has to know the label, and 686 the context within which that label is unique. The context is pro- 687 vided by the P-IP header [MPLS-UPSTREAM]. 689 The P-IP header and the GRE header is stripped. The lookup of the 690 resulting MPLS label determines the VSI in which the receiver PE 691 needs to do the C-multicast data packet lookup. It then strips the 692 inner MPLS label and sends the packet to the VSI for multicast data 693 forwarding. 695 17. Security Considerations 697 Security considerations discussed in [VPLS-BGP] and [VPLS-LDP] apply 698 to this document. 700 18. Acknowledgments 702 Many thanks to Thomas Morin for his support of this work. 704 19. Normative References 706 [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- 707 els.", Bradner, March 1997 709 [RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in 710 BGP-4", RFC3107. 712 [VPLS-BGP] K. Kompella, Y. Rekther, "Virtual Private LAN Service", 713 draft-ietf-l2vpn-vpls-bgp-02.txt 715 [VPLS-LDP] M. Lasserre, V. Kompella, "Virtual Private LAN Services 716 over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt 718 [MPLS-IP] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP 719 or Generic Routing Encapsulation (GRE)", draft-ietf-mpls-in-ip-or- 720 gre-08.txt 722 [BGP-AUTO] H. Ould-Brahim et al., "Using BGP as an Auto-Discovery 723 Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn- 724 auto-04.txt 726 [VPLS-CTRL] R. Aggarwal, Y. Kamite, L. Fang, "Propagation of VPLS IP 727 Multicast Group Membership Information", draft-raggarwa-l2vpn-vpls- 728 mcast-ctrl-00.txt 730 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 731 Label Assignment and Context Specific Label Space", draft-raggarwa- 732 mpls-upstream-label-00.txt 734 [MPLS-MCAST] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS Mul- 735 ticast Encapsulations", draft-rosen-mpls-multicast-encaps-00.txt 737 [VPLS-MCAST-REQ] Y. kamite, et. al., "Requirements for Multicast Sup- 738 port in Virtual Private LAN Services", draft-kamite-l2vpn-vpls-mcast- 739 reqts-00.txt 741 20. Informative References 743 [MVPN] E. Rosen, R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf- 744 l3vpn-2547bis-mcast-00.txt" 746 [RSVP-P2MP] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to 747 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-02.txt 749 [LDP-P2MP1] I. Minei et. al, "Label Distribution Protocol Extensions 750 for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp- 751 p2mp-00.txt 753 [LDP-P2MP2] I. Wijnands et. al., "Multicast Extensions for LDP", 754 draft-wijnands-mpls-ldp-mcast-ext-00.txt 756 21. Author Information 758 Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, 759 CA 94089 Email: rahul@juniper.net 761 Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, 762 CA 94089 Email: yakov@juniper.net 764 Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 765 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan Email: 766 y.kamite@ntt.com 768 Luyuan Fang AT&T 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748 769 Phone: 732-420-1921 Email: luyuanfang@att.com 771 Chaitanya Kodeboniya Juniper Networks 1194 North Mathilda Ave. Sun- 772 nyvale, CA 94089 Email: ck@juniper.net 774 22. Intellectual Property Statement 776 The IETF takes no position regarding the validity or scope of any 777 Intellectual Property Rights or other rights that might be claimed to 778 pertain to the implementation or use of the technology described in 779 this document or the extent to which any license under such rights 780 might or might not be available; nor does it represent that it has 781 made any independent effort to identify any such rights. Information 782 on the procedures with respect to rights in RFC documents can be 783 found in BCP 78 and BCP 79. 785 Copies of IPR disclosures made to the IETF Secretariat and any assur- 786 ances of licenses to be made available, or the result of an attempt 787 made to obtain a general license or permission for the use of such 788 proprietary rights by implementers or users of this specification can 789 be obtained from the IETF on-line IPR repository at 790 http://www.ietf.org/ipr. 792 The IETF invites any interested party to bring to its attention any 793 copyrights, patents or patent applications, or other proprietary 794 rights that may cover technology that may be required to implement 795 this standard. Please address the information to the IETF at ietf- 796 ipr@ietf.org. 798 23. Full Copyright Statement 800 Copyright (C) The Internet Society (2005). This document is subject 801 to the rights, licenses and restrictions contained in BCP 78, and 802 except as set forth therein, the authors retain all their rights. 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 809 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 810 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.