idnits 2.17.1 draft-serbest-l2vpn-vpls-mcast-01.txt: -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1033): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1600. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'VPLS-BGP' is mentioned on line 130, but not defined == Unused Reference: 'VPLSD-BGP' is defined on line 1504, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Y. Serbest 2 Internet Engineering Task Force SBC 3 Document: Ray Qiu 4 draft-serbest-l2vpn-vpls-mcast-01.txt Venu Hemige 5 November 2004 Alcatel 6 Category: Informational Rob Nath 7 Expires: May 2005 Riverstone 9 Supporting IP Multicast over VPLS 11 Status of this memo 13 By submitting this Internet-Draft, we represent that any applicable 14 patent or other IPR claims of which we are aware have been 15 disclosed, or will be disclosed, and any of which we become aware 16 will be disclosed in accordance with RFC 3668. 18 This document is an Internet-Draft and is in full conformance with 19 Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In Virtual Private LAN Service (VPLS), the PE devices provide a 40 logical interconnect such that CE devices belonging to a specific 41 VPLS instance appear to be connected by a single LAN. A VPLS 42 solution performs replication for multicast traffic at the ingress 43 PE devices. When replicated at the ingress PE, multicast traffic 44 wastes bandwidth when 1. Multicast traffic is sent to sites with no 45 members, and 2. Pseudo wires to different sites go through a shared 46 path. This document is addressing the former by IGMP and PIM 47 snooping. 49 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC 2119. 54 Table of Contents 55 1 Contributing Authors..............................................3 56 2 Introduction......................................................3 57 3 Overview of VPLS..................................................4 58 4 Multicast Traffic over VPLS.......................................4 59 5 Constraining of IP Multicast in a VPLS............................5 60 5.1 General Rules for IGMP/PIM Snooping in VPLS....................6 61 5.2 IGMP Snooping for VPLS.........................................6 62 5.2.1 Discovering Multicast Routers...............................7 63 5.2.2 IGMP Join...................................................8 64 5.2.3 IGMP Leave.................................................12 65 5.2.4 Failure Scenarios..........................................13 66 5.3 PIM Snooping for VPLS.........................................13 67 5.3.1 PIM-DM.....................................................15 68 5.3.1.1 Discovering Multicast Routers............................15 69 5.3.1.2 PIM-DM Multicast Forwarding..............................16 70 5.3.1.3 PIM-DM Pruning...........................................16 71 5.3.1.4 PIM-DM Grafting..........................................17 72 5.3.1.5 Failure Scenarios........................................18 73 5.3.2 PIM-SM.....................................................18 74 5.3.2.1 Discovering Multicast Routers............................19 75 5.3.2.2 PIM-SM (*,G) Join........................................19 76 5.3.2.3 PIM-SM Pruning...........................................21 77 5.3.2.4 PIM-SM (S,G) Join........................................22 78 5.3.2.5 PIM-SM (*,*,RP) State....................................22 79 5.3.2.6 Failure Scenarios........................................23 80 5.3.2.7 Special Cases for PIM-SM Snooping........................23 81 5.3.3 PIM-SSM....................................................24 82 5.3.3.1 Discovering Multicast Routers............................25 83 5.3.3.2 Guidelines for PIM-SSM Snooping..........................25 84 5.3.3.3 PIM-SSM Join.............................................25 85 5.3.3.4 PIM-SSM Prune............................................26 86 5.3.3.5 Failure Scenarios........................................27 87 5.3.3.6 Special Cases for PIM-SSM Snooping.......................27 88 5.3.4 Bidirectional-PIM (BIDIR-PIM)..............................27 89 5.3.4.1 Discovering Multicast Routers............................27 90 5.3.4.2 Guidelines for BIDIR-PIM Snooping........................29 91 5.3.4.3 BIDIR-PIM Join...........................................29 92 5.3.4.4 BIDIR-PIM Prune..........................................30 93 5.3.4.5 Failure Scenarios........................................31 94 5.3.5 Multicast Source Directly Connected to the VPLS Instance...31 95 6 Security Considerations..........................................32 96 7 References.......................................................32 97 7.1 Normative References..........................................32 98 7.2 Informative References........................................32 99 8 Authors' Addresses...............................................32 100 9 Intellectual Property Statement..................................33 101 10 Full copyright statement......................................34 102 1 Contributing Authors 103 This document was the combined effort of several individuals. The 104 following are the authors, in alphabetical order, who contributed to 105 this document: 107 Suresh Boddapati 108 Venu Hemige 109 Sunil Khandekar 110 Vach Kompella 111 Marc Lasserre 112 Rob Nath 113 Ray Qiu 114 Yetik Serbest 116 2 Introduction 117 In Virtual Private LAN Service (VPLS), the Provider Edge (PE) 118 devices provide a logical interconnect such that Customer Edge (CE) 119 devices belonging to a specific VPLS instance appear to be connected 120 by a single LAN. Forwarding information base for particular VPLS 121 instance is populated dynamically by source MAC address learning. 122 This is a straightforward solution to support unicast traffic, with 123 reasonable flooding for unicast unknown traffic. Since a VPLS 124 provides LAN emulation for IEEE bridges as wells as for routers, the 125 unicast and multicast traffic need to follow the same path for 126 layer-2 protocols to work properly. As such, multicast traffic is 127 treated as broadcast traffic and is flooded to every site in the 128 VPLS instance. 130 VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication 131 for multicast traffic at the ingress PE devices. When replicated at 132 the ingress PE, multicast traffic wastes bandwidth when: 1. 133 Multicast traffic is sent to sites with no members, 2. Pseudo wires 134 to different sites go through a shared path, and 3. Multicast 135 traffic is forwarded along a shortest path tree as opposed to the 136 minimum cost spanning tree. This document is addressing the first 137 problem by IGMP and PIM snooping. Using VPLS in conjunction with 138 IGMP and/or PIM snooping has the following advantages: 139 - It improves VPLS to support IP multicast efficiently (not 140 necessarily optimum, as there can still be bandwidth waste), 141 - It prevents sending multicast traffic to sites with no members, 142 - It keeps P routers in the core stateless, 143 - The Service Provider (SP) does not need to perform the tasks to 144 provide multicast service (e.g., running PIM, managing P-group 145 addresses, managing multicast tunnels) 146 - The SP does not need to maintain PIM adjacencies with the 147 customers. 149 In this document, we describe the procedures for Internet Group 150 Management Protocol (IGMP) and Protocol Independent Multicast (PIM) 151 snooping over VPLS for efficient distribution of IP multicast 152 traffic. 154 3 Overview of VPLS 155 In case of VPLS, the PE devices provide a logical interconnect such 156 that CE devices belonging to a specific VPLS appear to be connected 157 by a single LAN. End-to-end VPLS consists of a bridge module and a 158 LAN emulation module ([L2VPN-FR]). 160 In a VPLS, a customer site receives Layer-2 service from the SP. 161 The PE is attached via an access connection to one or more CEs. The 162 PE performs forwarding of user data packets based on information in 163 the Layer-2 header, that is, MAC destination address. The CE sees a 164 bridge. 166 The details of VPLS reference model, which we summarize here, can be 167 found in [L2VPN_FR]. In VPLS, the PE can be viewed as containing a 168 Virtual Switching Instance (VSI) for each L2VPN that it serves. A 169 CE device attaches, possibly through an access network, to a bridge 170 module of a PE. Within the PE, the bridge module attaches, through 171 an Emulated LAN Interface to an Emulated LAN. For each VPLS, there 172 is an Emulated LAN instance. The Emulated LAN consists of VPLS 173 Forwarder module (one per PE per VPLS service instance) connected by 174 pseudo wires (PW), where the PWs may be traveling through Packet 175 Switched Network (PSN) tunnels over a routed backbone. VSI is a 176 logical entity that contains a VPLS forwarder module and part of the 177 bridge module relevant to the VPLS service instance [L2VPN-FR]. 178 Hence, the VSI terminates PWs for interconnection with other VSIs 179 and also terminates attachment circuits (ACs) for accommodating CEs. 180 A VSI includes the forwarding information base for a L2VPN [L2VPN- 181 FR] which is the set of information regarding how to forward Layer-2 182 frames received over the AC from the CE to VSIs in other PEs 183 supporting the same L2VPN service (and/or to other ACs), and 184 contains information regarding how to forward Layer-2 frames 185 received from PWs to ACs. Forwarding information bases can be 186 populated dynamically (such as by source MAC address learning) or 187 statically (e.g., by configuration). Each PE device is responsible 188 for proper forwarding of the customer traffic to the appropriate 189 destination(s) based on the forwarding information base of the 190 corresponding VSI. 192 4 Multicast Traffic over VPLS 193 In VPLS, if a PE receives a frame from an Attachment Circuit (AC) 194 with no matching entry in the forwarding information base for that 195 particular VPLS instance, it floods the frame to all other PEs 196 (which are part of this VPLS instance) and to directly connected ACs 197 (other than the one that the frame is received from). The flooding 198 of a frame occurs when: 199 - The destination MAC address has not been learned, 200 - The destination MAC address is a broadcast address, 201 - The destination MAC address is a multicast address. 203 Malicious attacks (e.g., receiving unknown frames constantly) aside, 204 the first situation is handled by VPLS solutions as long as 205 destination MAC address can be learned. After that point on, the 206 frames will not be flooded. A PE is REQUIRED to have safeguards, 207 such as unknown unicast limiting and MAC table limiting, against 208 malicious unknown unicast attacks. 210 There is no way around flooding broadcast frames. To prevent 211 runaway broadcast traffic from adversely affecting the VPLS service 212 and the SP network, a PE is REQUIRED to have tools to rate limit the 213 broadcast traffic as well. 215 Similar to broadcast frames, multicast frames are flooded as well, 216 as a PE can not know where multicast members reside. Rate limiting 217 multicast traffic, while possible, should be should be done 218 carefully since several network control protocols relies on 219 multicast. For one thing, layer-2 and layer-3 protocols utilize 220 multicast for their operation. For instance, Bridge Protocol Data 221 Units (BPDUs) use an IEEE assigned all bridges multicast MAC 222 address, and OSPF is multicast to all OSPF routers multicast MAC 223 address. If the rate-limiting of multicast traffic is not done 224 properly, the customer network will experience instability and poor 225 performance. For the other, it is not straightforward to determine 226 the right rate limiting parameters for multicast. 228 A VPLS solution MUST NOT affect the operation of customer layer-2 229 protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT 230 affect the operation of layer-3 protocols. 232 In the following section, we describe procedures to constrain the 233 flooding of IP multicast traffic in a VPLS. 235 5 Constraining of IP Multicast in a VPLS 236 The objective of improving the efficiency of VPLS for multicast 237 traffic that we are trying to optimize here has the following 238 constraints: 239 - The service is VPLS, i.e., a layer-2 VPN, 240 - In VPLS, ingress replication is required, 241 - There is no layer-3 adjacency (e.g., PIM) between a CE and a 242 PE. 244 Under these circumstances, the most obvious approach is 245 implementation of IGMP and PIM snooping in VPLS. Other multicast 246 routing protocols such as DVMRP and MOSPF are outside the scope of 247 this document. 249 Another approach to constrain multicast traffic in a VPLS is to 250 utilize point-multipoint LSPs (e.g., [PMP-RSVP-TE]). In such case, 251 one has to establish a point-multipoint LSP from a source PE (i.e., 252 the PE to which the source router is connected to) to all other PEs 253 participating in the VPLS instance. In this case, if nothing is 254 done, all PEs will receive multicast traffic even if they don�t have 255 any members hanging off of them. One can apply IGMP/PIM snooping, 256 but this time IGMP/PIM snooping should be done in P routers as well. 257 One can propose a dynamic way of establishing point-multipoint LSPs, 258 for instance by mapping IGMP/PIM messages to RSVP-TE signaling. One 259 should consider the effect of such approach on the signaling load 260 and on the delay between the time the join request received and the 261 traffic is received (this is important for IPTV application for 262 instance). This approach is outside the scope of this document. 264 Although, in some extremely controlled cases, such as a ring 265 topology of PE routers with no P routers or a tree topology, the 266 efficiency of the replication of IP multicast can be improved. For 267 instance, spoke PWs of a hierarchical VPLS can be daisy-chained 268 together and some replication rules can be devised. These cases are 269 not expected to be common and will not be considered in this 270 document. 272 In the following sections, we provide some guidelines for the 273 implementation of IGMP and PIM snooping in VPLS. 275 5.1 General Rules for IGMP/PIM Snooping in VPLS 276 The following rules for the correct operation of IGMP/PIM snooping 277 MUST be followed. 279 Rule 1: IGMP and PIM messages forwarded by PEs MUST follow the 280 split-horizon rule for mesh PWs as defined in [VPLS-LDP]. 282 Rule 2: IGMP/PIM snooping states in a PE MUST be per VPLS instance. 284 Rule 3: If a PE does not have any entry in a IGMP/PIM snooping state 285 for multicast group (*,G) or (S,G), the multicast traffic to that 286 group in the VPLS instance MUST be flooded. 288 Rule 4: A PE MUST support PIM mode selection per VPLS instance via 289 CLI and/or EMS. Another option could be to deduce the PIM mode from 290 RP address for a specific multicast group. For instance, a RP 291 address can be learned during the Designated Forwarder (DF) election 292 stage for Bidirectional-PIM. 294 5.2 IGMP Snooping for VPLS 295 IGMP is a mechanism to inform the routers on a subnet of a host�s 296 request to become a member of a particular multicast group. IGMP is 297 a stateful protocol. The router (i.e., the querier) regularly 298 verifies that the hosts want to continue to participate in the 299 multicast groups by sending periodic queries, transmitted to all 300 hosts multicast group (IP:224.0.0.1, MAC:01-00-5E-00-00-01) on the 301 subnet. If the hosts are still interested in that particular 302 multicast group, they respond with membership report message, 303 transmitted to the multicast group of which they are members. In 304 IGMPv1 [RFC1112], the hosts simply stop responding to IGMP queries 305 with membership reports, when they want to leave a multicast group. 306 IGMPv2 [RFC2236] adds a leave message that a host will use when it 307 needs to leave a particular multicast group. IGMPv3 [RFC3376] 308 extends the report/leave mechanism beyond multicast group to permit 309 joins and leaves to be issued for specific source/group (S,G) pairs. 311 In IGMP snooping, a PE snoops on the IGMP protocol exchange between 312 hosts and routers, and based on that restricts the flooding of IP 313 multicast traffic. In the following, we explore the mechanisms 314 involved in implementing IGMP snooping for VPLS. Please refer to 315 Figure 1 as an example of VPLS with IGMP snooping. In the figure, 316 Router 1 is the Querier. If multiple routers exist on a single 317 subnet (basically that is what a VPLS instance is), they can 318 mutually elect a designated router (DR) that will manage all of the 319 IGMP messages for that subnet. 321 VPLS Instance 322 +------+ AC1 +------+ +------+ AC4 +------+ 323 | Host |-----| PE |-------------| PE |-----|Router| 324 | 1 | | 1 |\ PW1to3 /| 3 | | 1 | 325 +------+ +------+ \ / +------+ +------+ 326 | \ / | 327 | \ / | 328 | \ /PW2to3 | 329 | \ / | 330 PW1to2| \ |PW3to4 331 | / \ | 332 | / \PW1to4 | 333 | / \ | 334 | / \ | 335 +------+ +------+ / \ +------+ +------+ 336 | Host | | PE |/ PW2to4 \| PE | |Router| 337 | 2 |-----| 2 |-------------| 4 |-----| 2 | 338 +------+ AC2 +------+ +------+ AC5 +------+ 339 | 340 |AC3 341 +------+ 342 | Host | 343 | 3 | 344 +------+ 346 Figure 1 Reference Diagram for IGMP Snooping for VPLS 348 5.2.1 Discovering Multicast Routers 349 A PE need to discover the multicast routers in VPLS instances. This 350 is necessary because: 351 - Designated Router can be different from the Querier on a LAN. 352 - It is not always the Querier that initiates PIM joins 353 - Multicast traffic to the LAN could arrive from a non-querying 354 router because it could be the closest to the source. 356 As recommended in [MAGMA-SNOOP], the PEs can discover multicast 357 routers using Multicast Router Discovery Protocol or they can be 358 statically configured. Since multicast routing protocols other than 359 PIM is out scope, multicast routers can also be discovered by 360 snooping PIM Hello packets as described in Section 5.3.1. 362 5.2.2 IGMP Join 363 The IGMP snooping mechanism for joining a multicast group (for all 364 IGMP versions) works as follows: 365 - The Querier sends a membership query to all hosts 366 (IP:224.0.0.1, MAC:01-00-5E-00-00-01). The membership query 367 can be either general query or group specific query. 368 - PE 3 replicates the query message and forwards it to all PEs 369 participating in the VPLS instance (i.e., PE 1, PE 2, PE 4). 370 - PE 3 notes that there is already a directly connected Querier. 371 Basically, it keeps a state of {[McastRouters: AC4, PW3to4], 372 [Querier: AC4], [(*,G); Hosts:]}, if it is a group specific 373 query. It keeps a state of {[McastRouters: AC4, PW3to4], 374 [Querier: AC4], [(*,*); Hosts:]}, if it is a general query. 375 - All PEs then forward the query to ACs which are part of the 376 VPLS instance. 377 - At this point all PEs learn the place of the Querier. For 378 instance, for PE 1 it is behind PW1to3, for PE 2 behind PW2to3, 379 for PE 3 behind AC4, for PE 4 behind PW3to4. 380 - Suppose that all hosts (Host 1, Host 2, and Host 3) want to 381 participate in the multicast group. 382 - Host 2 first (for the sake of the example) sends a membership 383 report to the multicast group (e.g., IP: 239.1.1.1, MAC: 01-00- 384 5E-01-01-01), of which Host 2 wants to be a member. 385 - PE 2 replicates the membership report message and forwards it 386 to all PEs participating in the VPLS instance (i.e., PE 1, PE 387 3, PE 4). 388 - PE 2 notes that there is a directly connected host, which is 389 willing to participate in the multicast group and updates its 390 state to {[McastRouters: PW2to3, PW2to4], [Querier: PW2to3], 391 [(*,G); Hosts:AC2]}. 393 Guideline 1: A PE MUST forward a membership report message to ACs 394 that are part of "McastRouters" state. This is necessary to avoid 395 report suppression for other members in order for the PEs to 396 construct correct states and to not have any orphan receiver 397 hosts. 399 There are still some scenarios that can result in orphan receivers. 400 For instance, a multicast router and some hosts could be connected 401 to a customer layer-2 switch, and that layer-2 switch can be 402 connected to a PE via an AC. In such scenario, the customer layer-2 403 switch MUST perform IGMP snooping as well, and it MUST NOT forward 404 the IGMP report messages coming from the PE to the hosts directly 405 connected to it. There can be some cases such that the layer-2 406 switch does not have IGMP snooping capability or that device is a 407 dummy hub/bridge. In such cases, one can statically configure the 408 AC, through which the IGMP incapable layer-2 device is connected, to 409 be a (S,G)/(*,G) member on the PE. This way, multicast traffic will 410 always be sent to the hosts connected to that layer-2 device, even 411 they don�t send joins because of join suppression. 413 Continuing with the example: 415 - PE 2 does not forward the membership report of Host 2 to Host 416 3. 417 - Per the guideline above, PE 1 does not forward the membership 418 report of Host 2 to Host 1. 419 - Per the guideline above, PE 3 does forward the membership 420 report of Host 2 to Router 1 (the Querier). 421 - PE 3 notes that there is a host in the VPLS instance, which is 422 willing to participate in the multicast group and updates its 423 state to {[McastRouters: AC4, PW3to4], [Querier: AC4], [(*,G); 424 Hosts: PW2to3]} regardless of the type of the query. 425 - Let�s assume that Host 1 subsequently sends a membership report 426 to the same multicast group. 427 - PE 1 replicates the membership report message and forwards it 428 to all PEs participating in the VPLS instance (i.e., PE 2, PE 429 3, PE 4). 430 - PE 1 notes that there is a directly connected host, which is 431 willing to participate in the multicast group. Basically, it 432 keeps a state of {[McastRouters: PW1to3, PW1to4], [Querier: 433 PW1to3], [(*,G); Hosts: AC1,PW1to2]}. 434 - Per Guideline 1, PE 2 does not forward the membership report of 435 Host 1 to Host 2 and Host 3. 436 - PE 3 and PE 4 receive the membership report message of Host 1 437 and check their states. Per Guideline 1, they send the report 438 to Router 1 and Router 2 respectively. They also update their 439 states to reflect Host 1. 440 - Now, Host 3 sends a membership report to the same multicast 441 group. 442 - PE 2 updates its state to {[McastRouters: PW2to3, PW2to4], 443 [Querier: PW2to3], [(*,G); Hosts: AC2,AC3,PW1to2]}. It then 444 floods the report message to all PEs participating in the VPLS 445 instance. Per Guideline 1, PE 3 forwards the membership report 446 of Host 3 to Router 1, and PE 4 forwards the membership report 447 of Host 3 to Router 2. 449 At this point, all PEs have necessary states to ensure that no 450 multicast traffic will be sent to sites with no members. 452 The previous steps work the same way for IGMPv1 and IGMPv2, when the 453 query is general or source specific. 455 The group and source specific query for IGMPv3 is considered 456 separately below. In IGMPv3, there is no simple membership join or 457 leave report. IGMPv3 reports are one of IS_INCLUDE, IS_EXCLUDE, 458 ALLOW, BLOCK, TO_INCLUDE, TO_EXCLUDE. The PEs MUST implement the 459 "router behavior" portion of the state machine defined in Section 6 460 of [RFC3376]. 462 The IGMP snooping mechanism for joining a multicast group (for 463 IGMPv3) works as follows: 464 - The Querier sends a membership query to all hosts 465 (IP:224.0.0.1, MAC:01-00-5E-00-00-01). The membership query is 466 group and source specific query with a list of sources (e.g., 467 S1, S2, .., Sn). 468 - PE 3 replicates the query message and forwards it to all PEs 469 participating in the VPLS instance (i.e., PE 1, PE 2, PE 4). 470 - PE 3 notes that there is already a directly connected Querier. 471 Basically, it keeps a state of {[McastRouters: AC4, PW3to4], 472 [Querier: AC4], [(S1,G); Hosts: ], [(S2,G); Hosts: ], .., 473 [(Sn,G); Hosts: ]}. 474 - All PEs then forward the query to ACs which are part of the 475 VPLS instance. 476 - At this point, all PEs learn the place of the Querier. 477 - Suppose that all hosts (Host 1, Host 2, and Host 3) want to 478 participate in the multicast group. Host 1 and Host 2 want to 479 subscribe to (Sn,G), and Host 3 wants to subscribe to (S3,G). 480 - Host 2 first (for the sake of the example) sends a membership 481 report message with group record type IS_INCLUDE for (Sn,G) to 482 IP address of 224.0.0.22 (MAC:01-00-5E-00-00-16). 483 - PE 2 replicates the membership report message and forwards it 484 to all PEs participating in the VPLS instance (i.e., PE 1, PE 485 3, PE 4). 486 - PE 2 notes that there is a directly connected host, which is 487 willing to participate in the multicast group and updates its 488 state to {[McastRouters: PW2to3, PW2to4], [Querier: PW2to3], 489 [(S1,G); Hosts: ], [(S2,G); Hosts: ], .., [(Sn,G); Hosts: 490 AC2]}. 491 - Per Guideline 1, PE 2 does not forward the membership report of 492 Host 2 to Host 3. 494 - Per Guideline 1, PE 1 does not forward the membership report of 495 Host 2 to Host 1. 496 - Per Guideline 1, PE 3 does forward the membership report of 497 Host 2 to Router 1 (the Querier). 498 - Per Guideline 1, PE 4 does forward the membership report of 499 Host 2 to Router 2. 500 - PE 3 notes that there is a host in the VPLS instance, which is 501 willing to participate in the multicast group. Basically, it 502 updates its state to {[McastRouters: AC4, PW3to4], [Querier: 503 AC4], [(S1,G); Hosts: ], [(S2,G); Hosts: ], .., [(Sn,G); Hosts: 504 PW2to3]}. 505 - Likewise, PE 4 updates its state to {[McastRouters: PW3to4, 506 AC5], [Querier: PW3to4], [(S1,G); Hosts: ], [(S2,G); Hosts: ], 507 .., [(Sn,G); Hosts: PW2to4]}. 508 - Let�s say Host 1 now sends a membership report message with 509 group record type IS_INCLUDE for (Sn,G). 510 - Similar procedures are followed by PEs as explained in the 511 previous steps. For instance, PE 1 updates its state to 512 {[McastRouters: PW1to3, PW1to4], [Querier: PW1to3], [(S1,G); 513 Hosts: ], [(S2,G); Hosts: ], .., [(Sn,G); Hosts: PW1to2, AC1]}. 514 PE 3 updates its state to {[McastRouters: AC4, PW3to4], 515 [Querier: AC4], [(S1,G); Hosts: ], [(S2,G); Hosts: ], .., 516 [(Sn,G); Hosts: PW2to3, PW1to4]}. 517 - Finally, Host 3 sends a membership report message with group 518 record type IS_INCLUDE for (S3,G). 519 - PE 2 replicates the membership report message and forwards it 520 to all PEs participating in the VPLS instance (i.e., PE 1, PE 521 3, PE 4). 522 - Per Guideline 1, PE 2 does not forward the membership report of 523 Host 3 to Host 2. 524 - Per Guideline 1, PE 1 does not forward the membership report of 525 Host 3 to Host 1. 526 - Per Guideline 1, PE 3 does forward the membership report of 527 Host 3 to Router 1. 528 - Per Guideline 1, PE 4 does forward the membership report of 529 Host 3 to Router 2. 530 - All PEs update their states accordingly. For instance, PE 2 531 updates its state to {[McastRouters: PW2to3, PW2to4], [Querier: 532 PW2to3], [(S1,G); Hosts: ], .., [(S3,G); Hosts: AC3], .., 533 [(Sn,G); Hosts: PW1to2, AC2]}. PE 4 updates its state to 534 {[McastRouters: AC5, PW3to4], [Querier: PW3to4], [(S1,G); 535 Hosts: ], .., [(S3,G); Hosts: PW2to4], .., [(Sn,G); Hosts: 536 PW1to4, PW2to4]}. 538 At this point, all PEs have necessary states to not send multicast 539 traffic to sites with no members. 541 Based on above description of IGMPv3 based snooping for VPLS, one 542 may conclude that the PEs MUST have the capability to store (S,G) 543 state and MUST forward/replicate traffic accordingly. This is, 544 however, not MANDATORY. A PE MAY only keep (*,G) based states 545 rather than on a per (S,G) basis with the understanding that this 546 will result in a less efficient IP multicast forwarding within each 547 VPLS instance. 549 Guideline 2: If a PE receives unsolicited report message and if it 550 does not possess a state for that particular multicast group, it 551 MUST flood that unsolicited membership report message to all PEs 552 participating in the VPLS instance, as well as to the multicast 553 router if it is locally attached. 555 5.2.3 IGMP Leave 556 The IGMP snooping mechanism for leaving a multicast group works as 557 follows: 558 - In the case of IGMPv2, when a PE receives a leave (*,G)/(S,G) 559 message from a host via its AC, it removes the AC from its 560 state. 561 - In the case of IGMPv3, when a PE receives a membership report 562 message with group record type of IS_EXCLUDE or TO_EXCLUDE or 563 BLOCK for (S,G) from a host via its AC, it removes the AC from 564 its state. 566 In the following guideline, a "leave (*,G)/(S,G) message" also means 567 IGMPv3 membership report message with group record type of 568 IS_EXCLUDE or TO_EXCLUDE or BLOCK for (S,G). 570 Guideline 3: A PE MUST NOT forward a leave (*,G)/(S,G) message to 571 ACs participating in the VPLS instance, If the PE still has 572 locally connected hosts or hosts connected over a H-VPLS spoke in 573 its state. 575 Guideline 4: A PE MUST forward a leave (*,G)/(S,G) message to all 576 PEs participating in the VPLS instance. A PE MAY forward the 577 leave (*,G)/(S,G) message to the "McastRouters" ONLY, if there are 578 no member hosts in its state. 580 Guideline 5: In case of IGMPv1, If a PE does not receive a 581 membership report from an AC for the three consecutive queries, 582 the PE MUST remove the AC from its state. In case of IGMPv2 and 583 IGMPv3, If a PE does not receive a membership report from an AC 584 for the two consecutive "Last Member Query Intervals", the PE MUST 585 remove the AC from its state. 587 5.2.4 Failure Scenarios 588 Up to now, we did not consider any failures, which we will focus in 589 this section. 590 - In case the Querier fails (e.g., AC to the querier fails), 591 another router in the VPLS instance will be selected as the 592 Querier. The new Querier will be sending queries. In such 593 circumstances, the IGMP snooping states in the PEs will be 594 updated/overwritten by the same procedure explained above. 595 - In case a Multicast router fails, the IGMP snooping states in 596 the PEs will be updated/overwritten by the multicast router 597 discovery procedures provided in Section 5.2.1. 598 - In case a host fails (e.g., AC to the host fails), a PE removes 599 the host from its IGMP snooping state for that particular 600 multicast group. Guidelines 3, 4 and 5 still apply here. 601 - In case a PW (which is in IGMP snooping state) fails, the PEs 602 will remove the PW from their IGMP snooping state. For 603 instance, if PW1to3 fails, then PE 1 will remove PW1to3 from 604 its state as the Querier connection, and PE 3 will remove 605 PW1to3 from its state as one of the host connections. 606 Guidelines 3, 4 and 5 still apply here. After PW is restored, 607 the IGMP snooping states in the PEs will be updated/overwritten 608 by the same procedure explained above. One can implement a 609 dead timer before making any changes to IGMP snooping states 610 upon PW failure. In that case, IGMP snooping states will be 611 altered if the PW can not be restored before the dead timer 612 expires. 614 5.3 PIM Snooping for VPLS 615 IGMP snooping procedures described above provide efficient delivery 616 of IP multicast traffic in a given VPLS service when end stations 617 are connected to the VPLS. However, when VPLS is offered as a WAN 618 service it is likely that the CE devices are routers and would run 619 PIM between them. To provide efficient IP multicasting in such 620 cases, it is necessary that the PE routers offering the VPLS service 621 do PIM snooping. This section describes the procedures for PIM 622 snooping. 624 PIM is a multicast routing protocol, which runs exclusively between 625 routers. PIM shares many of the common characteristics of a routing 626 protocol, such as discovery messages (e.g., neighbor discovery using 627 Hello messages), topology information (e.g., multicast tree), and 628 error detection and notification (e.g., dead timer and designated 629 router election). On the other hand, PIM does not participate in 630 any kind of exchange of databases, as it uses the unicast routing 631 table to provide reverse path information for building multicast 632 trees. There are a few variants of PIM. In PIM-DM ([PIM-DM]), 633 multicast data is pushed towards the members similar to broadcast 634 mechanism. PIM-DM constructs a separate delivery tree for each 635 multicast group. As opposed to PIM-DM, other PIM versions (PIM-SM 636 [RFC2362], PIM-SSM [PIM-SSM], and BIDIR-PIM [BIDIR-PIM]) invokes a 637 pull methodology instead of push technique. 639 PIM routers periodically exchange Hello messages to discover and 640 maintain stateful sessions with neighbors. After neighbors are 641 discovered, PIM routers can signal their intentions to join/prune 642 specific multicast groups. This is accomplished by having 643 downstream routers send an explicit join message (for the sake of 644 generalization, consider Graft messages for PIM-DM as join messages) 645 to the upstream routers. The join/prune message can be group 646 specific (*,G) or group and source specific (S,G). 648 In PIM snooping, a PE snoops on the PIM message exchange between 649 routers, and builds its multicast states. Based on the multicast 650 states, it forwards IP multicast traffic accordingly to avoid 651 unnecessary flooding. 653 In the following, the mechanisms involved for implementing PIMv2 654 ([RFC2362]) snooping in VPLS are specified. PIMv1 is out of the 655 scope of this document. Please refer to Figure 2 as an example of 656 VPLS with PIM snooping. 658 VPLS Instance 659 +------+ AC1 +------+ +------+ AC4 +------+ 660 |Router|-----| PE |-------------| PE |-----|Router| 661 | 1 | | 1 |\ PW1to3 /| 3 | | 4 | 662 +------+ +------+ \ / +------+ +------+ 663 | \ / | 664 | \ / | 665 | \ /PW2to3 | 666 | \ / | 667 PW1to2| \ |PW3to4 668 | / \ | 669 | / \PW1to4 | 670 | / \ | 671 | / \ | 672 +------+ +------+ / \ +------+ +------+ 673 |Router| | PE |/ PW2to4 \| PE | |Router| 674 | 2 |-----| 2 |-------------| 4 |-----| 5 | 675 +------+ AC2 +------+ +------+ AC5 +------+ 676 | 677 |AC3 678 +------+ 679 |Router| 680 | 3 | 681 +------+ 683 Figure 2 Reference Diagram for PIM Snooping for VPLS 685 In the following sub-sections, snooping mechanisms for each variety 686 of PIM are specified. 688 5.3.1 PIM-DM 689 The characteristics of PIM-DM is flood and prune behavior. Shortest 690 path trees are built as a multicast source starts transmitting. 692 In Figure 2, the multicast source is behind Router 4, and all 693 routers have at least one receiver except Router 3 and Router 5. 695 5.3.1.1 Discovering Multicast Routers 696 The PIM-DM snooping mechanism for neighbor discovery works as 697 follows: 698 - To establish PIM neighbor adjacencies, PIM multicast routers 699 (all routers in this example) send PIM Hello messages to the 700 ALL PIM Routers group address (IPv4: 224.0.0.13, MAC: 01-00-5E- 701 00-00-0D) on every PIM enabled interfaces. The IPv6 ALL PIM 702 Routers group is "ff02::d". In addition, PIM Hello messages 703 are used to elect Designated Router for a multi-access network. 704 In PIM-DM, the DR acts as the Querier if IGMPv1 is used. 705 Otherwise, DR has no function in PIM-DM. 707 Guideline 6: PIM Hello messages MUST be flooded in the VPLS 708 instance. A PE MUST populate its "PIM Neighbors" list according 709 to the snooping results. This is a general PIM snooping guideline 710 and applies to all variants of PIM snooping. 712 Guideline 7: For PIM-DM only. The "Flood to" list is populated 713 with the ACs/PWs in the "PIM Neighbors" list. Changes to the "PIM 714 Neighbors" list MUST be replicated to the "Flood to" list. 716 - Every router starts sending PIM Hello messages. Per Guideline 717 6, every PE replicates Hello messages and forwards them to all 718 PEs participating in the VPLS instance. 719 - Based on PIM Hello exchanges PE routers populate PIM snooping 720 states as follows. PE 1: {[(,); Source:; Flood to: AC1, 721 PW1to2, PW1to3, PW1to4], [PIM Neighbors: (Router 1,AC1), 722 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 723 5,PW1to4)] }, PE 2: {[(,); Source:; Flood to: AC2, AC3, PW1to2, 724 PW2to3, PW2to4], [PIM Neighbors: (Router 1,PW1to2), (Router 725 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, 726 PE 3: {[(,); Source:; Flood to: AC4, PW1to3, PW2to3, PW3to4], 727 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 728 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Source:; 729 Flood to: AC5, PW1to4, PW2to4, PW3to4], [PIM Neighbors: (Router 730 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 731 (Router 5,AC5)]}. The original "Flood to" list is populated 732 with ACs/PWs in the PIM neighbor list per Guideline 7.. 733 - PIM Hello messages contain a Holdtime value, which tells the 734 receiver when to expire the neighbor adjacency (which is three 735 times the Hello period). 737 Guideline 8: If a PE does not receive a Hello message from a 738 router within its Holdtime, the PE MUST remove that router from 739 the PIM snooping state. If a PE receives a Hello message from a 740 router with Holdtime value set to zero, the PE MUST remove that 741 router from the PIM snooping state immediately. PEs MUST track 742 the Hello Holdtime value per PIM neighbor. 744 5.3.1.2 PIM-DM Multicast Forwarding 745 The PIM-DM snooping mechanism for multicast forwarding works as 746 follows: 747 - When the source starts sending traffic to multicast group 748 (S,G), PE 3 updates its state to PE 3: {[(S,G) ; Source: 749 (Router 4,AC4); Flood to: PW1to3, PW2to3, PW3to4], [PIM 750 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 751 (Router 4,AC4), (Router 5,PW3to4)]}. AC4 is removed from the 752 "Flood to" list for (S,G), since it is where the multicast 753 traffic comes from. 755 Guideline 9: Multicast traffic MUST be replicated per PW and AC 756 basis, i.e., even if there are more than one PIM neighbor behind a 757 PW/AC, only one replication MUST be sent to that PW/AC. 759 - PE 3 replicates the multicast traffic and sends it to the other 760 PE routers in its "Flood to" list. 761 - Consequently, all PEs update their states as follows. PE 1: 762 {[(S,G); Source: (Router 4,PW1to3); Flood to: AC1], [PIM 763 Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 764 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S,G); Source: (Router 765 4,PW2to3); Flood to: AC2, AC3], [PIM Neighbors: (Router 766 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 767 (Router 5,PW2to4)]}, PE 4: {[(S,G); Source: (Router 4,PW3to4); 768 Flood to: AC5], [PIM Neighbors: (Router 1,PW1to4), (Router 769 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 771 5.3.1.3 PIM-DM Pruning 772 At this point all the routers (Router 1, Router 2,Router 3, Router 773 5) receive the multicast traffic. 775 - However, Router 3 and Router 5 do not have any members for that 776 multicast group, so they send prune messages to leave the 777 multicast group to the ALL PIM Routers group. PE 2 updates its 778 state to PE 2: {[(S,G); Source: (Router 4,PW2to3); Flood to: 779 AC2], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), 780 (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}. PE 4 781 also remove Router 3 and Router 5 from its state as well. 783 Guideline 10: For PIM-DM only. PIM prune messages MUST be flooded 784 in the VPLS instance. 786 - PE 2 and PE 4 then flood the prune message and forward it to 787 all PEs participating in the VPLS instance per Guideline 10. 788 PE 4 updates its state to PE 4: {[(S,G); Source: (Router 789 4,AC4); Flood to:], [PIM Neighbors: (Router 1,PW1to4), (Router 790 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 791 - PIM-DM prune messages contain a Holdtime value, which specifies 792 how many seconds the prune state should last. 794 Guideline 11: For PIM-DM only. A PE MUST keep the prune state for 795 a PW/AC according to the Holdtime in the prune message, unless a 796 corresponding Graft message is received. 798 - Upon receiving the prune messages, each PE updates its state 799 accordingly. PE 1: {[(S,G); Source: (Router 4,PW1to3); Flood 800 to: AC1], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3, 801 PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S,G); 802 Source: (Router 4,PW2to3); Flood to: AC2], [PIM Neighbors: 803 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 804 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(S,G); Source: (Router 805 4,AC4); Flood to: PW1to3, PW2to3], [PIM Neighbors: (Router 806 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 807 5, PW3to4)]}, PE 4: {[(S,G); Source: (Router 4,PW3to4); Flood 808 to:], [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 809 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 811 Guideline 12: For PIM-DM only. To avoid overriding joins, a PE 812 SHOULD suppress the PIM prune messages to directly connected 813 routers (i.e., ACs), as long as there is a PW/AC in its 814 corresponding "Flood to" list. 816 - In this case, PE 1, PE 2, and PE 3 do not forward the prune 817 messages to their directly connected routers. 819 5.3.1.4 PIM-DM Grafting 820 The multicast traffic is now flowing only to points in the network 821 where receivers are present. 823 Guideline 13: For PIM-DM only. A PE MUST remove the AC/PW from 824 its corresponding prune state when it receives a graft message 825 from the AC/PW. That is, the corresponding AC/PW MUST be added to 826 the "Flood to" list. 828 Guideline 14: For PIM-DM only. PIM-DM graft messages MUST be 829 forwarded based on the destination MAC address. If the 830 destination MAC address is 01-00-5E-00-00-0D, then the graft 831 message MUST be flooded in the VPLS instance. 833 - For the sake of example, suppose now Router 3 has a receiver 834 the multicast group (S,G). Assuming Router 3 sends a graft 835 message in IP unicast to Router 4 to restart the flow of 836 multicast traffic. PE 2 updates its state to PE 2: {[(S,G); 837 Source: (Router 4,PW2to3); Flood to: AC2, AC3], [PIM Neighbors: 838 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 839 4,PW2to3), (Router 5,PW2to4)]}. PE 2 then forwards the graft 840 message to PE 3 according to Guideline 14. 841 - Upon receiving the graft message, PE 3 updates its state 842 accordingly to PE 3: {[(S,G); Source: (Router 4,AC4); Flood to: 843 PW1to3, PW2to3], [PIM Neighbors: (Router 1,PW1to3), (Router 844 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}. 846 5.3.1.5 Failure Scenarios 847 Guideline 15: PIM Assert messages MUST be flooded in the VPLS 848 instance. 850 Guideline 16: If an AC/PW goes down, a PE MUST remove it from its 851 PIM snooping state. 853 Failures can be easily handled in PIM-DM snooping, as it uses push 854 technique. If an AC or a PW goes down, PEs in the VPLS instance 855 will remove it from their snooping state (if the AC/PW is not 856 already pruned). After the AC/PW comes back up, it will be 857 automatically added to the snooping state by PE routers, as all 858 PWs/ACs MUST be in the snooping state, unless they are pruned later 859 on. 861 5.3.2 PIM-SM 862 The key characteristics of PIM-SM is explicit join behavior. In 863 this model, the multicast traffic is only sent to locations that 864 specifically request it. The root node of a tree is the Rendezvous 865 Point (RP) in case of a shared tree or the first hop router that is 866 directly connected to the multicast source in the case of a shortest 867 path tree. 869 In Figure 2, the RP is behind Router 4, and all routers have at 870 least one member except Router 3 and Router 5. 872 As in the case with IGMPv3 snooping, we assume that the PEs have the 873 capability to store (S,G) states for PIM-SM snooping and 874 forward/replicate traffic accordingly. This is not mandatory. An 875 implementation, can fall back to (*,G) states, if its hardware can 876 not support it. In such case, the efficiency of multicast 877 forwarding will be less. 879 5.3.2.1 Discovering Multicast Routers 880 The PIM-SM snooping mechanism for neighbor discovery works the same 881 way as the procedure defined in PIM-DM section, with the exception 882 of PIM-DM only guidelines. 883 - Based on PIM Hello exchanges PE routers populate PIM snooping 884 states as follows. PE 1: {[(,); Flood to:], [PIM Neighbors: 885 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 886 (Router 5,PW1to4)]}, PE 2: {[(,); Flood to:], [PIM Neighbors: 887 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 888 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(,); Flood to:], [PIM 889 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 890 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to:], 891 [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 892 (Router 4,PW3to4), (Router 5,AC5)]}. 894 For PIM-SM to work properly, all routers within the domain must use 895 the same mappings of group addresses to RP addresses. Currently, 896 there are three methods for RP discovery: 1. Static RP 897 configuration, 2, Auto-RP, and 3. PIMv2 Bootstrap Router mechanism. 899 Guideline 17: Cisco RP-Discovery (IP:224.0.1.40, MAC:01-00-5E-00- 900 01-28), Cisco-RP-Announce (IP:224.0.1.39, MAC:01-00-5E-00-01-27), 901 all bootstrap router (BSR) (IP:224.0.0.13, MAC:01-00-5E-00-00-0D) 902 messages MUST be flooded in the VPLS instance. 904 5.3.2.2 PIM-SM (*,G) Join 905 The PIM-SM snooping mechanism for joining a multicast group (*,G) 906 works as follows: 908 Guideline 18: PIM-SM join messages MUST be sent only to the remote 909 PE, which is connected to the router to which the Join is 910 addressed. 912 PIM-SM join messages MUST be sent only to the remote PE, which is 913 connected to the router to which the Join is addressed. The remote 914 PE can be determined by the "Upstream Neighbor Address" field of the 915 Join message. The "Upstream Neighbor Address" can be correlated to a 916 PW or an AC in the "PIM Neighbors" state. By Guideline 18, we are 917 ensuring that the other routers that are part of the VPLS instance 918 do not receive the PIM join messages and will initiate their own 919 join messages if they are interested in receiving that particular 920 multicast traffic. 922 - Assume Router 1 wants to join the multicast group (*,G) sends a 923 join message for the multicast group (*,G). PE 1 sends the 924 join message to PE 3 by Guideline 18. 926 Guideline 19: A PE MUST add a PW/AC to its (*,G) "Flood to" list, 927 if it receives a (*,G) join message from the PW/AC. 929 - PE 1 updates their states as follows: PE 1: {[(*,G); Flood to: 930 AC1], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 931 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}. 933 A periodic refresh mechanism is used in PIM-SM to maintain the 934 proper state. PIM-SM join messages contain a Holdtime value, which 935 specifies for how many seconds the join state should be kept. 937 Guideline 20: If a PE does not receive a refresh join message from 938 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 939 "Flood to" list. 941 - All PEs update their states accordingly as follows: PE 1: 942 {[(*,G); Flood to: AC1], [PIM Neighbors: (Router 1,AC1), 943 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 944 5,PW1to4)]}, PE 2: {[(,); Flood to: ], [PIM Neighbors: (Router 945 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 946 (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood to: PW1to3], [PIM 947 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 948 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to: ], 949 [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 950 (Router 4,PW3to4), (Router 5,AC5)]}. 951 - After Router 2 joins the same multicast group, the states 952 become as follows: PE 1: {[(*,G); Flood to: AC1], [PIM 953 Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 954 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(*,G); Flood to: AC2], 955 [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 956 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(*,G); 957 Flood to: PW1to3, PW2to3], [PIM Neighbors: (Router 1,PW1to3), 958 (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 959 5,PW3to4)]}, PE 4: {[(,); Flood to: ], [PIM Neighbors: (Router 960 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 961 (Router 5,AC5)]}. 962 - For the sake of example, Router 3 joins the multicast group. 963 PE 2 sends the join message to PE 3. 965 - Next Router 5 joins the group, and the states are updated 966 accordingly: PE 1: {[(*,G); Flood to: AC1], [PIM Neighbors: 967 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 968 (Router 5,PW1to4)]}, PE 2: {[(*,G); Flood to: AC2, AC3], [PIM 969 Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), 970 (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood 971 to: PW1to3, PW2to3, PW3to4], [PIM Neighbors: (Router 1,PW1to3), 972 (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 973 5,PW3to4)]}, PE 4: {[(*,G); Flood to: AC5],[PIM Neighbors: 974 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 975 4,PW3to4), (Router 5,AC5)]} 977 At this point, all PEs have necessary states to not send multicast 978 traffic to sites with no members. 980 5.3.2.3 PIM-SM Pruning 981 The PIM-SM snooping mechanism for leaving a multicast group works as 982 follows: 983 - Assume Router 5 sends a prune message. 985 Guideline 21: PIM-SM prune messages MUST be flooded in the VPLS 986 instance. 988 Guideline 22: A PE MUST remove a PW/AC from its (*,G) "Flood to" 989 list if it receives a (*,G) prune message from the PW/AC. A 990 prune-delay timer SHOULD be implemented to support prune override. 992 - PE 4 floods the (*,G) prune to the VPLS instance per Guideline 993 21. PE routers participating in the VPLS instance also forward 994 the (*,G) prune to the ACs, which are connected to the VPLS 995 instance. The states are updated as follows: PE 1: {[(*,G); 996 Flood to: AC1], [PIM Neighbors: (Router 1,AC1), (Router 997 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 998 2: {[(*,G); Flood to: AC2, AC3], [PIM Neighbors: (Router 999 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1000 (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood to: PW1to3, PW2to3], 1001 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1002 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to: 1003 ],[PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 1004 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1006 In PIM-SM snooping, prune messages are flooded by PE routers. In 1007 such implementation, PE routers may receive overriding join 1008 messages, which will not affect anything. 1010 5.3.2.4 PIM-SM (S,G) Join 1011 The PIM-SM snooping mechanism for source and group specific join 1012 works as follows: 1014 Guideline 23: A PE MUST add a PW/AC to its (S,G) "Flood to" list 1015 if it receives a (S,G) join message from the PW/AC. 1017 Guideline 24: A PE MUST remove a PW/AC from its (S,G) "Flood to" 1018 list if it receives a (S,G) prune message from the PW/AC. A 1019 prune-delay timer SHOULD be implemented to support prune override. 1021 Guideline 25: A PE MUST prefer (S,G) state to (*,G), if both S and 1022 G match. 1024 Guideline 26: When a (S,G) is state is first created, the initial 1025 "Flood to" list MUST be populated by copying the "Flood to" list 1026 from its parent (*,G) state. 1028 Guideline 27: In case (*,G) state changes in a PE, all changes to 1029 (*,G) state MUST (additions and deletions in "Flood to" list) be 1030 replicated to (S,G) state. 1032 - Now, we assume Router 5 sends a source and group specific join 1033 (S,G). Let�s assume the source is behind Router 1. PE 4 sends 1034 the (S,G) join to PE 1. PE 1 forwards the (S,G) join to AC1. 1035 The states are updated as follows: PE 1: {[(*,G); Flood to: 1036 AC1], [(S,G); Flood to: AC1,PW1to4], [PIM Neighbors: (Router 1037 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1038 5,PW1to4)]}, PE 2: {[(*,G); Flood to: AC2, AC3], [PIM 1039 Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), 1040 (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(*,G); Flood 1041 to: PW1to3, PW2to3], [PIM Neighbors: (Router 1,PW1to3), (Router 1042 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: 1043 {[(S,G); Flood to: AC5],[PIM Neighbors: (Router 1,PW1to4), 1044 (Router 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 1045 5,AC5)]}. 1046 - Afterwards, we assume Router 5 sends a (S,G)RP-bit prune, also 1047 known as (S,G,RPT) prune. PE routers flood this prune message 1048 and do not take any action. 1050 5.3.2.5 PIM-SM (*,*,RP) State 1051 PIM-SM defines a (*,*,RP) state which is used when traffic needs to 1052 cross multicast domains. A (*,*,RP) receiver requests all multicast 1053 traffic within a PIM domain to be sent to it. If the two multicast 1054 domains are both PIM-SM, they can use MSDP to leak multicast routes. 1055 But, if one is PIM-SM and the other is PIM-DM (hence, MSDP can not 1056 be used), then the border router would initiate a (*,*,RP) join to 1057 all RPs in the PIM-SM domain. 1059 If the customers will configure multiple and different PIM domains, 1060 PIM-SM snooping MUST support (*,*,RP) state as well. Depending on 1061 how likely scenario this is, future versions may include (*,*,RP) 1062 states. 1064 5.3.2.6 Failure Scenarios 1065 Failures can be easily handled in PIM-SM snooping, as it employs 1066 state-refresh technique. PEs in the VPLS instance will remove any 1067 entry for non-refreshing routers from their states. 1069 5.3.2.7 Special Cases for PIM-SM Snooping 1070 There are some special cases to consider for PIM-SM snooping. First 1071 one is the RP-on-a-stick. The RP-on-a-stick scenario may occur when 1072 the Shortest Path Tree and the Shared Tree shares a common Ethernet 1073 segment, as all routers will be connected over a multicast access 1074 network (i.e., VPLS). Such a scenario will be handled by PIM-SM 1075 rules (particularly, the incoming interface can not also appear in 1076 the outgoing interface list) very nicely. Second scenario is the 1077 turnaround router. The turnaround router scenario occurs when 1078 shortest path tree and shared tree share a common path. The router 1079 at which these tree merge is the turnaround router. PIM-SM handles 1080 this case by proxy (S,G) join implementation by the turnaround 1081 router. 1083 There can be some scenarios where CE routers can receive duplicate 1084 multicast traffic. Let�s consider the scenario in Figure 3. 1086 +------+ AC3 +------+ 1087 | PE2 |-----| R3 | 1088 /| | | | 1089 / +------+ +------+ 1090 / | | 1091 / | | 1092 /PW1to2 | | 1093 / | +-----+ 1094 / |PW2to3 | Src | 1095 / | +-----+ 1096 / | | 1097 / | | 1098 / | | 1099 +------+ +------+ / +------+ +------+ 1100 | R1 | | PE1 |/ PW1to3 | PE3 | | R4 | 1101 | |-----| |-------------| |-----| | 1102 +------+ AC1 +------+ +------+ AC4 +------+ 1103 | | 1104 |AC2 |AC5 1105 +------+ +------+ 1106 | R2 | | R5 | +---+ 1107 | | | |-----|RP | 1108 +------+ +------+ +---+ 1110 Figure 3 CE Routers Receive Duplicate Traffic 1112 In the scenario depicted in Figure 3, both R1 and R2 has two ECMP 1113 routes to reach the source Src. Hence, R1 may pick R3 as its next 1114 hop ("Upstream Neighbor"), and R2 may pick R4 as its next hop. As a 1115 result, both R1 and R2 will receive duplicate traffic. 1117 This issue can be solved as follows. PEs can keep the PW/AC that 1118 the join message is forwarded to (upstream PW/AC) in "Flood to" list 1119 in addition to the PW/AC that the join message is received 1120 (downstream PWAC). If the traffic arrives from a different PW/AC, 1121 that traffic is not forwarded downstream. Hence, in the example 1122 depicted in Figure 3 where source is dual homed to R3 and R4, R1 1123 will receive (S,G) traffic if it comes from PW1to2, and R2 will 1124 receive (S,G) traffic if it comes from PW1to3. 1126 Again, in Figure 3, R1 may send (S,G) join to R3 and R2 may send 1127 (*,G) join to the RP behind R5. In this scenario as well, both R1 1128 and R2 will receive duplicate traffic, as Guideline 25 will be no 1129 help to prevent it. 1131 In this case, where R1 joins for (S,G), and R2 joins for (*,G), we 1132 can do the following. The PEs SHOULD keep the upstream PW/AC in the 1133 state as described above. In addition, the PEs need to act on 1134 (S,G,RPT) prunes and remove the related upstream PW/AC from "Flood 1135 to" list of (S,G) state copied from (*,G) state. As a result, Ces 1136 will not receive duplicate traffic. 1138 However, there will still be bandwidth waste as the egress PE takes 1139 care of the duplicate traffic problem. We can further enhance the 1140 proposal by triggering Assert mechanism in CE routers. The PE which 1141 detects the duplicate traffic problem can simply remove the snooping 1142 state for that particular multicast group, and can send out "flush" 1143 message to other PEs participating in the VPLS instance. In return, 1144 other PEs also flush their snooping state for that multicast group. 1145 As a result, all the PEs will flood the multicast traffic in the 1146 VPLS instance (by Rule 3). Consequently, CEs will do Assert. The 1147 flush message TLV can be sent over the targeted LDP sessions running 1148 among PEs. Future versions will include the details. 1150 5.3.3 PIM-SSM 1151 The key characteristics of PIM-SSM is explicit join behavior, but it 1152 eliminates the shared tree and the rendezvous point in PIM-SM. In 1153 this model, a shortest path tree for each (S,G) is built with the 1154 first hop router (that is directly connected to the multicast 1155 source) being the root node. PIM-SSM is ideal for one-to-many 1156 multicast services. 1158 In Figure 2, S1 is behind Router 1, and S4 is behind Router 4. 1159 Routers 2 and 4 want to join (S1,G), while Router 5 wants to join 1160 (S4,G). 1162 We assume that the PEs have the capability to store (S,G) states for 1163 PIM-SSM snooping and constrain multicast flooding scope accordingly. 1164 An implementation, can fall back to (*,G) states, if its hardware 1165 can not support it. In such case, the efficiency of multicast 1166 forwarding will be less. 1168 5.3.3.1 Discovering Multicast Routers 1169 The PIM-SSM snooping mechanism for neighbor discovery works the same 1170 way as t procedure defined in PIM-DM section, with the exception of 1171 PIM-DM only guidelines. 1172 - Based on PIM Hello exchanges PE routers populate PIM snooping 1173 states as follows. PE 1: {[(,); Flood to:], [PIM Neighbors: 1174 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 1175 (Router 5,PW1to4)]}, PE 2: {[(,); Flood to:], [PIM Neighbors: 1176 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 1177 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(,); Flood to:], [PIM 1178 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1179 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to:], 1180 [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1181 (Router 4,PW3to4), (Router 5,AC5)]}. 1183 5.3.3.2 Guidelines for PIM-SSM Snooping 1184 PIM-SSM snooping is actually simpler than PIM-SM and only the 1185 following guidelines (some of which are repetitions from PIM-SM 1186 section) apply. 1188 Guideline 28: A PE MUST add a PW/AC to its (S,G) "Flood to" list 1189 if it receives a (S,G) join message from the PW/AC. 1191 Guideline 29: PIM-SSM join messages MUST be sent only to the 1192 remote PE, which is connected to the router to which the Join is 1193 addressed. 1195 Guideline 30: PIM prune messages MUST be flooded in the VPLS 1196 instance. 1198 Guideline 31: If A PE does not receive a refresh join message from 1199 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 1200 "Flood to" list. 1202 Guideline 32: A PE MUST remove a PW/AC from its (S,G) "Flood to" 1203 list if it receives a (S,G) prune message from the PW/AC. A 1204 prune-delay timer SHOULD be implemented to support prune override. 1206 5.3.3.3 PIM-SSM Join 1207 The PIM-SSM snooping mechanism for joining a multicast group works 1208 as follows: 1210 - Assume Router 2 requests to join the multicast group (S1,G). 1211 - PE 2 updates its state, and then sends the join message to PE 1212 1. 1213 - All PEs update their states as follows: PE 1: {[(S1,G); Flood 1214 to: PW1to2], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 1215 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: 1216 {[(S1,G); Flood to: AC2], [PIM Neighbors: (Router 1,PW1to2), 1217 (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 1218 5,PW2to4)]}, PE 3: {[(,); Flood to: ], [PIM Neighbors: (Router 1219 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 1220 5,PW3to4)]}, PE 4: {[(,); Flood to: ], [PIM Neighbors: (Router 1221 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 1222 (Router 5,AC5)]}. 1223 - Next, assume Router 4 sends a join (S1,G) message. Following 1224 the same procedures, all PEs update their states as follows: PE 1225 1: {[(S1,G); Flood to: PW1to2, PW1to3], [PIM Neighbors: (Router 1226 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1227 5,PW1to4)]}, PE 2: {[(S1,G); Flood to: AC2], [PIM Neighbors: 1228 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 1229 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[(S1,G); Flood to: AC4], 1230 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1231 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(,); Flood to: ], 1232 [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1233 (Router 4,PW3to4), (Router 5,AC5)]}. 1234 - Then, assume Router 5 requests to join the multicast group 1235 (S4,G). After the same procedures are applied, all PEs update 1236 their states as follows: PE 1: {[(S1,G); Flood to: PW1to2, 1237 PW1to3], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 1238 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: 1239 {[(S1,G); Flood to: AC2], [PIM Neighbors: (Router 1,PW1to2), 1240 (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 1241 5,PW2to4)]}, PE 3: {[(S1,G); Flood to: AC4], [(S4,G); Flood to: 1242 PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1243 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[(S4,G); 1244 Flood to: AC5], [PIM Neighbors: (Router 1,PW1to4), (Router 1245 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1247 5.3.3.4 PIM-SSM Prune 1248 At this point, all PEs have necessary states to not send multicast 1249 traffic to sites with no members. 1251 The PIM-SSM snooping mechanism for leaving a multicast group works 1252 as follows: 1253 - Assume Router 2 sends a (S1,G) prune message to leave the 1254 multicast group. The prune message gets flooded in the VPLS 1255 instance. All PEs update their states as follows: PE 1: 1257 {[(S1,G); Flood to: PW1to3], [PIM Neighbors: (Router 1,AC1), 1258 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1259 5,PW1to4)]}, PE 2: {[(,); Flood to: ], [PIM Neighbors: (Router 1260 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1261 (Router 5,PW2to4)]}, PE 3: {[(S1,G); Flood to: AC4], [(S4,G); 1262 Flood to: PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router 1263 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: 1264 {[(S4,G); Flood to: AC5], [PIM Neighbors: (Router 1,PW1to4), 1265 (Router 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 1266 5,AC5)]}. 1268 In PIM-SSM snooping, prune messages are flooded by PE routers. In 1269 such implementation, PE routers may receive overriding join 1270 messages, which will not affect anything. 1272 5.3.3.5 Failure Scenarios 1273 Similar to PIM-SSM snooping, failures can be easily handled in PIM- 1274 SSM snooping, as it employs state-refresh technique. The PEs in the 1275 VPLS instance will remove entry for non-refreshing routers from 1276 their states. 1278 5.3.3.6 Special Cases for PIM-SSM Snooping 1279 The scenarios with duplicate traffic as depicted in Figure 3 apply 1280 to PIM-SSM snooping as well. Again, the issue can be solved by the 1281 method described in Section 5.3.2.7. 1283 5.3.4 Bidirectional-PIM (BIDIR-PIM) 1284 BIDIR-PIM is a variation of PIM-SM. The main differences between 1285 PIM-SM and Bidirectional-PIM are as follows: 1286 - There are no source-based trees, and source-specific multicast 1287 is not supported (i.e., no (S,G) states) in BIDIR-PIM. 1288 - Multicast traffic can flow up the shared tree in BIDIR-PIM. 1289 - To avoid forwarding loops, one router on each link is elected 1290 as the Designated Forwarder (DF) for each RP in BIDIR-PIM. 1292 The main advantage of BIDIR-PIM is that it scales well for many-to- 1293 many applications. However, the lack of source-based trees means 1294 that multicast traffic is forced to remain on the shared tree. 1296 In Figure 2, the RP for (*,G4) is behind Router 4, and the RP for 1297 (*,G1) is behind Router 1. Router 2 and Router 4 want to join 1298 (*,G1), whereas Router 5 wants to join (*,G4). On the VPLS 1299 instance, Router 4 is the DF for the RP of (*,G4), and Router 1 is 1300 the DF of the RP for (*,G1). 1302 5.3.4.1 Discovering Multicast Routers 1303 The PIM-SSM snooping mechanism for neighbor discovery works the same 1304 way as t procedure defined in PIM-DM section, with the exception of 1305 PIM-DM only guidelines. 1307 - Based on PIM Hello exchanges PE routers populate PIM snooping 1308 Based on PIM Hello exchanges PE routers populate PIM snooping 1309 states as follows. PE 1: {[(,); Upstream to:; Downstream to:], 1310 [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), 1311 (Router 4,PW1to3), (Router 5,PW1to4)], [(,), DF:]}, PE 2: 1312 {[(,); Upstream to:; Downstream to:], [PIM Neighbors: (Router 1313 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1314 (Router 5,PW2to4)], [(,), DF:]}, PE 3: {[(,); Upstream to:; 1315 Downstream to:], [PIM Neighbors: (Router 1,PW1to3), (Router 1316 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)], [(,), 1317 DF:]}, PE 4: {[(,); Upstream to:; Downstream to:], [PIM 1318 Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1319 (Router 4,PW3to4), (Router 5,AC5)], [(,), DF:]}. 1321 For BIDIR-PIM to work properly, all routers within the domain must 1322 know the address of the RP. There are three methods to do that: 1. 1323 Static RP configuration, 2, Auto-RP, and 3. PIMv2 Bootstrap. 1324 Guideline 17 applies here as well. 1326 During RP discovery time, PIM routers elect DF per subnet for each 1327 RP. The algorithm to elect the DF is as follows: all PIM neighbors 1328 in a subnet advertise their unicast route to elect the RP and the 1329 router with the best route is elected. 1331 Guideline 33: All PEs MUST snoop the DF elections messages and 1332 determine the DF for each [(*,G),RP)] pair. The "Upstream" list 1333 MUST be updated with PW/AC that leads to the DF. When the DF 1334 changes, the "Upstream" list MUST be updated accordingly. 1336 - Based on DF election messages, PE routers populate PIM snooping 1337 states as follows: PE 1: {[(*,G1); Upstream to: AC1; Downstream 1338 to:], [(*,G4); Upstream to: PW1to3; Downstream to:], [PIM 1339 Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 1340 4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF: 1341 PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2; Downstream to:], 1342 [(*,G4); Upstream to: PW2to3; Downstream to:], [PIM Neighbors: 1343 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 1344 4,PW2to3), (Router 5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4), 1345 DF:PW2to3]}, PE 3: {[(*,G1); Upstream to: PW1to3; Downstream 1346 to:], [(*,G4); Upstream to: AC4; Downstream to:], [PIM 1347 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1348 (Router 4,AC4), (Router 5,PW3to4)], [(*,G1), DF: PW1to3], 1349 [(*,G4), DF: AC4]}, PE 4: {[(*,G1); Upstream to: PW1to4; 1350 Downstream to:], [(*,G4); Upstream to: PW3to4; Downstream to:], 1351 [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1352 (Router 4,PW3to4), (Router 5,AC5)], [(*,G1), DF: PW1to4], 1353 [(*,G4), DF: PW3to4]}. 1355 5.3.4.2 Guidelines for BIDIR-PIM Snooping 1356 The BIDIR-PIM snooping for Join and Prune messages is similar to 1357 PIM-SM and the following guidelines (some of which are repetitions 1358 from PIM-SM section) apply. 1360 Guideline 34: A PE MUST add a PW/AC to its (*,G) "Downstream" list 1361 if it receives a (*,G) join message from the PW/AC. 1363 Guideline 35: BIDIR-PIM join messages MUST be sent only to the 1364 remote PE, which is connected to the router to which the Join is 1365 addressed. 1367 Guideline 36: BIDIR-PIM prune messages MUST be flooded in the VPLS 1368 instance. 1370 Guideline 37: If A PE does not receive a refresh join message from 1371 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 1372 "Downstream" list. 1374 Guideline 38: A PE MUST remove a PW/AC from its (*,G) "Downstream" 1375 list if it receives a (*,G) prune message from the PW/AC. A 1376 prune-delay timer SHOULD be implemented to support prune override. 1378 Guideline 39: A PE MUST replicate multicast traffic for (*,G) to 1379 the members in its (*,G) "Upstream" and "Downstream" lists. 1381 5.3.4.3 BIDIR-PIM Join 1382 The BIDIR-PIM snooping mechanism for joining a multicast group works 1383 as follows: 1384 - Assume Router 2 wants to join the multicast group (*,G1). PE 2 1385 sends the join message PE 1. All PEs update their states as 1386 follows: PE 1: {[(*,G1); Upstream to: AC1; Downstream to: 1387 PW1to2], [(*,G4); Upstream to: PW1to3; Downstream to:], [PIM 1388 Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 1389 4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF: 1390 PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2; Downstream to: 1391 AC2], [(*,G4); Upstream to: PW2to3; Downstream to:], [PIM 1392 Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), 1393 (Router 4,PW2to3), (Router 5,PW2to4)], [(*,G1), DF:PW1to2], 1394 [(*,G4), DF:PW2to3]}, PE 3: {[(*,G1); Upstream to: PW1to3; 1395 Downstream to: ], [(*,G4); Upstream to: AC4; Downstream to:], 1396 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1397 (Router 4,AC4), (Router 5,PW3to4)], [(*,G1), DF: PW1to3], 1398 [(*,G4), DF: AC4]}, PE 4: {[(*,G1); Upstream to: PW1to4; 1399 Downstream to: ], [(*,G4); Upstream to: PW3to4; Downstream 1400 to:], [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 1401 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)], [(*,G1), DF: 1402 PW1to4], [(*,G4), DF: PW3to4]}. 1403 - Next, assume Router 4 wants to join the multicast group (*,G1). 1404 All PEs update their states as follows: PE 1: {[(*,G1); 1405 Upstream to: AC1; Downstream to: PW1to2, PW1to3], [(*,G4); 1406 Upstream to: PW1to3; Downstream to:], [PIM Neighbors: (Router 1407 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1408 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF: PW1to4]}, PE 2: 1409 {[(*,G1); Upstream to: PW1to2; Downstream to: AC2], [(*,G4); 1410 Upstream to: PW2to3; Downstream to:], [PIM Neighbors: (Router 1411 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1412 (Router 5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4), DF:PW2to3]}, 1413 PE 3: {[(*,G1); Upstream to: PW1to3; Downstream to: AC4], 1414 [(*,G4); Upstream to: AC4; Downstream to:], [PIM Neighbors: 1415 (Router 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), 1416 (Router 5,PW3to4)], [(*,G1), DF: PW1to3], [(*,G4), DF: AC4]}, 1417 PE 4: {[(*,G1); Upstream to: PW1to4; Downstream to: ], [(*,G4); 1418 Upstream to: PW3to4; Downstream to:], [PIM Neighbors: (Router 1419 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 1420 (Router 5,AC5)], [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}. 1421 - Then, assume Router 5 wants to join the multicast group (*,G4). 1422 Following the same procedures, all PEs update their states as 1423 follows: PE 1: {[(*,G1); Upstream to: AC1; Downstream to: 1424 PW1to2, PW1to3], [(*,G4); Upstream to: PW1to3; Downstream to:], 1425 [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), 1426 (Router 4,PW1to3), (Router 5,PW1to4)], [(*,G1), DF: AC1], 1427 [(*,G4), DF: PW1to4]}, PE 2: {[(*,G1); Upstream to: PW1to2; 1428 Downstream to: AC2], [(*,G4); Upstream to: PW2to3; Downstream 1429 to:], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), 1430 (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)], [(*,G1), 1431 DF:PW1to2], [(*,G4), DF:PW2to3]}, PE 3: {[(*,G1); Upstream to: 1432 PW1to3; Downstream to: AC4], [(*,G4); Upstream to: AC4; 1433 Downstream to: PW3to4], [PIM Neighbors: (Router 1,PW1to3), 1434 (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)], 1435 [(*,G1), DF: PW1to3], [(*,G4), DF: AC4]}, PE 4: {[(*,G1); 1436 Upstream to: PW1to4; Downstream to: ], [(*,G4); Upstream to: 1437 PW3to4; Downstream to: AC5], [PIM Neighbors: (Router 1,PW1to4), 1438 (Router 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)], 1439 [(*,G1), DF: PW1to4], [(*,G4), DF: PW3to4]}. 1441 5.3.4.4 BIDIR-PIM Prune 1442 At this point, all PEs have necessary states to not send multicast 1443 traffic to sites with no members. 1445 One example of the BIDIR-PIM snooping mechanism for leaving a 1446 multicast group works as follows: 1447 - Assume Router 2 wants to leave the multicast group (*,G1) and 1448 sends a (*,G1) prune message. The prune message gets flooded 1449 in the VPLS instance. All PEs update their states as follows: 1450 PE 1: {[(*,G1); Upstream to: AC1; Downstream to: PW1to3], 1451 [(*,G4); Upstream to: PW1to3; Downstream to:], [PIM Neighbors: 1452 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 1453 (Router 5,PW1to4)], [(*,G1), DF: AC1], [(*,G4), DF: PW1to4]}, 1454 PE 2: {[(*,G1); Upstream to: PW1to2; Downstream to: ], [(*,G4); 1455 Upstream to: PW2to3; Downstream to:], [PIM Neighbors: (Router 1456 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1457 (Router 5,PW2to4)], [(*,G1), DF:PW1to2], [(*,G4), DF:PW2to3]}, 1458 PE 3: {[(*,G1); Upstream to: PW1to3; Downstream to: AC4], 1459 [(*,G4); Upstream to: AC4; Downstream to: PW3to4], [PIM 1460 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1461 (Router 4,AC4), (Router 5,PW3to4)], [(*,G1), DF: PW1to3], 1462 [(*,G4), DF: AC4]}, PE 4: {[(*,G1); Upstream to: PW1to4; 1463 Downstream to: ], [(*,G4); Upstream to: PW3to4; Downstream to: 1464 AC5], [PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 1465 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)], [(*,G1), DF: 1466 PW1to4], [(*,G4), DF: PW3to4]}. 1468 5.3.4.5 Failure Scenarios 1469 Once again, failures can be easily handled in BIDIR-PIM snooping, as 1470 it employs state-refresh technique. PEs in the VPLS instance will 1471 remove entry for non-refreshing routers from their states. 1473 5.3.5 Multicast Source Directly Connected to the VPLS Instance 1474 If there is a source in the CE network that connects directly into 1475 the VPLS instance, then multicast traffic from that source MUST be 1476 sent to all PIM routers on the VPLS instance. If there is already 1477 (S,G)/(*,G) snooping state that is formed on any PE, this will not 1478 happen per the current forwarding rules and guidelines. The 1479 (S,G)/(*,G) state may not send traffic towards all the routers. So, 1480 in order to determine if traffic needs to be flooded to all routers, 1481 a PE must be able to determine if the traffic came from a host on 1482 that LAN. There are three ways to address this problem: 1483 - The PE would have to do ARP snooping to determine if a source 1484 is directly connected. 1485 - Another option is to have configuration on all PEs to say there 1486 are CE sources that are directly connected to the VPLS instance 1487 and disallow snooping for the groups for which the source is 1488 going to send traffic. This way traffic from that source to 1489 those groups will always be flooded within the provider 1490 network. 1491 - A third option is to require that sources of CE multicast 1492 routers must appear behind a router. 1494 6 Security Considerations 1495 Security considerations provided in VPLS solution documents (i.e., 1496 [VPLS-LDP] and [VPLS-BGP) apply to this document as well. 1498 7 References 1499 7.1 Normative References 1501 7.2 Informative References 1502 [VPLS-LDP] Lasserre, M, et al. "Virtual Private LAN Services 1503 over MPLS", work in progress 1504 [VPLSD-BGP] Kompella, K, et al. "Virtual Private LAN Service", 1505 work in progress 1506 [L2VPN-FR] Andersson, L, et al. "L2VPN Framework", work in 1507 progress 1508 [PMP-RSVP-TE] Aggarwal, R, et al. "Extensions to RSVP-TE for 1509 Point to Multipoint TE LSPs", work in progress 1510 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 1511 RFC 1112, August 1989. 1512 [RFC2236] Fenner, W., "Internet Group Management Protocol, 1513 Version 2", RFC 2236, November 1997. 1514 [RFC3376] Cain, B., et al. "Internet Group Management 1515 Protocol, Version 3", RFC 3376, October 2002. 1516 [MAGMA-SNOOP] Christensen, M., et al. "Considerations for IGMP 1517 and MLD Snooping Switches", work in progress 1518 [PIM-DM] Deering, S., et al. "Protocol Independent Multicast 1519 Version 2 � Dense Mode Specification", draft-ietf- 1520 pim-v2-dm-03.txt, June 1999. 1521 [RFC2362] Estrin, D, et al. "Protocol Independent Multicast- 1522 Sparse Mode (PIM-SM): Protocol Specification", RFC 1523 2362, June 1998. 1524 [PIM-SSM] Holbrook, H., et al. "Source-Specific Multicast for 1525 IP", work in progress 1526 [BIDIR-PIM] Handley, M., et al. "Bi-directional Protocol 1527 Independent Multicast (BIDIR-PIM)", work in 1528 progress 1530 8 Authors' Addresses 1532 Yetik Serbest 1533 SBC Labs 1534 9505 Arboretum Blvd. 1535 Austin, TX 78759 1536 Yetik_serbest@labs.sbc.com 1538 Ray Qiu 1539 Alcatel North America 1540 701 East Middlefield Rd. 1541 Mountain View, CA 94043 1542 Ray.Qiu@alcatel.com 1544 Venu Hemige 1545 Alcatel North America 1546 701 East Middlefield Rd. 1547 Mountain View, CA 94043 1548 Venu.hemige@alcatel.com 1550 Rob Nath 1551 Riverstone Networks 1552 5200 Great America Parkway 1553 Santa Clara, CA 95054 1554 Rnath@riverstonenet.com 1556 Suresh Boddapati 1557 Alcatel North America 1558 701 East Middlefield Rd. 1559 Mountain View, CA 94043 1560 Suresh.boddapati@alcatel.com 1562 Sunil Khandekar 1563 Alcatel North America 1564 701 East Middlefield Rd. 1565 Mountain View, CA 94043 1566 Sunil.khandekar@alcatel.com 1568 Vach Kompella 1569 Alcatel North America 1570 701 East Middlefield Rd. 1571 Mountain View, CA 94043 1572 Vach.kompella@alcatel.com 1574 Marc Lasserre 1575 Riverstone Networks 1576 Marc@riverstonenet.com 1578 9 Intellectual Property Statement 1580 The IETF takes no position regarding the validity or scope of any 1581 Intellectual Property Rights or other rights that might be claimed 1582 to pertain to the implementation or use of the technology described 1583 in this document or the extent to which any license under such 1584 rights might or might not be available; nor does it represent that 1585 it has made any independent effort to identify any such rights. 1586 Information on the procedures with respect to rights in RFC 1587 documents can be found in BCP 78 and BCP 79. 1589 Copies of IPR disclosures made to the IETF Secretariat and any 1590 assurances of licenses to be made available, or the result of an 1591 attempt made to obtain a general license or permission for the use 1592 of such proprietary rights by implementers or users of this 1593 specification can be obtained from the IETF on-line IPR repository 1594 at http://www.ietf.org/ipr. 1596 The IETF invites any interested party to bring to its attention any 1597 copyrights, patents or patent applications, or other proprietary 1598 rights that may cover technology that may be required to implement 1599 this standard. Please address the information to the IETF at ietf- 1600 ipr@ietf.org. 1602 10 Full copyright statement 1604 Copyright (C) The Internet Society (2004). This document is subject 1605 to the rights, licenses and restrictions contained in BCP 78 and 1606 except as set forth therein, the authors retain all their rights. 1608 This document and the information contained herein are provided on 1609 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1610 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1611 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1612 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1613 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.