idnits 2.17.1 draft-serbest-l2vpn-vpls-mcast-02.txt: -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1793): 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 1978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1964. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 9 instances of lines with non-ascii characters in the document. 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 2 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 138, but not defined == Missing Reference: 'MLD' is mentioned on line 291, but not defined == Missing Reference: 'MLDv2' is mentioned on line 292, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 690, but not defined == Missing Reference: 'IGMPv3' is mentioned on line 690, but not defined == Missing Reference: 'MAGMA-SNOOOP' is mentioned on line 693, but not defined == Missing Reference: 'MVPN-VPLS' is mentioned on line 1747, but not defined == Unused Reference: 'VPLSD-BGP' is defined on line 1867, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 7 errors (**), 0 flaws (~~), 11 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-02.txt Venu Hemige 5 February 2005 Alcatel 6 Category: Informational Rob Nath 7 Expires: August 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 disclosed, 15 or will be disclosed, and any of which we become aware will be 16 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 other 23 groups may also distribute working documents as Internet- Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In Virtual Private LAN Service (VPLS), the PE devices provide a 39 logical interconnect such that CE devices belonging to a specific 40 VPLS instance appear to be connected by a single LAN. A VPLS 41 solution performs replication for multicast traffic at the ingress PE 42 devices. When replicated at the ingress PE, multicast traffic wastes 43 bandwidth when 1. Multicast traffic is sent to sites with no members, 44 and 2. Pseudo wires to different sites go through a shared path. 45 This document is addressing the former by IGMP and PIM snooping. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119. 53 Table of Contents 54 1 Contributing Authors..............................................3 55 2 Introduction......................................................3 56 3 Overview of VPLS..................................................4 57 4 Multicast Traffic over VPLS.......................................4 58 5 Constraining of IP Multicast in a VPLS............................5 59 5.1 IPv6 Considerations............................................6 60 5.2 General Rules for IGMP/PIM Snooping in VPLS....................7 61 5.3 IGMP Snooping for VPLS.........................................7 62 5.3.1 Discovering Multicast Routers.............................8 63 5.3.2 IGMP Snooping Protocol State..............................8 64 5.3.3 IGMP Join.................................................9 65 5.3.4 IGMP Leave...............................................13 66 5.3.5 Failure Scenarios........................................14 67 5.3.6 Scaling Considerations for IGMP Snooping.................14 68 5.3.7 Downstream Proxy Behavior................................15 69 5.3.8 Upstream Proxy Behavior..................................15 70 5.4 PIM Snooping for VPLS.........................................16 71 5.4.1 PIM Snooping State Summarization Macros..................16 72 5.4.2 PIM-DM...................................................18 73 5.4.2.1 Discovering Multicast Routers............................18 74 5.4.2.2 PIM-DM Multicast Forwarding..............................19 75 5.4.2.3 PIM-DM Pruning...........................................20 76 5.4.2.4 PIM-DM Grafting..........................................21 77 5.4.2.5 Failure Scenarios........................................22 78 5.4.3 PIM-SM...................................................22 79 5.4.3.1 Discovering Multicast Routers............................22 80 5.4.3.2 PIM-SM (*,G) Join........................................23 81 5.4.3.3 PIM-SM Pruning...........................................25 82 5.4.3.4 PIM-SM (S,G) Join........................................26 83 5.4.3.5 PIM-SM (S,G,rpt) Prunes..................................26 84 5.4.3.6 PIM-SM (*,*,RP) State....................................26 85 5.4.3.7 Failure Scenarios........................................27 86 5.4.3.8 Special Cases for PIM-SM Snooping........................27 87 5.4.4 PIM-SSM..................................................29 88 5.4.4.1 Discovering Multicast Routers............................30 89 5.4.4.2 Guidelines for PIM-SSM Snooping..........................30 90 5.4.4.3 PIM-SSM Join.............................................31 91 5.4.4.4 PIM-SSM Prune............................................32 92 5.4.4.5 Failure Scenarios........................................32 93 5.4.4.6 Special Cases for PIM-SSM Snooping.......................32 94 5.4.5 Bidirectional-PIM (BIDIR-PIM)............................32 95 5.4.5.1 Discovering Multicast Routers............................32 96 5.4.5.2 Guidelines for BIDIR-PIM Snooping........................33 97 5.4.5.3 BIDIR-PIM Join...........................................34 98 5.4.5.4 BIDIR-PIM Prune..........................................35 99 5.4.5.5 Failure Scenarios........................................35 100 5.4.6 Multicast Source Directly Connected to the VPLS Instance.35 101 5.4.7 Data Forwarding Rules....................................36 102 5.4.8 PIM Snooping at PWs Overwhelm PEs........................36 103 6 Security Considerations..........................................39 104 7 References.......................................................39 105 7.1 Normative References..........................................39 106 7.2 Informative References........................................39 107 8 Authors' Addresses...............................................39 108 9 Intellectual Property Statement..................................40 109 10 Full copyright statement......................................41 111 1 Contributing Authors 112 This document was the combined effort of several individuals. The 113 following are the authors, in alphabetical order, who contributed to 114 this document: 116 Suresh Boddapati 117 Venu Hemige 118 Sunil Khandekar 119 Vach Kompella 120 Marc Lasserre 121 Rob Nath 122 Ray Qiu 123 Yetik Serbest 125 2 Introduction 126 In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices 127 provide a logical interconnect such that Customer Edge (CE) devices 128 belonging to a specific VPLS instance appear to be connected by a 129 single LAN. Forwarding information base for particular VPLS instance 130 is populated dynamically by source MAC address learning. This is a 131 straightforward solution to support unicast traffic, with reasonable 132 flooding for unicast unknown traffic. Since a VPLS provides LAN 133 emulation for IEEE bridges as wells as for routers, the unicast and 134 multicast traffic need to follow the same path for layer-2 protocols 135 to work properly. As such, multicast traffic is treated as broadcast 136 traffic and is flooded to every site in the VPLS instance. 138 VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication 139 for multicast traffic at the ingress PE devices. When replicated at 140 the ingress PE, multicast traffic wastes bandwidth when: 1. Multicast 141 traffic is sent to sites with no members, 2. Pseudo wires to 142 different sites go through a shared path, and 3. Multicast traffic is 143 forwarded along a shortest path tree as opposed to the minimum cost 144 spanning tree. This document is addressing the first problem by IGMP 145 and PIM snooping. Using VPLS in conjunction with IGMP and/or PIM 146 snooping has the following advantages: 147 - It improves VPLS to support IP multicast efficiently (not 148 necessarily optimum, as there can still be bandwidth waste), 149 - It prevents sending multicast traffic to sites with no members, 150 - It keeps P routers in the core stateless, 151 - The Service Provider (SP) does not need to perform the tasks to 152 provide multicast service (e.g., running PIM, managing P-group 153 addresses, managing multicast tunnels) 155 - The SP does not need to maintain PIM adjacencies with the 156 customers. 158 In this document, we describe the procedures for Internet Group 159 Management Protocol (IGMP) and Protocol Independent Multicast (PIM) 160 snooping over VPLS for efficient distribution of IP multicast 161 traffic. 163 3 Overview of VPLS 164 In case of VPLS, the PE devices provide a logical interconnect such 165 that CE devices belonging to a specific VPLS appear to be connected 166 by a single LAN. End-to-end VPLS consists of a bridge module and a 167 LAN emulation module ([L2VPN-FR]). 169 In a VPLS, a customer site receives layer-2 service from the SP. The 170 PE is attached via an access connection to one or more CEs. The PE 171 performs forwarding of user data packets based on information in the 172 layer-2 header, that is, MAC destination address. The CE sees a 173 bridge. 175 The details of VPLS reference model, which we summarize here, can be 176 found in [L2VPN-FR]. In VPLS, the PE can be viewed as containing a 177 Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE 178 device attaches, possibly through an access network, to a bridge 179 module of a PE. Within the PE, the bridge module attaches, through 180 an Emulated LAN Interface to an Emulated LAN. For each VPLS, there 181 is an Emulated LAN instance. The Emulated LAN consists of VPLS 182 Forwarder module (one per PE per VPLS service instance) connected by 183 pseudo wires (PW), where the PWs may be traveling through Packet 184 Switched Network (PSN) tunnels over a routed backbone. VSI is a 185 logical entity that contains a VPLS forwarder module and part of the 186 bridge module relevant to the VPLS service instance [L2VPN-FR]. 187 Hence, the VSI terminates PWs for interconnection with other VSIs and 188 also terminates attachment circuits (ACs) for accommodating CEs. A 189 VSI includes the forwarding information base for a L2VPN [L2VPN-FR] 190 which is the set of information regarding how to forward layer-2 191 frames received over the AC from the CE to VSIs in other PEs 192 supporting the same L2VPN service (and/or to other ACs), and contains 193 information regarding how to forward layer-2 frames received from PWs 194 to ACs. Forwarding information bases can be populated dynamically 195 (such as by source MAC address learning) or statically (e.g., by 196 configuration). Each PE device is responsible for proper forwarding 197 of the customer traffic to the appropriate destination(s) based on 198 the forwarding information base of the corresponding VSI. 200 4 Multicast Traffic over VPLS 201 In VPLS, if a PE receives a frame from an Attachment Circuit (AC) 202 with no matching entry in the forwarding information base for that 203 particular VPLS instance, it floods the frame to all other PEs (which 204 are part of this VPLS instance) and to directly connected ACs (other 205 than the one that the frame is received from). The flooding of a 206 frame occurs when: 207 - The destination MAC address has not been learned, 208 - The destination MAC address is a broadcast address, 209 - The destination MAC address is a multicast address. 211 Malicious attacks (e.g., receiving unknown frames constantly) aside, 212 the first situation is handled by VPLS solutions as long as 213 destination MAC address can be learned. After that point on, the 214 frames will not be flooded. A PE is REQUIRED to have safeguards, 215 such as unknown unicast limiting and MAC table limiting, against 216 malicious unknown unicast attacks. 218 There is no way around flooding broadcast frames. To prevent runaway 219 broadcast traffic from adversely affecting the VPLS service and the 220 SP network, a PE is REQUIRED to have tools to rate limit the 221 broadcast traffic as well. 223 Similar to broadcast frames, multicast frames are flooded as well, as 224 a PE can not know where multicast members reside. Rate limiting 225 multicast traffic, while possible, should be done carefully since 226 several network control protocols relies on multicast. For one 227 thing, layer-2 and layer-3 protocols utilize multicast for their 228 operation. For instance, Bridge Protocol Data Units (BPDUs) use an 229 IEEE assigned all bridges multicast MAC address, and OSPF is 230 multicast to all OSPF routers multicast MAC address. If the rate- 231 limiting of multicast traffic is not done properly, the customer 232 network will experience instability and poor performance. For the 233 other, it is not straightforward to determine the right rate limiting 234 parameters for multicast. 236 A VPLS solution MUST NOT affect the operation of customer layer-2 237 protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT 238 affect the operation of layer-3 protocols. 240 In the following section, we describe procedures to constrain the 241 flooding of IP multicast traffic in a VPLS. 243 5 Constraining of IP Multicast in a VPLS 244 The objective of improving the efficiency of VPLS for multicast 245 traffic that we are trying to optimize here has the following 246 constraints: 247 - The service is VPLS, i.e., a layer-2 VPN, 248 - In VPLS, ingress replication is required, 249 - There is no layer-3 adjacency (e.g., PIM) between a CE and a 250 PE. 252 Under these circumstances, the most obvious approach is 253 implementation of IGMP and PIM snooping in VPLS. Other multicast 254 routing protocols such as DVMRP and MOSPF are outside the scope of 255 this document. 257 Another approach to constrain multicast traffic in a VPLS is to 258 utilize point-multipoint LSPs (e.g., [PMP-RSVP-TE]). In such case, 259 one has to establish a point-multipoint LSP from a source PE (i.e., 260 the PE to which the source router is connected to) to all other PEs 261 participating in the VPLS instance. In this case, if nothing is 262 done, all PEs will receive multicast traffic even if they don�t have 263 any members hanging off of them. One can apply IGMP/PIM snooping, 264 but this time IGMP/PIM snooping should be done in P routers as well. 265 One can propose a dynamic way of establishing point-multipoint LSPs, 266 for instance by mapping IGMP/PIM messages to RSVP-TE signaling. One 267 should consider the effect of such approach on the signaling load and 268 on the delay between the time the join request received and the 269 traffic is received (this is important for IPTV application for 270 instance). This approach is outside the scope of this document. 272 Although, in some extremely controlled cases, such as a ring topology 273 of PE routers with no P routers or a tree topology, the efficiency of 274 the replication of IP multicast can be improved. For instance, spoke 275 PWs of a hierarchical VPLS can be daisy-chained together and some 276 replication rules can be devised. These cases will not be considered 277 in this document. 279 In the following sections, we provide some guidelines for the 280 implementation of IGMP and PIM snooping in VPLS. 282 5.1 IPv6 Considerations 283 In VPLS, PEs forward Ethernet frames received from CEs and as such 284 are agnostic of the layer-3 protocol used by the CEs. However, as an 285 IGMP and PIM snooping switch, the PE would have to look deeper into 286 the IP and IGMP/PIM packets and build snooping state based on that. 287 As already stated, the scope of this document is limited to snooping 288 IGMP/PIM packets. So, we are concerned with snooping specific IP 289 payloads. Nonetheless, there are two IP versions a PE would have to 290 be able to interpret. IGMP is the Group Management Protocol which 291 applies only to IPv4. MLD [MLD] is the equivalent of IGMPv2 defined 292 for IPv6. MLDv2 [MLDv2] is the equivalent of IGMPv3 defined for 293 IPv6. PIM runs on top of both IPv4 and IPv6. 295 This document mandates that a PE MUST be able to snoop IGMP and PIM 296 encapsulated as IPv4 payloads. The PE SHOULD also be capable of 297 snooping MLD/MLDv2 packets and PIM packets encapsulated as IPv6 298 payloads. If the PE cannot snoop IPv6 payloads, then it MUST NOT 299 build any snooping state for such multicast groups and MUST simply 300 flood any data traffic sent to such groups. This allows an IPv6- 301 unaware PE to perform the snooping function only on IPv4 multicast 302 groups. This is possible because an IPv4 multicast address and an 303 IPv6 multicast address never share the same MAC address. 305 To avoid confusion, this document describes the procedures for 306 IGMP/PIM snooping for IPv4. The procedures described for IGMP can 307 also be applied to MLD and MLDv2. Please refer to Section 3 of 309 [MAGMA-SNOOP] for a list of IPv4/IPv6 differences an IGMP/MLD 310 snooping switch has to be aware of. In addition to those 311 differences, some of the other differences of interest are: 312 - IPv4 multicast addresses map to multicast MAC addresses 313 starting with 01:00:5E and IPv6 multicast addresses map to 314 multicast MAC addresses starting with 33:33. So the MAC 315 addresses used for IPv4 and IPv6 never overlap. 317 5.2 General Rules for IGMP/PIM Snooping in VPLS 318 The following rules for the correct operation of IGMP/PIM snooping 319 MUST be followed. 321 Rule 1: IGMP and PIM messages forwarded by PEs MUST follow the split- 322 horizon rule for mesh PWs as defined in [VPLS-LDP]. 324 Rule 2: IGMP/PIM snooping states in a PE MUST be per VPLS instance. 326 Rule 3: If a PE does not have any entry in a IGMP/PIM snooping state 327 for multicast group (*,G) or (S,G), the multicast traffic to that 328 group in the VPLS instance MUST be flooded. 330 Rule 4: A PE MUST support PIM mode selection per VPLS instance via 331 CLI and/or EMS. Another option could be to deduce the PIM mode from 332 RP address for a specific multicast group. For instance, a RP address 333 can be learned during the Designated Forwarder (DF) election stage 334 for Bidirectional-PIM. 336 5.3 IGMP Snooping for VPLS 337 IGMP is a mechanism to inform the routers on a subnet of a host�s 338 request to become a member of a particular multicast group. IGMP is 339 a stateful protocol. The router (i.e., the Querier) regularly 340 verifies that the hosts want to continue to participate in the 341 multicast groups by sending periodic queries, transmitted to all 342 hosts multicast group (IP:224.0.0.1, MAC:01-00-5E-00-00-01) on the 343 subnet. If the hosts are still interested in that particular 344 multicast group, they respond with membership report message, 345 transmitted to the multicast group of which they are members. In 346 IGMPv1 [RFC1112], the hosts simply stop responding to IGMP queries 347 with membership reports, when they want to leave a multicast group. 348 IGMPv2 [RFC2236] adds a leave message that a host will use when it 349 needs to leave a particular multicast group. IGMPv3 [RFC3376] 350 extends the report/leave mechanism beyond multicast group to permit 351 joins and leaves to be issued for specific source/group (S,G) pairs. 353 In IGMP snooping, a PE snoops on the IGMP protocol exchange between 354 hosts and routers, and based on that restricts the flooding of IP 355 multicast traffic. In the following, we explore the mechanisms 356 involved in implementing IGMP snooping for VPLS. Please refer to 357 Figure 1 as an example of VPLS with IGMP snooping. In the figure, 358 Router 1 is the Querier. If multiple routers exist on a single 359 subnet (basically that is what a VPLS instance is), they can mutually 360 elect a designated router (DR) that will manage all of the IGMP 361 messages for that subnet. 363 VPLS Instance 364 +------+ AC1 +------+ +------+ AC4 +------+ 365 | Host |-----| PE |-------------| PE |-----|Router| 366 | 1 | | 1 |\ PW1to3 /| 3 | | 1 | 367 +------+ +------+ \ / +------+ +------+ 368 | \ / | 369 | \ / | 370 | \ /PW2to3 | 371 | \ / | 372 PW1to2| \ |PW3to4 373 | / \ | 374 | / \PW1to4 | 375 | / \ | 376 | / \ | 377 +------+ +------+ / \ +------+ +------+ 378 | Host | | PE |/ PW2to4 \| PE | |Router| 379 | 2 |-----| 2 |-------------| 4 |-----| 2 | 380 +------+ AC2 +------+ +------+ AC5 +------+ 381 | 382 |AC3 383 +------+ 384 | Host | 385 | 3 | 386 +------+ 388 Figure 1 Reference Diagram for IGMP Snooping for VPLS 390 5.3.1 Discovering Multicast Routers 391 A PE need to discover the multicast routers in VPLS instances. This 392 is necessary because: 393 - Designated Router can be different from the Querier on a LAN. 394 - It is not always the Querier that initiates PIM joins 395 - Multicast traffic to the LAN could arrive from a non-querying 396 router because it could be the closest to the source. 398 As recommended in [MAGMA-SNOOP], the PEs can discover multicast 399 routers using Multicast Router Discovery Protocol or they can be 400 statically configured. Since multicast routing protocols other than 401 PIM is out scope, multicast routers can also be discovered by 402 snooping PIM Hello packets as described in Section 5.4.2.1. 404 5.3.2 IGMP Snooping Protocol State 405 The IGMP snooping mechanism described here builds the following state 406 on the PEs. 408 For each VPLS Instance 409 - Set of Multicast Routers (McastRouters) in the VPLS instance 410 using mechanisms listed in Section 5.2.1. 411 - The IGMP Querying Router (Querier) in the VPLS instance. 413 For each Group entry (*,G) or Source Filtering entry (S,G) in a VPLS 414 instance 415 - Set of interfaces (ACs and/or PWs) from which IGMP membership 416 reports were received. For (*,G) entries, we will call this set 417 igmp_include(*,G). For (S,G) entries, we will call this set 418 igmp_include(S,G). 419 - Set of interfaces from which IGMPv3 hosts have requested to not 420 receive traffic from the specified sources. We will call this 421 set igmp_exclude(S,G). 423 On each interface I, for each (*,G) or (S,G) entry 424 - A Group Timer (GroupTimer(*,G,I)) representing the hold-time 425 for each downstream (*,G) report received on interface I. 426 - A Source Timer (SrcTimer(S,G,I)) representing the hold-time for 427 each downstream (S,G) report received on interface I. 429 5.3.3 IGMP Join 430 The IGMP snooping mechanism for joining a multicast group (for all 431 IGMP versions) works as follows: 432 - The PE does querier election (by tracking query messages and 433 the source IP addresses) to determine the Querier when there 434 are multiple routers present. Additionally, the query must be 435 received with a non-zero source-ip-address to perform the 436 Querier election 437 - At this point all PEs learn the place of the Querier. For 438 instance, for PE 1 it is behind PW1to3, for PE 2 behind PW2to3, 439 for PE 3 behind AC4, for PE 4 behind PW3to4. 440 - The Querier sends a membership query on the LAN. The 441 membership query can be either general query or group specific 442 query. 443 - PE 3 replicates the query message and forwards it to all PEs 444 participating in the VPLS instance (i.e., PE 1, PE 2, PE 4). 445 - PE 3 keeps a state of {[McastRouters: AC4, PW3to4], [Querier: 446 AC4]}. 447 - All PEs then forward the query to ACs which are part of the 448 VPLS instance. 449 - Suppose that all hosts (Host 1, Host 2, and Host 3) want to 450 participate in the multicast group. 451 - Host 2 first (for the sake of the example) sends a membership 452 report to the multicast group (e.g., IP: 239.1.1.1, MAC: 01-00- 453 5E-01-01-01), of which Host 2 wants to be a member. 455 - PE 2 replicates the membership report message and forwards it 456 to all PEs participating in the VPLS instance (i.e., PE 1, PE 457 3, PE 4). 458 - PE 2 notes that there is a directly connected host, which is 459 willing to participate in the multicast group and updates its 460 state to {[McastRouters: PW2to3, PW2to4], [Querier: PW2to3], 461 [igmp_include(*,G):AC2; GroupTimer(*,G,AC2)=GMI]}. 463 Guideline 1: A PE MUST forward a membership report message to ACs 464 that are part of "McastRouters" state. This is necessary to avoid 465 report suppression for other members in order for the PEs to 466 construct correct states and to not have any orphan receiver 467 hosts. 469 There are still some scenarios that can result in orphan receivers. 470 For instance, a multicast router and some hosts could be connected to 471 a customer layer-2 switch, and that layer-2 switch can be connected 472 to a PE via an AC. In such scenario, the customer layer-2 switch 473 MUST perform IGMP snooping as well, and it MUST NOT forward the IGMP 474 report messages coming from the PE to the hosts directly connected to 475 it. There can be some cases such that the layer-2 switch does not 476 have IGMP snooping capability or that device is a dummy hub/bridge. 477 In such cases, one can statically configure the AC, through which the 478 IGMP incapable layer-2 device is connected, to be a (S,G)/(*,G) 479 member on the PE. This way, multicast traffic will always be sent to 480 the hosts connected to that layer-2 device, even they don�t send 481 joins because of join suppression. 483 Continuing with the example: 485 - PE 2 does not forward the membership report of Host 2 to Host 486 3. 487 - Per the guideline above, PE 1 does not forward the membership 488 report of Host 2 to Host 1. 489 - Per the guideline above, PE 3 does forward the membership 490 report of Host 2 to Router 1 (the Querier). 491 - PE 3 notes that there is a host in the VPLS instance, which is 492 willing to participate in the multicast group and updates its 493 state to {[McastRouters: AC4, PW3to4], [Querier: AC4], 494 [igmp_include(*,G): PW2to3; GroupTimer(*,G,PW2to3)=GMI]} 495 regardless of the type of the query. 496 - Let�s assume that Host 1 subsequently sends a membership report 497 to the same multicast group. 498 - PE 1 replicates the membership report message and forwards it 499 to all PEs participating in the VPLS instance (i.e., PE 2, PE 500 3, PE 4). 502 - PE 1 notes that there is a directly connected host, which is 503 willing to participate in the multicast group. Basically, it 504 keeps a state of {[McastRouters: PW1to3, PW1to4], [Querier: 505 PW1to3], [igmp_include(*,G): AC1,PW1to2; 506 GroupTimer(*,G,AC1)=GMI]}. 507 - Per Guideline 1, PE 2 does not forward the membership report of 508 Host 1 to Host 2 and Host 3. 509 - PE 3 and PE 4 receive the membership report message of Host 1 510 and check their states. Per Guideline 1, they send the report 511 to Router 1 and Router 2 respectively. They also update their 512 states to reflect Host 1. 513 - Now, Host 3 sends a membership report to the same multicast 514 group. 515 - PE 2 updates its state to {[McastRouters: PW2to3, PW2to4], 516 [Querier: PW2to3], [igmp_include(*,G): AC2,AC3,PW1to2; 517 GroupTimer(*,G,AC3)=GMI]}. It then floods the report message to 518 all PEs participating in the VPLS instance. Per Guideline 1, 519 PE 3 forwards the membership report of Host 3 to Router 1, and 520 PE 4 forwards the membership report of Host 3 to Router 2. 522 At this point, all PEs have necessary states to ensure that no 523 multicast traffic will be sent to sites with no members. 525 The previous steps work the same way for IGMPv1 and IGMPv2, when the 526 query is general or source specific. 528 The group and source specific query for IGMPv3 is considered 529 separately below. In IGMPv3, there is no simple membership join or 530 leave report. IGMPv3 reports are one of IS_INCLUDE, IS_EXCLUDE, 531 ALLOW, BLOCK, TO_INCLUDE, TO_EXCLUDE. The PEs MUST implement the 532 "router behavior" portion of the state machine defined in Section 6 533 of [RFC3376]. 535 The IGMP snooping mechanism for joining a multicast group (for 536 IGMPv3) works as follows: 537 - The Querier sends a membership query to the LAN. The 538 membership query is group and source specific query with a list 539 of sources (e.g., S1, S2, .., Sn). 540 - PE 3 replicates the query message and forwards it to all PEs 541 participating in the VPLS instance (i.e., PE 1, PE 2, PE 4). 542 - PE 3 keeps a state of {[McastRouters: AC4, PW3to4], [Querier: 543 AC4]}. 544 - All PEs then forward the query to ACs which are part of the 545 VPLS instance. 546 - Suppose that all hosts (Host 1, Host 2, and Host 3) want to 547 participate in the multicast group. Host 1 and Host 2 want to 548 subscribe to (Sn,G), and Host 3 wants to subscribe to (S3,G). 550 - Host 2 first (for the sake of the example) sends a membership 551 report message with group record type IS_INCLUDE for (Sn,G). 552 - PE 2 replicates the membership report message and forwards it 553 to all PEs participating in the VPLS instance (i.e., PE 1, PE 554 3, PE 4). 555 - PE 2 notes that there is a directly connected host, which is 556 willing to participate in the multicast group and updates its 557 state to {[McastRouters: PW2to3, PW2to4], [Querier: PW2to3], 558 [igmp_include(Sn,G): AC2; SrcTimer(Sn,G,AC2)=GMI]}. 559 - Per Guideline 1, PE 2 does not forward the membership report of 560 Host 2 to Host 3. 561 - Per Guideline 1, PE 1 does not forward the membership report of 562 Host 2 to Host 1. 563 - Per Guideline 1, PE 3 does forward the membership report of 564 Host 2 to Router 1 (the Querier). 565 - Per Guideline 1, PE 4 does forward the membership report of 566 Host 2 to Router 2. 567 - PE 3 notes that there is a host in the VPLS instance, which is 568 willing to participate in the multicast group. Basically, it 569 updates its state to {[McastRouters: AC4, PW3to4], [Querier: 570 AC4], [igmp_include(Sn,G): PW2to3; SrcTimer(Sn,G,PW2to3)=GMI]}. 571 - Likewise, PE 4 updates its state to {[McastRouters: PW3to4, 572 AC5], [Querier: PW3to4], [igmp_include(Sn,G):PW2to4; 573 SrcTimer(Sn,G,PW2to4)=GMI]}. 574 - Let�s say Host 1 now sends a membership report message with 575 group record type IS_INCLUDE for (Sn,G). 576 - Similar procedures are followed by PEs as explained in the 577 previous steps. For instance, PE 1 updates its state to 578 {[McastRouters: PW1to3, PW1to4], [Querier: PW1to3], 579 [igmp_include(Sn,G): PW1to2, AC1; SrcTimer(Sn,G,AC1)=GMI}. PE 580 3 updates its state to {[McastRouters: AC4, PW3to4], [Querier: 581 AC4] [igmp_include(Sn,G): PW2to3, PW1to3; 582 SrcTimer(Sn,G,PW1to3)=GMI]}. 583 - Finally, Host 3 sends a membership report message with group 584 record type IS_INCLUDE for (S3,G). 585 - PE 2 replicates the membership report message and forwards it 586 to all PEs participating in the VPLS instance (i.e., PE 1, PE 587 3, PE 4). 588 - Per Guideline 1, PE 2 does not forward the membership report of 589 Host 3 to Host 2. 590 - Per Guideline 1, PE 1 does not forward the membership report of 591 Host 3 to Host 1. 592 - Per Guideline 1, PE 3 does forward the membership report of 593 Host 3 to Router 1. 595 - Per Guideline 1, PE 4 does forward the membership report of 596 Host 3 to Router 2. 597 - All PEs update their states accordingly. For instance, PE 2 598 updates its state to {[McastRouters: PW2to3, PW2to4], [Querier: 599 PW2to3], [igmp_include(S3,G): AC3; SrcTimer(S3,G,AC3)=GMI]], 600 [igmp_include(Sn,G): PW1to2, AC2], [SrcTimer(Sn,G,AC2)=GMI]}. 601 PE 4 updates its state to {[McastRouters: AC5, PW3to4], 602 [Querier: PW3to4], [igmp_include(S3,G): PW2to4; 603 SrcTimer(S3,G,PW2to4)=GMI], [igmp_include(Sn,G): PW1to4, 604 PW2to4; SrcTimer(Sn,G,PW2to4)=GMI]}. 606 At this point, all PEs have necessary states to not send multicast 607 traffic to sites with no members. 609 Based on above description of IGMPv3 based snooping for VPLS, one may 610 conclude that the PEs MUST have the capability to store (S,G) state 611 and MUST forward/replicate traffic accordingly. This is, however, 612 not MANDATORY. A PE MAY only keep (*,G) based states rather than on 613 a per (S,G) basis with the understanding that this will result in a 614 less efficient IP multicast forwarding within each VPLS instance. 616 Guideline 2: If a PE receives unsolicited report message and if it 617 does not possess a state for that particular multicast group, it MUST 618 flood that unsolicited membership report message to all PEs 619 participating in the VPLS instance, as well as to the multicast 620 router if it is locally attached. 622 5.3.4 IGMP Leave 623 The IGMP snooping mechanism for leaving a multicast group works as 624 follows: 625 - In the case of IGMPv2, when a PE receives a leave (*,G) message 626 from a host via its AC, it lowers the corresponding 627 GroupTimer(*,G,AC) to "Last Member Query Time" (LMQT). 628 - In the case of IGMPv3, when a PE receives a membership report 629 message with group record type of IS_EXCLUDE or TO_EXCLUDE or 630 BLOCK for (S,G) from a host via its AC, it lowers the 631 corresponding SrcTimer(S,G,AC) for all affected (S,G)s to LMQT. 633 In the following guideline, a "leave (*,G)/(S,G) message" also means 634 IGMPv3 membership report message with group record type of IS_EXCLUDE 635 or TO_EXCLUDE or BLOCK for (S,G). 637 Guideline 3: A PE MUST NOT forward a leave (*,G)/(S,G) message to 638 ACs participating in the VPLS instance, If the PE still has 639 locally connected hosts or hosts connected over a H-VPLS spoke in 640 its state. 642 Guideline 4: A PE MUST forward a leave (*,G)/(S,G) message to all 643 PEs participating in the VPLS instance. A PE MAY forward the 644 leave (*,G)/(S,G) message to the "McastRouters" ONLY, if there are 645 no member hosts in its state. 647 Guideline 5: If a PE does not receive a (*,G) membership report 648 from an AC before GroupTimer(*,G,AC) expires, the PE MUST remove 649 the AC from its state. In case of IGMPv3, if a PE does not 650 receive a (S,G) membership report from an AC before the 651 SrcTimer(S,G,AC) expires, the PE MUST remove the AC from its 652 state. 654 5.3.5 Failure Scenarios 655 Up to now, we did not consider any failures, which we will focus in 656 this section. 657 - In case the Querier fails (e.g., AC to the Querier fails), 658 another router in the VPLS instance will be selected as the 659 Querier. The new Querier will be sending queries. In such 660 circumstances, the IGMP snooping states in the PEs will be 661 updated/overwritten by the same procedure explained above. 662 - In case a Multicast router fails, the IGMP snooping states in 663 the PEs will be updated/overwritten by the multicast router 664 discovery procedures provided in Section 5.3.1. 665 - In case a host fails (e.g., AC to the host fails), a PE removes 666 the host from its IGMP snooping state for that particular 667 multicast group. Guidelines 3, 4 and 5 still apply here. 668 - In case a PW (which is in IGMP snooping state) fails, the PEs 669 will remove the PW from their IGMP snooping state. For 670 instance, if PW1to3 fails, then PE 1 will remove PW1to3 from 671 its state as the Querier connection, and PE 3 will remove 672 PW1to3 from its state as one of the host connections. 673 Guidelines 3, 4 and 5 still apply here. After PW is restored, 674 the IGMP snooping states in the PEs will be updated/overwritten 675 by the same procedure explained above. One can implement a 676 dead timer before making any changes to IGMP snooping states 677 upon PW failure. In that case, IGMP snooping states will be 678 altered if the PW can not be restored before the dead timer 679 expires. 681 5.3.6 Scaling Considerations for IGMP Snooping 682 In scenarios where there are multiple ACs connected to a PE, it is 683 quite likely that IGMP membership reports for the same group are 684 received from multiple ACs. The normal behavior would be to have 685 each of the membership reports sent to McastRouters. But in 686 scenarios where many ACs send IGMP membership reports to the same 687 groups, the burden on all the other PEs can be overwhelming. To make 688 matters worse, there can be a large number of hosts on the same AC 689 that all request IGMP membership reports to the same group. While 690 [IGMPv2] suggests the use of report suppression, [IGMPv3] does not. 691 Regardless, if hosts do not implement report suppression, this can be 692 a scaling issue on the PEs. This section outlines the optimization 693 suggested in [MAGMA-SNOOOP] to perform proxy-querying and proxy- 694 reporting function on the PEs to avoid report explosion. 696 For this optimization, we separate out the IGMP group state on the 697 PEs into downstream state and upstream state. 699 Note that the following sub-sections describe the procedures for 700 (*,G). The same procedures must be extended to (S,G)s. Furthermore, 701 the behavior described is for a downstream PE. While it is very 702 important for downstream PEs to implement the proxy behavior 703 described here, the scalability issues are not as bad on upstream 704 PEs. Optimizing upstream PEs would be designed to alleviate the 705 burden on the upstream CEs. Nevertheless, the same procedures can be 706 applied to upstream PEs as well, as an added optimization. The only 707 difference would be that ACs would be upstream interface(s) and PWs 708 would be downstream interface(s) for such PEs. 710 5.3.7 Downstream Proxy Behavior 711 When an IGMP membership Report for a group is received on an AC, the 712 PE adds the AC to the corresponding igmp_include set and resets the 713 GrpTimer to GMI. 715 When an IGMP membership Leave for a group is received on an AC, the 716 PE lowers the corresponding GrpTimer to LMQT and sends out a proxy 717 group-specific query on that AC. When sending the group-specific 718 query, the PE encodes 0.0.0.0 (or:: in case of IPv6) in the source-ip 719 address field. If there is no other host interested in that group, 720 then the AC is removed from the corresponding igmp_include set after 721 the GrpTimer expires. 723 There may be some cases where the Querier and hosts are connected via 724 a layer-2 device behind an AC. To take care of those special 725 circumstances, the PE MUST NOT send out the proxy group-specific 726 query on the interface on which the Querier exists. 728 5.3.8 Upstream Proxy Behavior 729 When the igmp_include set for a group becomes non-null, the PE sends 730 out a proxy IGMP Join report for that group to McastRouters. When 731 the igmp_include set for a group becomes empty, the PE sends out a 732 proxy IGMP Leave report for that group to McastRouters. 734 When the PE receives a general query, it replies with its current 735 snooping state for all groups and group-sources. It also forwards 736 the general query to all ACs thus removing the need for proxy general 737 queries. When the PE receives a group-specific or group-source 738 specific query, the PE does not forward such queries to the ACs. 739 Instead, it replies with a proxy report if it has snooping state for 740 that group or group-source. When sending the proxy report, the PE 741 encodes 0.0.0.0 (or :: in the case of IPv6) in the source-ip address 742 field. 744 5.4 PIM Snooping for VPLS 745 IGMP snooping procedures described above provide efficient delivery 746 of IP multicast traffic in a given VPLS service when end stations are 747 connected to the VPLS. However, when VPLS is offered as a WAN 748 service it is likely that the CE devices are routers and would run 749 PIM between them. To provide efficient IP multicasting in such 750 cases, it is necessary that the PE routers offering the VPLS service 751 do PIM snooping. This section describes the procedures for PIM 752 snooping. 754 PIM is a multicast routing protocol, which runs exclusively between 755 routers. PIM shares many of the common characteristics of a routing 756 protocol, such as discovery messages (e.g., neighbor discovery using 757 Hello messages), topology information (e.g., multicast tree), and 758 error detection and notification (e.g., dead timer and designated 759 router election). On the other hand, PIM does not participate in any 760 kind of exchange of databases, as it uses the unicast routing table 761 to provide reverse path information for building multicast trees. 762 There are a few variants of PIM. In PIM-DM ([PIM-DM]), multicast 763 data is pushed towards the members similar to broadcast mechanism. 764 PIM-DM constructs a separate delivery tree for each multicast group. 765 As opposed to PIM-DM, other PIM versions (PIM-SM [RFC2362], PIM-SSM 766 [PIM-SSM], and BIDIR-PIM [BIDIR-PIM]) invokes a pull methodology 767 instead of push technique. 769 PIM routers periodically exchange Hello messages to discover and 770 maintain stateful sessions with neighbors. After neighbors are 771 discovered, PIM routers can signal their intentions to join/prune 772 specific multicast groups. This is accomplished by having downstream 773 routers send an explicit join message (for the sake of 774 generalization, consider Graft messages for PIM-DM as join messages) 775 to the upstream routers. The join/prune message can be group 776 specific (*,G) or group and source specific (S,G). 778 In PIM snooping, a PE snoops on the PIM message exchange between 779 routers, and builds its multicast states. Based on the multicast 780 states, it forwards IP multicast traffic accordingly to avoid 781 unnecessary flooding. 783 5.4.1 PIM Snooping State Summarization Macros 784 The following sets are defined to help build the forwarding state on 785 a PE. Some sets may apply only to a subset of the PIM Protocol 786 variants as noted along with the definition of the sets. 788 pim_joins(*,G) = 789 Set of all downstream interfaces on which PIM (*,G) Joins are 790 received. This set applies only to PIM-SM, PIM-SSM, PIM-BIDIR. 792 pim_joins(S,G) = 793 Set of all downstream interfaces on which PIM (S,G) Joins are 794 received. This set applies only to PIM-SM, PIM-SSM. 796 all_pim_DM_oiflist = 797 If the upstream interface (the interface towards the upstream PIM 798 neighbor) is a PW, then this set is the set of all ACs on which there 799 are PIM neighbors. If the upstream interface is an AC, then this is 800 the set of all interfaces (both AC and PW) on which there are PIM 801 neighbors. This set applies only to PIM-DM. 803 pim_prunes(S,G) = 804 Set of all downstream interfaces on which PIM (S,G) prunes are 805 received. This set applies only to PIM-DM. 807 pim_prunes(S,G,rpt) = 808 Set of all downstream interfaces on which PIM (S,G,rpt) prunes are 809 received. This set applies only to PIM-SM. 811 pim_oiflist(*,G) = 812 Set of interfaces that PIM contributes to the list of outgoing 813 interfaces to which data traffic must be forwarded on a (*,G) match. 815 pim_oiflist(S,G) = 816 Set of interfaces that PIM contributes to the list of outgoing 817 interfaces to which data traffic must be forwarded on an (S,G) match. 819 Note that pim_oiflist is not the complete list of outgoing interfaces 820 (oiflist). IGMP/MLD also contribute to this list. 822 For PIM-DM, 824 pim_oiflist(S,G) = all_pim_DM_oiflist (-) pim_prunes(S,G) 826 For PIM-SM and PIM-SSM, 828 pim_inherited_oiflist(S,G,rpt) = pim_joins(*,G) (-) 829 pim_prunes(S,G,rpt) 831 pim_oiflist(*,G) = pim_joins(*,G) 833 pim_oiflist(S,G) = pim_inherited_oiflist(S,G,rpt) (+) 834 pim_joins(S,G) 836 For PIM-BIDIR, 838 pim_oiflist(*,G) = DF(RP(G)) + pim_joins(*,G) 839 Where DF(RP(G)) is the AC/PW towards the router that is the 840 designated forwarder for RP(G). 842 In the following, the mechanisms involved for implementing PIMv2 843 ([RFC2362]) snooping in VPLS are specified. PIMv1 is out of the 844 scope of this document. Please refer to Figure 2 as an example of 845 VPLS with PIM snooping. 847 VPLS Instance 848 +------+ AC1 +------+ +------+ AC4 +------+ 849 |Router|-----| PE |-------------| PE |-----|Router| 850 | 1 | | 1 |\ PW1to3 /| 3 | | 4 | 851 +------+ +------+ \ / +------+ +------+ 852 | \ / | 853 | \ / | 854 | \ /PW2to3 | 855 | \ / | 856 PW1to2| \ |PW3to4 857 | / \ | 858 | / \PW1to4 | 859 | / \ | 860 | / \ | 861 +------+ +------+ / \ +------+ +------+ 862 |Router| | PE |/ PW2to4 \| PE | |Router| 863 | 2 |-----| 2 |-------------| 4 |-----| 5 | 864 +------+ AC2 +------+ +------+ AC5 +------+ 865 | 866 |AC3 867 +------+ 868 |Router| 869 | 3 | 870 +------+ 872 Figure 2 Reference Diagram for PIM Snooping for VPLS 874 In the following sub-sections, snooping mechanisms for each variety 875 of PIM are specified. 877 5.4.2 PIM-DM 878 The characteristics of PIM-DM is flood and prune behavior. Shortest 879 path trees are built as a multicast source starts transmitting. 881 In Figure 2, the multicast source is behind Router 4, and all routers 882 have at least one receiver except Router 3 and Router 5. 884 5.4.2.1 Discovering Multicast Routers 885 The PIM-DM snooping mechanism for neighbor discovery works as 886 follows: 887 - To establish PIM neighbor adjacencies, PIM multicast routers 888 (all routers in this example) send PIM Hello messages to the 889 ALL PIM Routers group address (IPv4: 224.0.0.13, MAC: 01-00-5E- 890 00-00-0D) on every PIM enabled interfaces. The IPv6 ALL PIM 891 Routers group is "ff02::d". In addition, PIM Hello messages 892 are used to elect Designated Router for a multi-access network. 894 In PIM-DM, the DR acts as the Querier if IGMPv1 is used. 895 Otherwise, DR has no function in PIM-DM. 897 Guideline 6: PIM Hello messages MUST be flooded in the VPLS 898 instance. A PE MUST populate its "PIM Neighbors" list according 899 to the snooping results. This is a general PIM snooping guideline 900 and applies to all variants of PIM snooping. 902 Guideline 7: For PIM-DM only. pim_oiflist(S,G) is populated with 903 all_pim_DM_oiflist (the ACs/PWs in the "PIM Neighbors" list). 904 Changes to the "PIM Neighbors" list MUST be replicated to 905 all_pim_DM_oiflist. 907 - Every router starts sending PIM Hello messages. Per Guideline 908 6, every PE replicates Hello messages and forwards them to all 909 PEs participating in the VPLS instance. 910 - Based on PIM Hello exchanges PE routers populate PIM snooping 911 states as follows. PE 1: {[pim_oiflist(S,G): AC1, PW1to2, 912 PW1to3, PW1to4], [PIM Neighbors: (Router 1,AC1), (Router 913 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)] }, PE 914 2: {[pim_oiflist(S,G): AC2, AC3, PW1to2, PW2to3, PW2to4], [PIM 915 Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), 916 (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: 917 {[pim_oiflist(S,G): AC4, PW1to3, PW2to3, PW3to4], [PIM 918 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 919 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[pim_oiflist(S,G): 920 AC5, PW1to4, PW2to4, PW3to4], [PIM Neighbors: (Router 921 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 922 (Router 5,AC5)]}. The original pim_oiflist(S,G) is populated 923 with ACs/PWs in the PIM neighbor list per Guideline 7.. 924 - PIM Hello messages contain a Holdtime value, which tells the 925 receiver when to expire the neighbor adjacency (which is three 926 times the Hello period). 928 Guideline 8: If a PE does not receive a Hello message from a 929 router within its Holdtime, the PE MUST remove that router from 930 the PIM snooping state. If a PE receives a Hello message from a 931 router with Holdtime value set to zero, the PE MUST remove that 932 router from the PIM snooping state immediately. PEs MUST track 933 the Hello Holdtime value per PIM neighbor. 935 5.4.2.2 PIM-DM Multicast Forwarding 936 The PIM-DM snooping mechanism for multicast forwarding works as 937 follows: 938 - When the source starts sending traffic to multicast group 939 (S,G), PE 3 updates its state to PE 3: {[(S,G); Source: (Router 940 4,AC4); pim_oiflist(S,G): PW1to3, PW2to3, PW3to4], [PIM 941 Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 942 (Router 4,AC4), (Router 5,PW3to4)]}. AC4 is removed from the 943 "pim_oiflist" list for (S,G), since it is where the multicast 944 traffic comes from. 946 Guideline 9: Multicast traffic MUST be replicated per PW and AC 947 basis, i.e., even if there are more than one PIM neighbor behind a 948 PW/AC, only one replication MUST be sent to that PW/AC. 950 - PE 3 replicates the multicast traffic and sends it to the other 951 PE routers in its pim_oiflist(S,G). 952 - Consequently, all PEs update their states as follows. PE 1: 953 {[(S,G); Source: (Router 4,PW1to3); pim_oiflist(S,G): AC1], 954 [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), 955 (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[(S,G); Source: 956 (Router 4,PW2to3); pim_oiflist(S,G): AC2, AC3], [PIM Neighbors: 957 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 958 4,PW2to3), (Router 5,PW2to4)]}, PE 4: {[(S,G); Source: (Router 959 4,PW3to4); pim_oiflist(S,G): AC5], [PIM Neighbors: (Router 960 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 961 (Router 5,AC5)]}. 963 5.4.2.3 PIM-DM Pruning 964 At this point all the routers (Router 1, Router 2,Router 3, Router 5) 965 receive the multicast traffic. 967 - However, Router 3 and Router 5 do not have any members for that 968 multicast group, so they send prune messages to leave the 969 multicast group to the ALL PIM Routers group. PE 2 updates its 970 state to PE 2: {[(S,G); Source: (Router 4,PW2to3); 971 pim_prunes(S,G): AC3, pim_oiflist(S,G): AC2], [PIM Neighbors: 972 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 973 4,PW2to3), (Router 5,PW2to4)]}. PE 4 also removes Router 5 974 from its state as well. 976 Guideline 10: The PIM-DM prune message MUST be forwarded towards 977 the upstream PE only if pim_oiflist(S,G) became empty as a result 978 of the received prune message. If pim_oiflist(S,G) was already 979 null when the PIM-DM prune was received, then the prune MUST NOT 980 be forwarded upstream. 982 - PE 2 does not forward the prune message per Guideline 10. PE 4 983 updates its state to PE 4: {[(S,G); Source: (Router 4,AC4); 984 pim_prunes(S,G): AC5, pim_oiflist(S,G):], [PIM Neighbors: 985 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 986 4,PW3to4), (Router 5,AC5)]}. PE 4 does forward the prune 987 message to PE 3 (upstream neighbor) per guideline 10 and 988 - PIM-DM prune messages contain a Holdtime value, which specifies 989 how many seconds the prune state should last. 991 Guideline 11: For PIM-DM only. A PE MUST keep the prune state for 992 a PW/AC according to the Holdtime in the prune message, unless a 993 corresponding Graft message is received. 995 - Upon receiving the prune messages, each PE 3 updates its state 996 accordingly to PE 3: {[(S,G); Source: (Router 4,AC4); 997 pim_prunes(S,G): PW2to4, pim_oiflist(S,G): PW1to3, PW2to3], 998 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 999 (Router 4,AC4), (Router 5, PW3to4)]}. 1001 Guideline 12: For PIM-DM only. To avoid overriding joins, a PE 1002 SHOULD suppress the PIM prune messages to directly connected 1003 routers (i.e., ACs), as long as there is a PW/AC in its 1004 corresponding pim_oiflist(S,G). 1006 - In this case, PE 1, PE 2, and PE 3 do not forward the prune 1007 messages to their directly connected routers. 1009 5.4.2.4 PIM-DM Grafting 1010 The multicast traffic is now flowing only to points in the network 1011 where receivers are present. 1013 Guideline 13: For PIM-DM only. A PE MUST remove the AC/PW from 1014 its corresponding prune state (pim_prunes(S,G)) when it receives a 1015 graft message from the AC/PW. That is, the corresponding AC/PW 1016 MUST be added to the pim_oiflist(S,G) list. 1018 Guideline 14: For PIM-DM only. PIM-DM graft messages MUST be 1019 forwarded based on the destination MAC address. If the 1020 destination MAC address is 01-00-5E-00-00-0D, then the graft 1021 message MUST be flooded in the VPLS instance. PIM-DM graft 1022 messages MUST NOT be forwarded if pim_oiflist is non-null. 1024 - For the sake of example, suppose now Router 3 has a receiver 1025 the multicast group (S,G). Assuming Router 3 sends a graft 1026 message in IP unicast to Router 4 to restart the flow of 1027 multicast traffic. PE 2 updates its state to PE 2: {[(S,G); 1028 Source: (Router 4,PW2to3); pim_prunes(S,G): , pim_oiflist(S,G): 1029 AC2, AC3], [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), 1030 (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}. PE 2 1031 does not forward the graft message to PE 3 according to 1032 Guideline 14. 1034 5.4.2.5 Failure Scenarios 1035 Guideline 15: PIM Assert messages MUST be flooded in the VPLS 1036 instance. 1038 Guideline 16: If an AC/PW goes down, a PE MUST remove it from its 1039 PIM snooping state. 1041 Failures can be easily handled in PIM-DM snooping, as it uses push 1042 technique. If an AC or a PW goes down, PEs in the VPLS instance will 1043 remove it from their snooping state. After the AC/PW comes back up, 1044 it will be automatically added to the pim_oiflist by PE routers, as 1045 all PWs/ACs MUST be in the pim_oiflist, unless they are pruned later 1046 on. 1048 5.4.3 PIM-SM 1049 The key characteristics of PIM-SM is explicit join behavior. In this 1050 model, the multicast traffic is only sent to locations that 1051 specifically request it. The root node of a tree is the Rendezvous 1052 Point (RP) in case of a shared tree or the first hop router that is 1053 directly connected to the multicast source in the case of a shortest 1054 path tree. 1056 In Figure 2, the RP is behind Router 4, and all routers have at least 1057 one member except Router 3 and Router 5. 1059 As in the case with IGMPv3 snooping, we assume that the PEs have the 1060 capability to store (S,G) states for PIM-SM snooping and 1061 forward/replicate traffic accordingly. 1063 If the PE were to convert a received PIM (S,G) into PIM (*,G), then 1064 it would not know where the RP is and hence where to forward the join 1065 and prunes. Legacy switches may not be able to support (S,G) 1066 forwarding and hence the forwarding portion can probably be made 1067 optional. But there may be some issues with that if there are 1068 multiple (S,G)s for the same G. For instance, the PEs may go into 1069 continuous tear-down/build-up of snooping state. In addition, the 1070 efficiency of multicast forwarding will be less. 1072 5.4.3.1 Discovering Multicast Routers 1073 The PIM-SM snooping mechanism for neighbor discovery works the same 1074 way as the procedure defined in PIM-DM section, with the exception of 1075 PIM-DM only guidelines. 1076 - Based on PIM Hello exchanges PE routers populate PIM snooping 1077 states as follows. PE 1: { [PIM Neighbors: (Router 1,AC1), 1078 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1079 5,PW1to4)]}, PE 2: { [PIM Neighbors: (Router 1,PW1to2), (Router 1080 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, 1081 PE 3: { [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1082 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: { [PIM 1083 Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1084 (Router 4,PW3to4), (Router 5,AC5)]}. 1086 To reduce the amount of PIM Join/Prune traffic in the VPLS network, 1087 it is important that Explicit-Tracking capability be disabled between 1088 the CEs. If a CE advertises tracking support, it is RECOMMENDED that 1089 the PEs modify the tracking-support option in CE Hello packets before 1090 forwarding them to ensure that tracking support is disabled between 1091 the CEs. Otherwise, the mechanism listed for "JP_Optimization" 1092 throughout the PIM-SM and PIM-SSM sections of this document MUST NOT 1093 be employed. 1095 NOTE: The examples below are for scenarios where JP_Optimization is 1096 not employed. 1098 For PIM-SM to work properly, all routers within the domain must use 1099 the same mappings of group addresses to RP addresses. Currently, 1100 there are three methods for RP discovery: 1. Static RP configuration, 1101 2, Auto-RP, and 3. PIMv2 Bootstrap Router mechanism. 1103 Guideline 17: Cisco RP-Discovery (IP:224.0.1.40, MAC:01-00-5E-00- 1104 01-28), Cisco-RP-Announce (IP:224.0.1.39, MAC:01-00-5E-00-01-27), 1105 all bootstrap router (BSR) (IP:224.0.0.13, MAC:01-00-5E-00-00-0D 1106 for IPv4 or FF02::D for IPv6) messages MUST be flooded in the 1107 VPLS instance. 1109 5.4.3.2 PIM-SM (*,G) Join 1110 The PIM-SM snooping mechanism for joining a multicast group (*,G) 1111 works as follows: 1113 Guideline 18: PIM-SM join messages MUST be sent only to the remote 1114 PE, which is connected to the router to which the Join is 1115 addressed. 1116 JP_Optimization: The PIM-SM join message MUST be forwarded towards 1117 the upstream CE only if pim_joins(*,G) became non-empty as a 1118 result of the received join message. If pim_joins(*,G) was 1119 already non-null when the PIM-SM join was received, then the join 1120 MUST NOT be forwarded upstream. 1122 PIM-SM join messages MUST be sent only to the remote PE, which is 1123 connected to the router to which the Join is addressed. The remote 1124 PE can be determined by the "Upstream Neighbor Address" field of the 1125 Join message. The "Upstream Neighbor Address" can be correlated to a 1126 PW or an AC in the "PIM Neighbors" state. By Guideline 18, we are 1127 ensuring that the other routers that are part of the VPLS instance do 1128 not receive the PIM join messages and will initiate their own join 1129 messages if they are interested in receiving that particular 1130 multicast traffic. 1132 - Assume Router 1 wants to join the multicast group (*,G) sends a 1133 join message for the multicast group (*,G). PE 1 sends the 1134 join message to PE 3 by Guideline 18. 1136 Guideline 19: A PE MUST add a PW/AC to its pim_joins(*,G) list, if 1137 it receives a (*,G) join message from the PW/AC. 1139 - PE 1 updates their states as follows: PE 1: {[pim_joins(*,G): 1140 AC1], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 1141 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}. 1143 A periodic refresh mechanism is used in PIM-SM to maintain the proper 1144 state. PIM-SM join messages contain a Holdtime value, which 1145 specifies for how many seconds the join state should be kept. 1147 Guideline 20: If a PE does not receive a refresh join message from 1148 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 1149 pim_joins(*,G) list. 1151 - All PEs update their states accordingly as follows: PE 1: 1152 {[pim_joins(*,G): AC1], [PIM Neighbors: (Router 1,AC1), (Router 1153 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 1154 2: {[PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 1155 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: 1156 {[pim_joins(*,G): PW1to3], [PIM Neighbors: (Router 1,PW1to3), 1157 (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 1158 5,PW3to4)]}, PE 4: {[PIM Neighbors: (Router 1,PW1to4), (Router 1159 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1160 - After Router 2 joins the same multicast group, the states 1161 become as follows: PE 1: {[pim_joins(*,G): AC1], [PIM 1162 Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 1163 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[pim_joins(*,G): AC2], 1164 [PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 1165 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: 1166 {[pim_joins(*,G): PW1to3, PW2to3], [PIM Neighbors: (Router 1167 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 1168 5,PW3to4)]}, PE 4: {[PIM Neighbors: (Router 1,PW1to4), (Router 1169 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1170 - For the sake of example, Router 3 joins the multicast group. 1171 PE 2 sends the join message to PE 3. 1172 - Next Router 5 joins the group, and the states are updated 1173 accordingly: PE 1: {[pim_joins(*,G): AC1], [PIM Neighbors: 1174 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 1175 (Router 5,PW1to4)]}, PE 2: {[pim_joins(*,G): AC2, AC3], [PIM 1176 Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), 1177 (Router 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[pim_joins(*,G): 1178 PW1to3, PW2to3, PW3to4], [PIM Neighbors: (Router 1,PW1to3), 1179 (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 1180 5,PW3to4)]}, PE 4: {[pim_joins(*,G): AC5],[PIM Neighbors: 1181 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 1182 4,PW3to4), (Router 5,AC5)]} 1184 At this point, all PEs have necessary states to not send multicast 1185 traffic to sites with no members. 1187 5.4.3.3 PIM-SM Pruning 1188 The PIM-SM snooping mechanism for leaving a multicast group works as 1189 follows: 1190 - Assume Router 5 sends a prune message. 1192 Guideline 21: PIM-SM prune messages MUST be flooded in the VPLS 1193 instance. 1194 JP_Optimization: Instead of the above guideline, a PE MUST forward 1195 prune messages only towards the upstream CE and only if 1196 pim_joins(*,G) became empty as a result of the received prune 1197 message. If pim_joins(*,G) is non-empty after receiving the prune 1198 message, the PE MUST NOT forward the prune message. 1200 Guideline 22: A PE MUST remove a PW/AC from its pim_joins(*,G) 1201 list if it receives a (*,G) prune message from the PW/AC. A 1202 prune-delay timer SHOULD be implemented to support prune override. 1203 However, the prune-delay timer is not required if there is only 1204 one PIM neighbor on that AC/PW on which the prune was received. 1206 - PE 4 floods the (*,G) prune to the VPLS instance per Guideline 1207 21. PE routers participating in the VPLS instance also forward 1208 the (*,G) prune to the ACs, which are connected to the VPLS 1209 instance. The states are updated as follows: PE 1: 1210 {[pim_joins(*,G): AC1], [PIM Neighbors: (Router 1,AC1), (Router 1211 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 1212 2: {[pim_joins(*,G): AC2, AC3], [PIM Neighbors: (Router 1213 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1214 (Router 5,PW2to4)]}, PE 3: {[pim_joins(*,G): PW1to3, PW2to3], 1215 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1216 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[PIM Neighbors: 1217 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 1218 4,PW3to4), (Router 5,AC5)]}. 1220 In PIM-SM snooping, prune messages are flooded by PE routers. In 1221 such implementation, PE routers may receive overriding join messages, 1222 which will not affect anything. 1224 5.4.3.4 PIM-SM (S,G) Join 1225 The PIM-SM snooping mechanism for source and group specific join 1226 works as follows: 1228 Guideline 23: A PE MUST add a PW/AC to its pim_joins(S,G) list if 1229 it receives a (S,G) join message from the PW/AC. The PE MUST 1230 forward the received join message towards the upstream CE. 1231 JP_Optimization: The PE MUST forward the Join message towards the 1232 upstream neighbor only if the pim_joins(S,G) list becomes non- 1233 empty as a result of the received join. If the pim_joins(S,G) 1234 list was non-empty prior to receiving the join message, then the 1235 PE MUST NOT forward the join message. 1237 Guideline 24: A PE MUST remove a PW/AC from its pim_joins(S,G) 1238 list if it receives a (S,G) prune message from the PW/AC. The PE 1239 MUST flood the prune message in the VPLS instance. A prune-delay 1240 timer SHOULD be implemented to support prune override on the 1241 downstream AC/PW. However, the prune-delay timer is not required 1242 if there is only one PIM neighbor on that AC/PW on which the prune 1243 was received. 1244 JP_Optimization: Instead of flooding the prune message in the VPLS 1245 instance, the PE MUST forward the prune message towards the 1246 upstream neighbor only if the pim_joins(S,G) list becomes empty as 1247 a result of the received prune. If the pim_joins(S,G) list 1248 remains non-empty after receiving the prune message, then the PE 1249 MUST NOT forward the prune message. 1251 Guideline 25: A PE MUST prefer (S,G) state to (*,G), if both S and 1252 G match. 1254 5.4.3.5 PIM-SM (S,G,rpt) Prunes 1255 Guideline 28: When a PE receives a Prune(S,G,rpt) on an AC/PW, it 1256 MUST add the AC/PW to the pim_prunes(S,G,rpt) list. Additionally, 1257 if pim_inherited_olist(S,G,rpt) becomes empty, the PE MUST forward 1258 the Prune(S,G,rpt) towards the upstream neighbor. If 1259 pim_snoop_inherited_olist(S,G,rpt) is still non-empty, then the PE 1260 MUST NOT forward the Prunes(S,G,rpt). 1262 5.4.3.6 PIM-SM (*,*,RP) State 1263 PIM-SM defines a (*,*,RP) state which is used when traffic needs to 1264 cross multicast domains. A (*,*,RP) receiver requests all multicast 1265 traffic within a PIM domain to be sent to it. If the two multicast 1266 domains are both PIM-SM, they can use MSDP to leak multicast routes. 1267 But, if one is PIM-SM and the other is PIM-DM (hence, MSDP can not be 1268 used), then the border router would initiate a (*,*,RP) join to all 1269 RPs in the PIM-SM domain. 1271 If the customers will configure multiple and different PIM domains, 1272 PIM-SM snooping MUST support (*,*,RP) state as well. Depending on 1273 how likely scenario this is, future versions may include (*,*,RP) 1274 states. 1276 5.4.3.7 Failure Scenarios 1277 Failures can be easily handled in PIM-SM snooping, as it employs 1278 state-refresh technique. PEs in the VPLS instance will remove any 1279 entry for non-refreshing routers from their states. 1281 5.4.3.8 Special Cases for PIM-SM Snooping 1282 There are some special cases to consider for PIM-SM snooping. First 1283 one is the RP-on-a-stick. The RP-on-a-stick scenario may occur when 1284 the Shortest Path Tree and the Shared Tree shares a common Ethernet 1285 segment, as all routers will be connected over a multicast access 1286 network (i.e., VPLS). Such a scenario will be handled by PIM-SM 1287 rules (particularly, the incoming interface can not also appear in 1288 the outgoing interface list) very nicely. Second scenario is the 1289 turnaround router. The turnaround router scenario occurs when 1290 shortest path tree and shared tree share a common path. The router 1291 at which these trees merge is the turnaround router. PIM-SM handles 1292 this case by proxy (S,G) join implementation by the turnaround 1293 router. 1295 There can be some scenarios where CE routers can receive duplicate 1296 multicast traffic. Let�s consider the scenario in Figure 3. 1298 +------+ AC3 +------+ 1299 | PE2 |-----| R3 | 1300 /| | | | 1301 / +------+ +------+ 1302 / | | 1303 / | | 1304 /PW1to2 | | 1305 / | +-----+ 1306 / |PW2to3 | Src | 1307 / | +-----+ 1308 / | | 1309 / | | 1310 / | | 1311 +------+ +------+ / +------+ +------+ 1312 | R1 | | PE1 |/ PW1to3 | PE3 | | R4 | 1313 | |-----| |-------------| |-----| | 1314 +------+ AC1 +------+ +------+ AC4 +------+ 1315 | | 1316 |AC2 |AC5 1317 +------+ +------+ 1318 | R2 | | R5 | +---+ 1319 | | | |-----|RP | 1320 +------+ +------+ +---+ 1322 Figure 3 CE Routers Receive Duplicate Traffic 1324 In the scenario depicted in Figure 3, both R1 and R2 has two ECMP 1325 routes to reach the source "Src". Hence, R1 may pick R3 as its next 1326 hop ("Upstream Neighbor"), and R2 may pick R4 as its next hop. As a 1327 result, both R1 and R2 will receive duplicate traffic. 1329 This issue can be solved as follows. PEs can keep the PW/AC that the 1330 join message is forwarded to (upstream PW/AC) in "pim_joins(S,G)" 1331 list in addition to the PW/AC that the join message is received 1332 (downstream PW/AC). If the traffic arrives from a different PW/AC, 1333 that traffic is not forwarded downstream. Hence, in the example 1334 depicted in Figure 3 where source is dual homed to R3 and R4, R1 will 1335 receive (S,G) traffic if it comes from PW1to2, and R2 will receive 1336 (S,G) traffic if it comes from PW1to3. 1338 Again, in Figure 3, R1 may send (S,G) join to R3 and R2 may send 1339 (*,G) join to the RP behind R5. In this scenario as well, both R1 1340 and R2 will receive duplicate traffic, as Guideline 25 will be no 1341 help to prevent it. 1343 In this case, where R1 joins for (S,G), and R2 joins for (*,G), we 1344 can do the following. We can solve the problem by triggering Assert 1345 mechanism in CE routers. The PE which detects the duplicate traffic 1346 problem can simply remove the snooping state for that particular 1347 multicast group, and can send out "flush" message to other PEs 1348 participating in the VPLS instance. In return, other PEs also flush 1349 their snooping state for that multicast group. As a result, all the 1350 PEs will flood the multicast traffic in the VPLS instance (by Rule 1351 3). Consequently, CEs will do Assert. The flush message TLV can be 1352 sent over the targeted LDP sessions running among PEs. For this 1353 purpose, we propose new "Multicast Group TLV". 1355 Multicast groups to be flushed can be signaled using an LDP Address 1356 Withdraw Message that contains a FEC TLV (to identify the VPLS 1357 instance), a Multicast Group TLV and optional parameters. The format 1358 of the Multicast Group TLV is described below. 1360 0 1 2 3 1361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 |U|F| Type | Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Multicast Group Address (Encoded-Group format) | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Multicast Source Address (Encoded-Unicast format) | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 // 1370 // 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 U bit 1374 Unknown bit. This bit MUST be set to 1. If TLV is not 1375 understood by the node, it MUST be ignored. 1377 F bit 1378 Forward bit. This bit MUST be set to 0. Since the LDP 1379 mechanism used here is Targeted, the TLV MUST NOT be forwarded. 1381 Type 1382 Type field. This identifies the TLV type as Multicast Group 1383 TLV. 1384 Value: TBA by IANA. 1386 Length 1387 Length field. This field specifies the total length of the 1388 Multicast addresses in the TLV, including Multicast Group 1389 addresses and Multicast Source Addresses. 1391 Multicast Group Address 1392 The address of the Multicast group that needs to be flushed. 1393 Detailed format is described in [RFC2362] Section 4.9.1. 1395 Multicast Source Address 1396 The host address of the Multicast source. Detailed format is 1397 described in [RFC2362] Section 4.9.1. A special wild card value 1398 consisting of an address field of all zeroes can be used to 1399 indicate any source, and all the (S,G) and (*,G) entries that 1400 match the Group Address G MUST be flushed. 1402 5.4.4 PIM-SSM 1403 The key characteristics of PIM-SSM is explicit join behavior, but it 1404 eliminates the shared tree and the rendezvous point in PIM-SM. In 1405 this model, a shortest path tree for each (S,G) is built with the 1406 first hop router (that is directly connected to the multicast source) 1407 being the root node. PIM-SSM is ideal for one-to-many multicast 1408 services. 1410 In Figure 2, S1 is behind Router 1, and S4 is behind Router 4. 1411 Routers 2 and 4 want to join (S1,G), while Router 5 wants to join 1412 (S4,G). 1414 We assume that the PEs have the capability to store (S,G) states for 1415 PIM-SSM snooping and constrain multicast flooding scope accordingly. 1416 An implementation, can fall back to (*,G) states, if its hardware can 1417 not support it. In such case, the efficiency of multicast forwarding 1418 will be less. 1420 5.4.4.1 Discovering Multicast Routers 1421 The PIM-SSM snooping mechanism for neighbor discovery works the same 1422 way as the procedure defined in PIM-DM section, with the exception of 1423 PIM-DM only guidelines. 1424 - Based on PIM Hello exchanges PE routers populate PIM snooping 1425 states as follows. PE 1: { [PIM Neighbors: (Router 1,AC1), 1426 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1427 5,PW1to4)]}, PE 2: { [PIM Neighbors: (Router 1,PW1to2), (Router 1428 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, 1429 PE 3: { [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1430 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: { [PIM 1431 Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1432 (Router 4,PW3to4), (Router 5,AC5)]}. 1434 5.4.4.2 Guidelines for PIM-SSM Snooping 1435 PIM-SSM snooping is actually simpler than PIM-SM and only the 1436 following guidelines (some of which are repetitions from PIM-SM 1437 section) apply. 1439 Guideline 28: A PE MUST add a PW/AC to its (S,G) pim_joins(S,G) 1440 list if it receives a (S,G) join message from the PW/AC. 1442 Guideline 29: PIM-SSM join messages MUST be sent only to the 1443 remote PE, which is connected to the router to which the Join is 1444 addressed. 1445 JP_Optimization: The PE MUST forward the Join message towards the 1446 upstream neighbor only if the pim_joins(S,G) list becomes non- 1447 empty as a result of the received join. If the pim_joins(S,G) 1448 list was non-empty prior to receiving the join message, then the 1449 PE MUST NOT forward the join message. 1451 Guideline 30: PIM prune messages MUST be flooded in the VPLS 1452 instance. A prune-delay timer SHOULD be implemented to support 1453 prune override on the downstream AC/PW. However, the prune-delay 1454 timer is not required if there is only one PIM neighbor on that 1455 AC/PW on which the prune was received. 1456 JP_Optimization: Instead of flooding the prune message in the VPLS 1457 instance, the PE MUST forward the prune message towards the 1458 upstream neighbor only if the pim_joins(S,G) list becomes empty as 1459 a result of the received prune. If the pim_joins(S,G) list 1460 remains non-empty after receiving the prune message, then the PE 1461 MUST NOT forward the prune message. 1463 Guideline 31: If A PE does not receive a refresh join message from 1464 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 1465 pim_joins(S,G) list. 1467 Guideline 32: A PE MUST remove a PW/AC from its pim_joins(S,G) 1468 list if it receives a (S,G) prune message from the PW/AC. A 1469 prune-delay timer SHOULD be implemented to support prune override. 1471 5.4.4.3 PIM-SSM Join 1472 The PIM-SSM snooping mechanism for joining a multicast group works as 1473 follows: 1474 - Assume Router 2 requests to join the multicast group (S1,G). 1475 - PE 2 updates its state, and then sends the join message to PE 1476 1. 1477 - All PEs update their states as follows: PE 1: 1478 {[pim_joins(S1,G): PW1to2], [PIM Neighbors: (Router 1,AC1), 1479 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1480 5,PW1to4)]}, PE 2: {[pim_joins(S1,G): AC2], [PIM Neighbors: 1481 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 1482 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[PIM Neighbors: (Router 1483 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), (Router 1484 5,PW3to4)]}, PE 4: {[PIM Neighbors: (Router 1,PW1to4), (Router 1485 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1486 - Next, assume Router 4 sends a join (S1,G) message. Following 1487 the same procedures, all PEs update their states as follows: PE 1488 1: {[pim_joins(S1,G): PW1to2, PW1to3], [PIM Neighbors: (Router 1489 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1490 5,PW1to4)]}, PE 2: {[pim_joins(S1,G): AC2], [PIM Neighbors: 1491 (Router 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 1492 4,PW2to3), (Router 5,PW2to4)]}, PE 3: {[pim_joins(S1,G): AC4], 1493 [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 3,PW2to3), 1494 (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[PIM Neighbors: 1495 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 1496 4,PW3to4), (Router 5,AC5)]}. 1497 - Then, assume Router 5 requests to join the multicast group 1498 (S4,G). After the same procedures are applied, all PEs update 1499 their states as follows: PE 1: {[pim_joins(S1,G): PW1to2, 1500 PW1to3], [PIM Neighbors: (Router 1,AC1), (Router 2,Router 1501 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)]}, PE 2: 1502 {[pim_joins(S1,G): AC2], [PIM Neighbors: (Router 1,PW1to2), 1503 (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 1504 5,PW2to4)]}, PE 3: {[pim_joins(S1,G): AC4], [pim_joins(S4,G): 1505 PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1506 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: 1507 {[pim_joins(S4,G): AC5], [PIM Neighbors: (Router 1,PW1to4), 1508 (Router 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 1509 5,AC5)]}. 1511 5.4.4.4 PIM-SSM Prune 1512 At this point, all PEs have necessary states to not send multicast 1513 traffic to sites with no members. 1515 The PIM-SSM snooping mechanism for leaving a multicast group works as 1516 follows: 1517 Assume Router 2 sends a (S1,G) prune message to leave the multicast 1518 group. The prune message gets flooded in the VPLS instance. All PEs 1519 update their states as follows: PE 1: {[pim_joins(S1,G): PW1to3], 1520 [PIM Neighbors: (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 1521 4,PW1to3), (Router 5,PW1to4)]}, PE 2: {[PIM Neighbors: (Router 1522 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 1523 5,PW2to4)]}, PE 3: {[pim_joins(S1,G): AC4], [(S4,G); Flood to: 1524 PW3to4], [PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1525 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: 1526 {[pim_joins(S4,G): AC5], [PIM Neighbors: (Router 1,PW1to4), (Router 1527 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)]}. 1529 In PIM-SSM snooping, prune messages are flooded by PE routers. In 1530 such implementation, PE routers may receive overriding join messages, 1531 which will not affect anything. 1533 5.4.4.5 Failure Scenarios 1534 Similar to PIM-SSM snooping, failures can be easily handled in PIM- 1535 SSM snooping, as it employs state-refresh technique. The PEs in the 1536 VPLS instance will remove entry for non-refreshing routers from their 1537 states. 1539 5.4.4.6 Special Cases for PIM-SSM Snooping 1540 The scenarios with duplicate traffic as depicted in Figure 3 apply to 1541 PIM-SSM snooping as well. Again, the issue can be solved by the 1542 method described in Section 5.4.3.8. 1544 5.4.5 Bidirectional-PIM (BIDIR-PIM) 1545 BIDIR-PIM is a variation of PIM-SM. The main differences between 1546 PIM-SM and Bidirectional-PIM are as follows: 1547 - There are no source-based trees, and source-specific multicast 1548 is not supported (i.e., no (S,G) states) in BIDIR-PIM. 1549 - Multicast traffic can flow up the shared tree in BIDIR-PIM. 1550 - To avoid forwarding loops, one router on each link is elected 1551 as the Designated Forwarder (DF) for each RP in BIDIR-PIM. 1553 The main advantage of BIDIR-PIM is that it scales well for many-to- 1554 many applications. However, the lack of source-based trees means 1555 that multicast traffic is forced to remain on the shared tree. 1557 5.4.5.1 Discovering Multicast Routers 1558 The PIM-SSM snooping mechanism for neighbor discovery works the same 1559 way as the procedure defined in PIM-DM section, with the exception of 1560 PIM-DM only guidelines. 1562 - Based on PIM Hello exchanges PE routers populate PIM snooping 1563 states as follows. PE 1: {[PIM Neighbors: (Router 1,AC1), 1564 (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1565 5,PW1to4)]}, PE 2: {[PIM Neighbors: (Router 1,PW1to2), (Router 1566 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)]}, 1567 PE 3: {[PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1568 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)]}, PE 4: {[PIM 1569 Neighbors: (Router 1,PW1to4), (Router 2,Router 3,PW2to4), 1570 (Router 4,PW3to4), (Router 5,AC5)]}. 1572 For BIDIR-PIM to work properly, all routers within the domain must 1573 know the address of the RP. There are three methods to do that: 1. 1574 Static RP configuration, 2, Auto-RP, and 3. PIMv2 Bootstrap. 1575 Guideline 17 applies here as well. 1577 During RP discovery time, PIM routers elect DF per subnet for each 1578 RP. The algorithm to elect the DF is as follows: all PIM neighbors 1579 in a subnet advertise their unicast route to the RP and the router 1580 with the best route is elected. 1582 Guideline 33: All PEs MUST snoop the DF election messages and 1583 determine the DF for each [(*,G),RP] (i.e., RP(G)) pair. The 1584 AC/PW towards the DF (i.e., DF(RP)) MUST be added to the 1585 pim_oiflist for each (*,G) whose RP(G) is RP. When DF(RP) 1586 changes, the pim_oiflist must be updated accordingly. 1588 - In Figure 2, there is one RP (let�s call it RPA) behind Router 1589 5. Based on DF election messages, PE routers populate PIM 1590 snooping states as follows: PE 1: {[PIM Neighbors: (Router 1591 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1592 5,PW1to4)], [DF(RPA): PW1to3], PE 2: {[PIM Neighbors: (Router 1593 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1594 (Router 5,PW2to4)], [DF(RPA): PW2to3]}, PE 3: {[PIM Neighbors: 1595 (Router 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), 1596 (Router 5,PW3to4)], [DF(RPA): AC5]}, PE 4: {[PIM Neighbors: 1597 (Router 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 1598 4,PW3to4), (Router 5,AC5)], [DF(RPA): PW3to4]}. 1600 5.4.5.2 Guidelines for BIDIR-PIM Snooping 1601 The BIDIR-PIM snooping for Join and Prune messages is similar to 1602 PIM-SM and the following guidelines (some of which are repetitions 1603 from PIM-SM section) apply. 1605 Guideline 34: A PE MUST add a PW/AC to its pim_joins(*,G) list if 1606 it receives a (*,G) join message from the PW/AC. 1608 Guideline 35: BIDIR-PIM join messages MUST be flooded to all PEs 1609 in the VPLS instance. BIDIR-PIM join messages received on remote 1610 PEs MUST be forwarded only towards the router to which the Join is 1611 addressed. 1613 Guideline 36: BIDIR-PIM prune messages MUST be flooded in the VPLS 1614 instance. 1616 Guideline 37: If A PE does not receive a refresh join message from 1617 a PW/AC within its Holdtime, the PE MUST remove the PW/AC from its 1618 pim_joins(*,G) list. 1620 Guideline 38: A PE MUST remove a PW/AC from its pim_joins(*,G) 1621 list if it receives a (*,G) prune message from the PW/AC. A 1622 prune-delay timer SHOULD be implemented to support prune override. 1624 5.4.5.3 BIDIR-PIM Join 1625 The BIDIR-PIM snooping mechanism for joining a multicast group works 1626 as follows: 1627 - As before, assume the RP for both G1 and G4 (RPA) is behind 1628 Router 4. Assume Router 2 wants to join the multicast group 1629 (*,G1). PE 2 sends the join message to the other PEs. All PEs 1630 update their states as follows: PE 1: {[PIM Neighbors: (Router 1631 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 1632 5,PW1to4)], [DF(RPA): PW1to3], [pim_joins(*,G1): PW1to2]}, PE 1633 2: {[PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), (Router 1634 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)], [DF(RPA): 1635 PW2to3], [pim_joins(*,G1): AC2]}, PE 3: {[PIM Neighbors: 1636 (Router 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), 1637 (Router 5,PW3to4)], [DF(RPA): AC4], [pim_joins(*,G1): PW2to3]}, 1638 PE 4: {[PIM Neighbors: (Router 1,PW1to4), (Router 2,Router 1639 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)], [DF(RPA): 1640 PW3to4], [pim_joins(*,G1): PW2to4]}. 1641 - Next, assume Router 4 wants to join the multicast group (*,G1). 1642 All PEs update their states as follows: PE 1: {[PIM Neighbors: 1643 (Router 1,AC1), (Router 2,Router 3,PW1to2), (Router 4,PW1to3), 1644 (Router 5,PW1to4)], [DF(RPA): PW1to3], [pim_joins(*,G1): 1645 PW1to2, PW1to3]}, PE 2: {[PIM Neighbors: (Router 1,PW1to2), 1646 (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), (Router 1647 5,PW2to4)], [DF(RPA): PW2to3], [pim_joins(*,G1): AC2, PW2to3}, 1648 PE 3: {[PIM Neighbors: (Router 1,PW1to3), (Router 2,Router 1649 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)], [DF(RPA): AC4], 1650 pim_joins(*,G1): PW2to3, AC4]}, PE 4: {[PIM Neighbors: (Router 1651 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 1652 (Router 5,AC5)], [DF(RPA): PW3to4], [pim_joins(*,G1): PW2to4, 1653 PW3to4]}. 1655 - Then, assume Router 5 wants to join the multicast group (*,G4). 1656 Following the same procedures, all PEs update their states as 1657 follows: PE 1: {[PIM Neighbors: (Router 1,AC1), (Router 1658 2,Router 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)], 1659 [DF(RPA): PW1to3], [pim_joins(*,G1): PW1to2, PW1to3], 1660 [pim_joins(*,G4): PW1to4]}, PE 2: {[PIM Neighbors: (Router 1661 1,PW1to2), (Router 2,AC2), (Router 3,AC3), (Router 4,PW2to3), 1662 (Router 5,PW2to4)], [DF(RPA): PW2to3], [pim_joins(*,G1): AC2, 1663 PW2to3], [pim_joins(*,G4): PW2to4]}, PE 3: {[PIM Neighbors: 1664 (Router 1,PW1to3), (Router 2,Router 3,PW2to3), (Router 4,AC4), 1665 (Router 5,PW3to4)], [DF(RPA): AC4], pim_joins(*,G1): PW2to3, 1666 AC4], pim_joins(*,G4): PW3to4]}, PE 4: {[PIM Neighbors: (Router 1667 1,PW1to4), (Router 2,Router 3,PW2to4), (Router 4,PW3to4), 1668 (Router 5,AC5)], [DF(RPA): PW3to4], [pim_joins(*,G1): PW2to4, 1669 PW3to4], [pim_joins(*,G4): AC5]}. 1671 5.4.5.4 BIDIR-PIM Prune 1672 At this point, all PEs have necessary states to not send multicast 1673 traffic to sites with no members. 1675 One example of the BIDIR-PIM snooping mechanism for leaving a 1676 multicast group works as follows: 1677 - Assume Router 2 wants to leave the multicast group (*,G1) and 1678 sends a (*,G1) prune message. The prune message gets flooded 1679 in the VPLS instance. All PEs update their states as follows: 1680 PE 1: {[PIM Neighbors: (Router 1,AC1), (Router 2,Router 1681 3,PW1to2), (Router 4,PW1to3), (Router 5,PW1to4)], [DF(RPA): 1682 PW1to3], [pim_joins(*,G1): PW1to3], [pim_joins(*,G4): PW1to4]}, 1683 PE 2: {[PIM Neighbors: (Router 1,PW1to2), (Router 2,AC2), 1684 (Router 3,AC3), (Router 4,PW2to3), (Router 5,PW2to4)], 1685 [DF(RPA): PW2to3], [pim_joins(*,G1): PW2to3], [pim_joins(*,G4): 1686 PW2to4]}, PE 3: {[PIM Neighbors: (Router 1,PW1to3), (Router 1687 2,Router 3,PW2to3), (Router 4,AC4), (Router 5,PW3to4)], 1688 [DF(RPA): AC4], [pim_joins(*,G1): AC1], [pim_joins(*,G4): 1689 PW3to4]}, PE 4: {[PIM Neighbors: (Router 1,PW1to4), (Router 1690 2,Router 3,PW2to4), (Router 4,PW3to4), (Router 5,AC5)], 1691 [DF(RPA): PW3to4], [pim_joins(*,G1): PW3to4], [pim_joins(*,G4): 1692 AC5]}. 1694 5.4.5.5 Failure Scenarios 1695 Once again, failures can be easily handled in BIDIR-PIM snooping, as 1696 it employs state-refresh technique. PEs in the VPLS instance will 1697 remove entry for non-refreshing routers from their states. 1699 5.4.6 Multicast Source Directly Connected to the VPLS Instance 1700 If there is a source in the CE network that connects directly into 1701 the VPLS instance, then multicast traffic from that source MUST be 1702 sent to all PIM routers on the VPLS instance apart from the outgoing 1703 interface list for the corresponding snooping state. If there is 1704 already (S,G)/(*,G) snooping state that is formed on any PE, this 1705 will not happen per the current forwarding rules and guidelines. The 1706 (S,G)/(*,G) state may not send traffic towards all the routers. So, 1707 in order to determine if traffic needs to be flooded to all routers, 1708 a PE must be able to determine if the traffic came from a host on 1709 that LAN. There are three ways to address this problem: 1710 - The PE would have to do ARP snooping to determine if a source 1711 is directly connected. 1712 - Another option is to have configuration on all PEs to say there 1713 are CE sources that are directly connected to the VPLS instance 1714 and disallow snooping for the groups for which the source is 1715 going to send traffic. This way traffic from that source to 1716 those groups will always be flooded within the provider 1717 network. 1718 - A third option is to require that sources of CE multicast 1719 routers must appear behind a router. 1721 5.4.7 Data Forwarding Rules 1722 The final list of outgoing interfaces for a given (S,G) or (*,G) is 1723 computed by combining the IGMP and PIM state summarization macros. 1725 oifList(*,G) = igmp_include(*,G) (+) pim_oiflist(*,G) 1727 oiflist(S,G) = igmp_include(*,G) (-) igmp_exclude(S,G) (+) 1728 igmp_include(S,G) (+) pim_oiflist(S,G) 1730 If PIM Snooping is active for a given (*,G) or (S,G), then the PE 1731 also tracks the upstream AC/PW as the RPF interface. Data traffic 1732 MUST be forwarded ONLY IF traffic arrives on the RPF interface. If 1733 data traffic arrives on any other interface, then the following rules 1734 apply: 1735 - If the traffic arrives on an AC and the PE determines that the 1736 traffic is coming from a directly connected source, then the 1737 rules described in Section 5.4.6 apply. 1738 - Otherwise, it could be a PIM ASSERT scenario. Then the rules 1739 described in Section 5.4.3.8 apply. 1741 In the presence of only IGMP Snooping state, there is no RPF 1742 interface that can be remembered. In such a scenario, traffic should 1743 simply be forwarded to the pim_oiflist after performing source 1744 interface pruning. 1746 5.4.8 PIM Snooping at PWs Overwhelm PEs 1747 In [MVPN-VPLS], it is commented that PIM snooping (due to refreshing 1748 scheme) in PWs will overwhelm PEs. To address this issue, we provide 1749 a proposal in this section. 1751 Although PIM refresh reduction is under consideration, PEs are 1752 RECOMMENEDED to implement this scheme, as CEs need not change, and 1753 PEs will not depend on CEs to turn refresh reduction on. Only the 1754 PEs need to implement this scheme. Note this scheme is trying to 1755 take care of Refresh reduction only. If all the states are 1756 continuously flapping, then VPLS has to deal with it irrespective of 1757 which solution is used for refresh reduction. 1759 In order to prevent control traffic explosion in the core, the PEs 1760 can be configured to not exceed a threshold which represents the 1761 aggregate amount of PIM refresh traffic that can be generated in the 1762 core. Since the PEs are fully meshed, the PEs can determine their 1763 individual rate by dividing the threshold by the number of PEs in the 1764 mesh. This gives the amount of PIM refresh traffic that a PE can 1765 generate in the core. Once we have this number (call it the 1766 tx_threshold), we proceed in the following fashion. 1768 For every PIM Join/Prune PDU received by a PE from the access side 1769 (i.e., AC), the PE will modify the holdtime to a large value 1770 (possibly even infinity) before sending out into the core. The 1771 holdtime, call it core_holdtime, can be configured OR can be 1772 adaptively computed based on the number of entries the PE has. The 1773 core_holdtime ensures that the core side (all the relevant PEs and 1774 the CEs connected to them) will not time out the state as fast as an 1775 access side upstream router would, in the absence of a Join refresh. 1776 The PE will also keep track of when the holdtimer will expire in the 1777 core for an entry (call this the core_holdtimer). A typical value of 1778 the core_holdtime would be something like 10-20 times the received 1779 holdtime in the PDU. The core_holdtime is jittered across PDUs so 1780 that all of them do not fire at once (all entries in a PDU get the 1781 same core_holdtime). 1783 Once this is done, for every entry that has a core_holdtimer running, 1784 the PE will not send any refreshes that it receives from the access 1785 side, into the core, if the following condition is satisfied: 1786 The core_holdtimer will expire at a time that is greater than twice 1787 the holdtime encoded in the Join/Prune PDU received from the access 1788 (this is an arbitrary multiplier, call it X). If the core_holdtime 1789 will expire at a time that is less than X times the holdtime encoded 1790 in the Join/Prune PDU received from the access, AND if the PE can 1791 send a JP PDU (because it will not exceed the tx_threshold), only 1792 then the PE will propagate the refresh into the core, again with the 1793 holdtime modified to the core_holdtime. If it can�t because it would 1794 exceed the tx_threshold, it will wait for the next refresh as long as 1795 X is greater than 1. If X is 1, then it will propagate the refresh 1796 irrespective of whether the tx_threshold will exceed or not. The 1797 idea here is that if X is reasonable enough, then it will get a 1798 chance to send out the refresh without exceeding the threshold most 1799 of the times. 1801 To take care of the possibility of Join/Prune PDUs getting lost, we 1802 could have a configured robustness variable R like in IGMP for the 1803 VPLS instance (possibly even per PW). This simply means that we will 1804 propagate the Joins R times into the core instead of 1, before we 1805 skip propagating them when they arrive. 1807 The hold time is modified only when there is at least one of the 1808 following in the PDU: 1809 - (*,G) Join, (S,G) Join or (S,G,rpt) Prune, since these are the 1810 states that are refreshed. 1811 - (*,G) Prune, (S,G) Prune and (S,G,rpt) Join are not refreshed 1812 in PIM and are used only to deregister state, so the holdtime 1813 modification does not apply to these. 1815 Corresponding to every entry that a PE creates upon receiving a Join 1816 from an AC, the PE maintains an upstream state which consists of: 1817 1) Upstream PW (defined in the previous sections) 1818 2) Upstream neighbor (defined in the previous sections) 1819 3) core_holdtimer 1821 Once this state is created due to a downstream state received on an 1822 AC, the PE takes no action with respect to the upstream state if it 1823 receives Joins for the same state from other ACs. Since the upstream 1824 PW has already been notified, there is no need to propagate those 1825 Joins towards the PW. 1827 If a CE on an AC sends a Join causing the upstream state to be 1828 created and the downstream state times out (due to not seeing a Join 1829 from the CE again), and if that is the only downstream state, then 1830 the PE will simulate a Prune towards the PW by using any AC neighbor 1831 as the source IP of the Prune packet. This ensures that the core 1832 side will time out the state immediately. Same thing applies to 1833 (S,G,rpt) Joins. 1835 Core_holdtime determination (optional): As mentioned earlier, a PE 1836 can adaptively determine the value of core_holdtime it should use, 1837 based on the number of entries it has on the AC side. For example, 1838 if a PE has 1000 entries, and its tx_threshold is 10 packets per 1839 second, and assuming a worst case of 1 Join/Prune entry per 1840 Join/Prune PDU, it is safe to say that if every 60 seconds, the PE 1841 receives a refresh for all 1000 entries and it propagates only 10 of 1842 them (unique), it will take 60 * 100 seconds for all the entries to 1843 be refreshed i.e. 100 minutes. A reasonable value of core holdtime 1844 then can be used as 1.25 * 6000 = 7500 seconds. X above can be 1845 chosen to be 25 or 50. If you assume a better case, say 50 entries 1846 per Join/Prune PDU, 1000 entries would take 20 PDUs i.e. 120 seconds. 1847 So a core_holdtime of 1.25 * 120 = 150 seconds with X = 2 might do. 1848 The basic idea being, it would refresh more often if there are less 1849 entries, and less often if there are more entries. Or the 1850 core_holdtime could be simply configured to keep it simple. 1852 The scheme can be extended to PIM Hellos as well wherein we modify 1853 the holdtime sent in hellos towards the PWs. If an adjacency times 1854 out, PE can simulate a Hello and send it out towards the PW with a 1855 holdtime of 0. 1857 6 Security Considerations 1858 Security considerations provided in VPLS solution documents (i.e., 1859 [VPLS-LDP] and [VPLS-BGP) apply to this document as well. 1861 7 References 1862 7.1 Normative References 1864 7.2 Informative References 1865 [VPLS-LDP] Lasserre, M, et al. "Virtual Private LAN Services 1866 over MPLS", work in progress 1867 [VPLSD-BGP] Kompella, K, et al. "Virtual Private LAN Service", 1868 work in progress 1869 [L2VPN-FR] Andersson, L, et al. "L2VPN Framework", work in 1870 progress 1871 [PMP-RSVP-TE] Aggarwal, R, et al. "Extensions to RSVP-TE for Point 1872 to Multipoint TE LSPs", work in progress 1873 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 1874 RFC 1112, August 1989. 1875 [RFC2236] Fenner, W., "Internet Group Management Protocol, 1876 Version 2", RFC 2236, November 1997. 1877 [RFC3376] Cain, B., et al. "Internet Group Management 1878 Protocol, Version 3", RFC 3376, October 2002. 1879 [MAGMA-SNOOP] Christensen, M., et al. "Considerations for IGMP and 1880 MLD Snooping Switches", work in progress 1881 [PIM-DM] Deering, S., et al. "Protocol Independent Multicast 1882 Version 2 � Dense Mode Specification", draft-ietf- 1883 pim-v2-dm-03.txt, June 1999. 1884 [RFC2362] Estrin, D, et al. "Protocol Independent Multicast- 1885 Sparse Mode (PIM-SM): Protocol Specification", RFC 1886 2362, June 1998. 1887 [PIM-SSM] Holbrook, H., et al. "Source-Specific Multicast for 1888 IP", work in progress 1889 [BIDIR-PIM] Handley, M., et al. "Bi-directional Protocol 1890 Independent Multicast (BIDIR-PIM)", work in progress 1891 [MVPN-VPLS]] Aggarwal, R., et al. "Multicast in BGP/MPLS VPNs and 1892 VPLS", work in progress 1894 8 Authors' Addresses 1896 Yetik Serbest 1897 SBC Labs 1898 9505 Arboretum Blvd. 1899 Austin, TX 78759 1900 Yetik_serbest@labs.sbc.com 1902 Ray Qiu 1903 Alcatel North America 1904 701 East Middlefield Rd. 1905 Mountain View, CA 94043 1906 Ray.Qiu@alcatel.com 1908 Venu Hemige 1909 Alcatel North America 1910 701 East Middlefield Rd. 1911 Mountain View, CA 94043 1912 Venu.hemige@alcatel.com 1914 Rob Nath 1915 Riverstone Networks 1916 5200 Great America Parkway 1917 Santa Clara, CA 95054 1918 Rnath@riverstonenet.com 1920 Suresh Boddapati 1921 Alcatel North America 1922 701 East Middlefield Rd. 1923 Mountain View, CA 94043 1924 Suresh.boddapati@alcatel.com 1926 Sunil Khandekar 1927 Alcatel North America 1928 701 East Middlefield Rd. 1929 Mountain View, CA 94043 1930 Sunil.khandekar@alcatel.com 1932 Vach Kompella 1933 Alcatel North America 1934 701 East Middlefield Rd. 1935 Mountain View, CA 94043 1936 Vach.kompella@alcatel.com 1938 Marc Lasserre 1939 Riverstone Networks 1940 Marc@riverstonenet.com 1942 9 Intellectual Property Statement 1944 The IETF takes no position regarding the validity or scope of any 1945 Intellectual Property Rights or other rights that might be claimed to 1946 pertain to the implementation or use of the technology described in 1947 this document or the extent to which any license under such rights 1948 might or might not be available; nor does it represent that it has 1949 made any independent effort to identify any such rights. Information 1950 on the procedures with respect to rights in RFC documents can be 1951 found in BCP 78 and BCP 79. 1953 Copies of IPR disclosures made to the IETF Secretariat and any 1954 assurances of licenses to be made available, or the result of an 1955 attempt made to obtain a general license or permission for the use of 1956 such proprietary rights by implementers or users of this 1957 specification can be obtained from the IETF on-line IPR repository at 1958 http://www.ietf.org/ipr. 1960 The IETF invites any interested party to bring to its attention any 1961 copyrights, patents or patent applications, or other proprietary 1962 rights that may cover technology that may be required to implement 1963 this standard. Please address the information to the IETF at ietf- 1964 ipr@ietf.org. 1966 10 Full copyright statement 1968 Copyright (C) The Internet Society (2004). This document is subject 1969 to the rights, licenses and restrictions contained in BCP 78 and 1970 except as set forth therein, the authors retain all their rights. 1972 This document and the information contained herein are provided on an 1973 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1974 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1975 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1976 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1977 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1978 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.