idnits 2.17.1 draft-ietf-l2vpn-vpls-pim-snooping-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 55 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To achieve that, PIM-SM Snooping MUST not only forward multicast traffic for an (S,G) on the ports on which they snooped Joins(S,G)/ Joins(*,G), but also towards the upstream neighbor(s)). In other words, the ports on which the upstream neighbors are learnt must be added to the outgoing port list along with the ports on which Joins are snooped. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2013) is 3853 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (ref. 'PIM-SM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-11 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Layer 2 Virtual Private Networks O. Dornon 3 Internet-Draft J. Kotalwar 4 Intended status: Informational Alcatel-Lucent 5 Expires: April 11, 2014 V. Hemige 7 R. Qiu 8 Z. Zhang 9 Juniper Networks, Inc. 10 October 8, 2013 12 PIM Snooping over VPLS 13 draft-ietf-l2vpn-vpls-pim-snooping-05 15 Abstract 17 This document describes the procedures and recommendations for VPLS 18 PEs to facilitate replication of multicast traffic to only certain 19 ports (behind which there are interested PIM routers and/or IGMP 20 hosts) via PIM Snooping and PIM Proxy. 22 With PIM Snooping, PEs passively listen to certain PIM control 23 messages to build control and forwarding states while transparently 24 flooding those messages. With PIM Proxy, PEs do not flood PIM Join/ 25 Prune messages but only generate their own and send out of certain 26 ports, based on the control states built from downstream Join/Prune 27 messages. PIM Proxy is required when PIM Join suppression is enabled 28 on the CE devices and useful to reduce PIM control traffic in a VPLS 29 domain. 31 The document also describes PIM Relay, which can be viewed as light- 32 weight proxy, where all downstream Join/Prune messages are simply 33 forwarded out of certain ports but not flooded to avoid triggering 34 PIM Join suppression on CE devices. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on April 11, 2014. 59 Copyright Notice 61 Copyright (c) 2013 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Multicast Snooping in VPLS . . . . . . . . . . . . . . . . 5 78 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 79 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 80 2. PIM Snooping for VPLS . . . . . . . . . . . . . . . . . . . . 7 81 2.1. PIM protocol background . . . . . . . . . . . . . . . . . 7 82 2.2. General Rules for PIM Snooping in VPLS . . . . . . . . . . 8 83 2.2.1. Preserving Assert Trigger . . . . . . . . . . . . . . 8 84 2.3. Some Considerations for PIM Snooping . . . . . . . . . . . 9 85 2.3.1. Scaling . . . . . . . . . . . . . . . . . . . . . . . 9 86 2.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 2.3.3. PIM-SM (*,*,RP) . . . . . . . . . . . . . . . . . . . 10 88 2.4. PIM Snooping vs PIM Proxy . . . . . . . . . . . . . . . . 10 89 2.4.1. Differences between PIM Snooping, Relay and Proxy . . 10 90 2.4.2. PIM Control Message Latency . . . . . . . . . . . . . 11 91 2.4.3. When to Snoop and When to Proxy . . . . . . . . . . . 12 92 2.5. Discovering PIM Routers . . . . . . . . . . . . . . . . . 13 93 2.6. PIM-SM and PIM-SSM . . . . . . . . . . . . . . . . . . . . 14 94 2.6.1. Building PIM-SM Snooping States . . . . . . . . . . . 14 95 2.6.2. Explanation for per (S,G,N) states . . . . . . . . . . 17 96 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages . . . . . . 17 97 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages . . . . . . 19 98 2.6.5. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 21 99 2.6.6. Sending Join/Prune Messages Upstream . . . . . . . . . 21 100 2.7. Bidirectional-PIM (PIM-BIDIR) . . . . . . . . . . . . . . 22 101 2.8. Interaction with IGMP Snooping . . . . . . . . . . . . . . 23 102 2.9. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 2.9.1. Building PIM-DM Snooping States . . . . . . . . . . . 23 104 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine . 24 105 2.9.3. Triggering ASSERT election in PIM-DM . . . . . . . . . 24 106 2.10. PIM Proxy . . . . . . . . . . . . . . . . . . . . . . . . 24 107 2.10.1. Upstream PIM Proxy behavior . . . . . . . . . . . . . 24 108 2.11. Directly Connected Multicast Source . . . . . . . . . . . 25 109 2.12. Data Forwarding Rules . . . . . . . . . . . . . . . . . . 25 110 2.12.1. PIM-SM Data Forwarding Rules . . . . . . . . . . . . . 26 111 2.12.2. PIM-DM Data Forwarding Rules . . . . . . . . . . . . . 27 112 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 113 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 114 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 115 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 118 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 119 Appendix A. PIM-BIDIR Thoughts . . . . . . . . . . . . . . . . . 30 120 A.1. PIM-BIDIR Data Forwarding Rules . . . . . . . . . . . . . 30 121 Appendix B. Example Network Scenario . . . . . . . . . . . . . . 31 122 B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . . 32 123 B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . . 34 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 126 1. Introduction 128 In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices 129 provide a logical interconnect such that Customer Edge (CE) devices 130 belonging to a specific VPLS instance appear to be connected by a 131 single LAN. Forwarding Information Base for a VPLS instance is 132 populated dynamically by source MAC address learning. Once a unicast 133 MAC address is learned and associated with a particular Attachment 134 Circuit (AC) or PseudoWire (PW), a frame destined to that MAC address 135 only needs to be sent on that AC or PW. 137 For a frame not addressed to a known unicast MAC address, flooding 138 has to be used. This happen with the following so called BUM 139 traffic: 141 o B: The destination MAC address is a broadcast address, 143 o U: The destination MAC address is unknown (has not been learned), 145 o M: The destination MAC address is a multicast address. 147 Multicast frames are flooded because a PE cannot know where multicast 148 members reside. VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) 149 perform replication for multicast traffic at the ingress PE devices. 150 As stated in the VPLS Multicast Requirements draft [VPLS-MCAST-REQ], 151 there are two issues with VPLS Multicast today: 153 o A. Multicast traffic is replicated to non-member sites. 155 o B. Replication of PWs on shared physical path. 157 Issue A can be solved by Multicast Snooping - PEs learn sites with 158 multicast members by snooping multicast protocol control messages and 159 forward IP multicast traffic only to member sites. This documents 160 describes the procedures to achieve that when PIM is running between 161 the CE devices. Issue B is outside the scope of this document and 162 discussed in[VPLS-MCAST-TREES]. 164 While this document is in the context of VPLS, the procedures apply 165 to regular layer-2 switches interconnected by physical connections as 166 well. In that case, the PW related concept/procedures are not 167 applicable and that's all. 169 1.1. Multicast Snooping in VPLS 171 IGMP Snooping procedures described in[IGMP-SNOOP] make sure that IP 172 multicast traffic is only sent out of the following: 174 o Attachment Circuits (ACs) connecting to hosts that report related 175 group membership 177 o ACs connecting to routers 179 o PseudoWires (PWs) connecting to remote PEs that have the above 180 described ACs 182 Notice that traffic is always sent out of ports connecting to 183 routers, even those on which there are no snooped group memberships, 184 because IGMP Snooping alone can not determine if there are interested 185 receivers beyond those routers. To further restrict traffic sent to 186 those routers, PIM Snooping can be used, and this document describes 187 the procedures, including the rules when both IGMP and PIM are active 188 in a VPLS instance. 190 Note that for both IGMP and PIM, the term Snooping is used loosely, 191 referring to the fact that a layer-2 device peeks into layer-3 192 routing protocol messages to build relevant control and forwarding 193 states. Depending on how the control messages are handled 194 (transparently flooded, selectively forwarded, or consumed and then 195 regenerated), the procedure/process may be called Snooping or Proxy 196 in different contexts. 198 Unless explicitly noted, the procedures in this document are used for 199 either PIM Snooping or PIM Proxy, and we will largely refer to PIM 200 "Snooping" in this document. The PIM Proxy specific procedures are 201 described in Section 2.6.6. Differences that need to be observed 202 while implementing one or the other and recommendations on which 203 method to employ in different scenarios are noted in section 204 Section 2.4. 206 This document also describes PIM Relay, which can be viewed as light- 207 weight Proxy. Unless explicitly noted, in the rest of the document 208 Proxy implicitly includes Relay as well. 210 1.2. Assumptions 212 The document assumes that the reader has a good understanding of the 213 PIM protocols. The text in this draft is written in the same style 214 as the PIM RFCs to help correlate the concepts and to make it easier 215 to follow. In order to avoid replicating the text relating to PIM 216 protocol handling here, this draft cross references into definitions 217 of macros and procedures from the PIM RFCs, and assumes that the user 218 will infer such detail from those PIM RFCs. Deviations in protocol 219 handling specific to PIM Snooping are specified in this draft. 221 1.3. Definitions 223 There are several definitions referenced in this document that are 224 well described in the PIM RFCs [PIM-SM], PIM-BIDIR, PIM-DM]. The 225 following definitions and abbreviations are used throughout this 226 document: 228 o A port is defined as either an attachment circuit (AC) or a 229 Pseudo-Wire (PW). 231 o When we say a PIM message is 'received' on a port, it means that a 232 PIM Snooping PE snooped the PIM message. 234 Abbreviations used in the document: 236 o S: IP Address of the Multicast Source. 238 o G: IP Address of the Multicast Group. 240 o N: Upstream Neighbor field in a Join/Prune/Graft message. 242 o Rport(N): Port on which neighbor N is learnt. 244 Other definitions are explained in the sections where they are 245 introduced. 247 2. PIM Snooping for VPLS 249 2.1. PIM protocol background 251 PIM is a multicast routing protocol running between routers, which 252 are CE devices in a VPLS. PIM shares many of the common 253 characteristics of a routing protocol, such as discovery messages 254 (e.g., neighbor discovery using Hello messages), topology information 255 (e.g., multicast tree), and error detection and notification (e.g., 256 dead timer and designated router election). PIM does not participate 257 in exchange of unicast routing databases, but it uses the unicast 258 routing table to provide reverse path information for building 259 multicast trees. There are a few variants of PIM. In [PIM-DM], 260 multicast data is pushed towards the members similar to broadcast 261 mechanism but routers without attached receivers will prune back 262 towards the source. Unlike PIM-DM, other PIM flavors (PIM-SM 263 [PIM-SM], PIM-SSM [PIM-SSM], and PIM-BIDIR [PIM-BIDIR]) employs a 264 pull methodology via explicit joins instead of push technique. 266 PIM routers periodically exchange Hello messages to discover and 267 maintain stateful sessions with neighbors. After neighbors are 268 discovered, PIM routers can signal their intentions to join or prune 269 specific multicast groups. This is accomplished by having downstream 270 routers send an explicit Join/Prune message (for the sake of 271 generalization, consider Graft messages for PIM-DM as Join messages) 272 to the upstream routers. The Join/Prune message can be group 273 specific (*,G) or group and source specific (S,G). 275 2.2. General Rules for PIM Snooping in VPLS 277 The following rules for the correct operation of PIM snooping MUST be 278 followed. 280 o PIM Snooping MUST NOT affect the operation of customer layer-2 281 protocols (e.g., BPDUs) or layer-3 protocols. 283 o PIM messages and multicast data traffic forwarded by PEs MUST 284 follow the split-horizon rule for mesh PWs. 286 o PIM snooping states in a PE MUST be per VPLS instance. 288 o PIM assert triggers MUST be preserved to the extent necessary to 289 avoid sending duplicate traffic to the same PE (see 290 Section 2.2.1). 292 2.2.1. Preserving Assert Trigger 294 In PIM-SM/DM, there are scenarios where multiple routers could be 295 forwarding the same multicast traffic on a LAN. When this happens, 296 using PIM Assert Election process by sending PIM Assert Messages, 297 routers ensure that only the Assert Winner forwards traffic on the 298 LAN. The Assert Election is a data driven event and happens only if 299 a router sees traffic on the interface to which it should be 300 forwarding the traffic. In the case of VPLS with snooping, two 301 routers may forward the same flow at the same time but each copy may 302 reach different set of PEs, and that is acceptable from the point of 303 view of avoiding duplicate traffic. If the two copies may reach the 304 same PE then the sending routers must be able to see each other's 305 traffic, in order to trigger Assert Election and stop duplicate 306 traffic. 308 To achieve that, PIM-SM Snooping MUST not only forward multicast 309 traffic for an (S,G) on the ports on which they snooped Joins(S,G)/ 310 Joins(*,G), but also towards the upstream neighbor(s)). In other 311 words, the ports on which the upstream neighbors are learnt must be 312 added to the outgoing port list along with the ports on which Joins 313 are snooped. 315 Similarly, PIM-DM Snooping SHOULD make sure that asserts can be 316 triggered (Section 2.9.3). 318 The above logic needs to be facilitated without breaking VPLS Split 319 Horizon Rules. i.e. traffic should not be forwarded on the port on 320 which it was received, and traffic arriving on a PW MUST NOT be 321 forwarded onto other PW(s). 323 2.3. Some Considerations for PIM Snooping 325 The PIM Snooping solution described here requires a PE to examine and 326 operate on only PIM Hello and PIM Join/Prune packets. The PE does 327 not need to examine any other PIM packets. 329 Most of the procedures in PIM Snooping in the handling of PIM Hellos 330 and PIM Join/Prune packets are very similar to that of a PIM Router. 332 However, the PE does not need to have any routing tables like is 333 required in PIM Multicast Routing. It knows how to forward Join/ 334 Prunes by looking at the Upstream Neighbor field in the Join/Prune 335 packets. 337 The PE does not need to know about Rendezvous Points (RP) and does 338 not have to maintain any RP Set. All that is transparent to a PIM 339 Snooping PE. 341 In the following sub-sections, we list some considerations and 342 observations for the implementation of PIM Snooping in VPLS. 344 2.3.1. Scaling 346 Snooping needs to be employed on ACs at the downstream PEs to prevent 347 traffic from being sent out of ACs unnecessarily. Snooping 348 techniques can also be employed on PWs at the upstream PEs to prevent 349 traffic from being sent to PEs unnecessarily. This may work well for 350 small to medium scale deployments. However, if there are a large 351 number of VPLS instances with a large number of PEs per instances, 352 then the amount of snooping required at the upstream PEs can 353 overwhelm the upstream PEs. 355 There are two methods to reduce the burden on the upstream PEs. One 356 is to use PIM Proxy as described in Section 2.6.6, to reduce the 357 control messages forwarded by a PE. The other is not to snoop on the 358 PWs at all, but PEs signal the snooped states to other PEs out of 359 band via BGP, as described in [VPLS-MCAST-TREES]. In this document, 360 it is assumed that Snooping is performed on PWs. 362 2.3.2. IPv6 364 In VPLS, PEs forward Ethernet frames received from CEs and as such 365 are agnostic of the layer-3 protocol used by the CEs. However, as an 366 IGMP and PIM snooping PE, the PE would have to look deeper into the 367 IP and IGMP/PIM packets and build snooping state based on that. The 368 PIM Protocol specifications handle both IPv4 and IPv6. The 369 specification for PIM Snooping in this draft can be applied to both 370 IPv4 and IPv6 payloads. 372 2.3.3. PIM-SM (*,*,RP) 374 This draft does not address (*,*,RP) states in the VPLS network. 375 Although [PIM-SM] specifies that routers MUST support (*,*,RP) 376 states, there are very few implementations that actually support it 377 in actual deployments, and it is being removed from the PIM protocol 378 in its ongoing advancement process in IETF. Given that, this draft 379 omits the specification relating to (*,*,RP) support. 381 2.4. PIM Snooping vs PIM Proxy 383 The document has previously alluded to PIM Snooping/Relay/Proxy. 384 Details on the PIM Proxy/Relay solution are discussed in 385 Section 2.6.6. In this section, a brief description and comparison 386 are given. 388 2.4.1. Differences between PIM Snooping, Relay and Proxy 390 Differences between PIM Snooping and Proxy/Relay can be summarized as 391 the following: 393 +----------------------+---------------------+-----------------------+ 394 | PIM Snooping | PIM Relay | PIM Proxy | 395 +======================|=====================|=======================+ 396 | Join/Prune messages | Join/Prune messages | Join/Prune messages | 397 | snooped and flooded | snooped; forwarded | consumed. Regenerated | 398 | everywhere | as is out of certain| ones sent out of | 399 | | upstream ports | certain upstream ports| 400 +----------------------+---------------------+-----------------------+ 401 | No PIM packets | No PIM packets | New Join/Prune | 402 | generated. | generated | messages generated | 403 +----------------------+---------------------+-----------------------+ 404 | CE Join Suppression | CE Join Suppression | CE Join Suppression | 405 | not allowed | allowed | allowed | 406 +----------------------+---------------------+-----------------------+ 408 Note that the differences apply only to PIM Join/Prune messages. PIM 409 Hello messages are snooped and flooded in all cases. 411 Other than the above differences, most of the procedures are common 412 to PIM Snooping and PIM Proxy/Relay, unless specifically stated 413 otherwise. 415 Pure PIM Snooping PEs simply snoop on PIM packets as they are being 416 forwarded in the VPLS. As such they truly provide transparent LAN 417 services since no customer packets are modified or consumed or new 418 packets introduced in the VPLS. It is also simpler to implement than 419 PIM Proxy. However for PIM Snooping to work correctly, it is a 420 requirement that CE routers MUST disable Join suppression in the 421 VPLS. 423 Given that a large number of existing CE deployments do not support 424 disabling of Join suppression and given the operational complexity 425 for a provider to manage disabling of Join suppression in the VPLS, 426 it becomes a difficult solution to deploy. Another disadvantage of 427 PIM Snooping is that it does not scale as well as PIM Proxy. If 428 there are a large number of CEs in a VPLS, then every CE will see 429 every other CE's Join/Prune messages. 431 PIM Proxy/Relay has the advantage that it does not require Join 432 suppression to be disabled in the VPLS. Multicast as a VPLS service 433 can be very easily provided without requiring any changes on the CE 434 routers. PIM Proxy/Relay helps scale VPLS Multicast since Join/Prune 435 messages are only sent to certain upstream ports instead of flooded, 436 and in case of full Proxy (vs. Relay) the PEs intelligently generate 437 only one Join/Prune message for a given flow. 439 PIM Proxy however loses the transparency argument since Join/Prunes 440 could get modified or even consumed at a PE. Also, new packets could 441 get introduced in the VPLS. However, this loss of transparency is 442 limited to PIM Join/Prune packets. It is in the interest of 443 optimizing multicast in the VPLS and helping a VPLS network scale 444 much better. Data traffic will still be completely transparent. 446 2.4.2. PIM Control Message Latency 448 A PIM Snooping/Proxy/Relay PE snoops on PIM Hello packets while 449 transparently flooding them in the VPLS. As such there is no latency 450 introduced by the VPLS in the delivery of PIM Hello packets to remote 451 CEs in the VPLS. 453 A PIM Snooping PE snoops on PIM Join/Prune packets while 454 transparently flooding them in the VPLS. There is no latency 455 introduced by the VPLS in the delivery of PIM Join/Prune packets when 456 PIM Snooping is employed. 458 A PIM Proxy/Relay PE does not simply flood PIM Join/Prune packets. 459 This can result in additional latency for a downstream CE to receive 460 multicast traffic after it has sent a Join. When a downstream CE 461 prunes a multicast stream, the traffic should stop flowing to the CE 462 with no additional latency introduced by the VPLS. 464 Performing only proxy of Join/Prune and not Hello messages keeps the 465 PE behavior very similar to that of a PIM router without introducing 466 too much additional complexity. It keeps the PIM Proxy solution 467 fairly simple. Since Join/Prunes are forwarded by a PE along the 468 slow-path and all other PIM packet types are forwarded along the 469 fast-path, it is very likely that packets forwarded along the fast- 470 path will arrive "ahead" of Join/Prune packets at a CE router (note 471 the stress on the fact that fast-path messages will never arrive 472 after Join/Prunes). Of particular importance are Hello packets sent 473 along the fast-path. We can construct a variety of scenarios 474 resulting in out of order delivery of Hellos and Join/Prune messages. 475 However, there should be no deviation from normal expected behavior 476 observed at the CE router receiving these messages out of order. 478 2.4.3. When to Snoop and When to Proxy 480 From the above descriptions, factors that affect the choice of 481 Snooping/Relay/Proxy include: 483 o Whether CEs do Join Suppression or not 485 o Whether Join/Prune latency is critical or not 487 o Whether the scale of PIM protocol message/states in a VPLS 488 requires the scaling benefit of Proxy 490 Of the above factors, Join Suppression is the hard one - pure 491 Snooping can only be used when Join Suppression is disabled on all 492 CEs. The latency associated with Relay/Proxy is implementation 493 dependent and may not be a concern at all with a particular 494 implementation. The scaling benefit may not be important either, in 495 that on a real LAN with Explicit Tracking (ET) a PIM router will need 496 to receive and process all PIM Join/Prune messages as well. 498 A PIM router indicates that Join Suppression is disabled if the T-bit 499 is set in the LAN Prune Delay option of its Hello message. If all 500 PIM routers on a LAN set the T-bit, Explicit Tracking is possible, 501 allowing an upstream router to track all the downstream neighbors 502 that have Join states for any (S,G) or (*,G). That has two benefits: 504 o No need for PrunePending process - the upstream router may 505 immediately stop forwarding data when it receives a Prune from the 506 last downstream neighbor, and immediately prune to its upstream if 507 that's for the last downstream interface. 509 o For management purpose, the upstream router knows exactly which 510 downstream routers exist for a particular Join State. 512 While full Proxy can be used with or without Join Suppression on CEs 513 and does not interfere with an upstream CE's bypass of PrunePending 514 process, it does proxy all its downstream CEs as a single one to the 515 upstream, removing the second benefit mentioned above. 517 Therefore, the general rule is that if Join Suppression is enabled on 518 CEs then Proxy or Relay MUST be used and if Suppression is known to 519 be disabled on all CEs then either Snooping, Relay, or Proxy MAY be 520 used while Snooping or Relay SHOULD be used. 522 An implementation MAY choose dynamic determination of which mode to 523 use, through the tracking of the above mentioned T-bit in all snooped 524 PIM Hello messages, or MAY simply require static provisioning. 526 2.5. Discovering PIM Routers 528 A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs. 529 i.e. the PE transparently floods the PIM Hello while snooping on it. 530 PIM Hellos are used by the snooping PE to discover PIM routers and 531 their characteristics. 533 For each neighbor discovered by a PE, it includes an entry in the PIM 534 Neighbor Database with the following fields: 536 o Layer 2 encapsulation for the Router sending the PIM Hello. 538 o IP Address and address family of the Router sending the PIM Hello. 540 o Port (AC / PW) on which the PIM Hello was received. 542 o Hello TLVs 544 The PE should be able to interpret and act on Hello TLVs currently 545 defined in the PIM RFCs. The TLVs of particular interest in this 546 document are: 548 o Hello-Hold-Time 550 o Tracking Support 551 o DR Priority 553 Please refer to [PIM-SM] for a list of the Hello TLVs. When a PIM 554 Hello is received, the PE MUST reset the neighbor-expiry-timer to 555 Hello-Hold-Time. If a PE does not receive a Hello message from a 556 router within Hello-Hold-Time, the PE MUST remove that neighbor from 557 its PIM Neighbor Database. If a PE receives a Hello message from a 558 router with Hello-Hold-Time value set to zero, the PE MUST remove 559 that router from the PIM snooping state immediately. 561 From the PIM Neighbor Database, a PE MUST be able to use the 562 procedures defined in [PIM-SM] to identify the PIM Designated Router 563 in the VPLS instance. It should also be able to determine if 564 Tracking Support is active in the VPLS instance. 566 2.6. PIM-SM and PIM-SSM 568 The key characteristic of PIM-SM and PIM-SSM is explicit join 569 behavior. In this model, multicast traffic is only forwarded to 570 locations that specifically request it. The root node of a tree is 571 the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or 572 the first hop router that is directly connected to the multicast 573 source in the case of a shortest path tree. All the procedures 574 described in this section apply to both PIM-SM and PIM-SSM, except 575 for the fact that there is no (*,G) state in PIM-SSM. 577 2.6.1. Building PIM-SM Snooping States 579 PIM-SM and PIM-SSM Snooping states are built by snooping on the 580 PIM-SM Join/Prune messages received on AC/PWs. 582 The downstream state machine of a PIM-SM snooping PE very closely 583 resembles the downstream state machine of PIM-SM routers. The 584 downstream state consists of: 586 Per downstream (Port, *, G): 588 o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 589 Pending" (PP) } 591 Per downstream (Port, *, G, N): 593 o Prune Pending Timer (PPT(N)) 595 o Join Expiry Timer (ET(N)) 597 Per downstream (Port, S, G): 599 o DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 600 Pending" (PP) } 602 Per downstream (Port, S, G, N): 604 o Prune Pending Timer (PPT(N)) 606 o Join Expiry Timer (ET(N)) 608 Per downstream (Port, S, G, rpt): 610 o DownstreamJPRptState: One of { "NoInfo" (NI), "Pruned" (P), "Prune 611 Pending" (PP) } 613 Per downstream (Port, S, G, rpt, N): 615 o Prune Pending Timer (PPT(N)) 617 o Join Expiry Timer (ET(N)) 619 Where S is the address of the multicast source, G is the Group 620 address and N is the upstream neighbor field in the Join/Prune 621 message. Notice that unlike on PIM-SM routers where PPT and ET are 622 per (Interface, S, G), PIM Snooping PEs have to maintain PPT and ET 623 per (Port, S, G, N). The reasons for this are explained in 624 Section 2.6.2. 626 Apart from the above states, we define the following state 627 summarization macros. 629 UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on 630 any port with upstream neighbor N and ET(N) is active, then N is 631 added to UpstreamNeighbors(*,G). This set is used to determine if a 632 Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent 633 upstream. 635 UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on 636 any port with upstream neighbor N and ET(N) is active, then N is 637 added to UpstreamNeighbors(S,G). This set is used to determine if a 638 Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent 639 upstream. 641 UpstreamPorts(*,G): This is the set of all Rport(N) ports where N is 642 in the set UpstreamNeighbors(*,G). Multicast Streams forwarded using 643 a (*,G) match MUST be forwarded to these ports in addition to 644 downstream ports. So UpstreamPorts(*,G) MUST be added to 645 OutgoingPortList(*,G). 647 UpstreamPorts(S,G): This is the set of all Rport(N) ports where N is 648 in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added 649 to OutgoingPortList(S,G). 651 InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) 652 and UpstreamPorts(*,G). 654 UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes true, then 655 this set is set to UpstreamPorts(*,G). Otherwise, this set is empty. 656 UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to 657 OutgoingPortList(S,G). 659 UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) 660 and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and 661 (*,G) Join/Prune messages MUST be sent to a subset of 662 UpstreamPorts(G) as specified in Section 2.6.6.1. 664 PWPorts: This is the set of all PWs. 666 OutgoingPortList(*,G): This is the set of all ports to which traffic 667 needs to be forwarded on a (*,G) match. 669 OutgoingPortList(S,G): This is the set of all ports to which traffic 670 needs to be forwarded on an (S,G) match. 672 See Section 2.12 on Data Forwarding Rules for the specification on 673 how OutgoingPortList is calculated. 675 NumETsActive(Port,*,G): Number of (Port,*,G,N) entries that have 676 Expiry Timer running. This macro keeps track of the number of 677 Join(*,G)s that are received on this Port with different upstream 678 neighbors. 680 NumETsActive(Port,S,G): Number of (Port,S,G,N) entries that have 681 Expiry Timer running. This macro keeps track of the number of 682 Join(S,G)s that are received on this Port with different upstream 683 neighbors. 685 RpfVectorTlvs(*,G): RPF Vectors [RPF-VECTOR] are TLVs that may be 686 present in received Join(*,G) messages. If present, they must be 687 copied to RpfVectorTlvs(*,G). 689 RpfVectorTlvs(S,G): RPF Vectors [RPF-VECTOR] are TLVs that may be 690 present in received Join(S,G) messages. If present, they must be 691 copied to RpfVectorTlvs(S,G). 693 Since there are a few differences between the downstream state 694 machines of PIM-SM Routers and PIM-SM snooping PEs, we specify the 695 details of the downstream state machine of PIM-SM snooping PEs at the 696 risk of repeating most of the text documented in [PIM-SM]. 698 2.6.2. Explanation for per (S,G,N) states 700 In PIM Routing protocols, states are built per (S,G). On a router, 701 an (S,G) has only one RPF-Neighbor. However, a PIM Snooping PE does 702 not have the Layer 3 routing information available to the routers in 703 order to determine the RPF-Neighbor for a multicast flow. It merely 704 discovers it by snooping the Join/Prune message. A PE could have 705 snooped on two or more different Join/Prune messages for the same 706 (S,G) that could have carried different Upstream-Neighbor fields. 707 This could happen during transient network conditions or due to dual- 708 homed sources. A PE cannot make assumptions on which one to pick, 709 but instead must facilitate the CE routers decide which Upstream 710 Neighbor gets elected the RPF-Neighbor. And for this purpose, the PE 711 will have to track downstream and upstream Join/Prune per (S,G,N). 713 2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages 715 A Join(*,G) or Prune(*,G) is considered "received" if the following 716 conditions are met: 718 o The port on which it arrived is not Rport(N) where N is the 719 upstream-neighbor N of the Join/Prune(*,G), or, 721 o if both RPort(N) and the arrival port are PWs, then there exists 722 at least one other (*,G,Nx) or (Sx,G,Nx) state with an AC 723 UpstreamPort. 725 For simplicity, the case where both RPort(N) and the arrival port are 726 PWs is referred to as PW-only Join/Prune in this document. The PW- 727 only Join/Prune handling is so that the RPort(N) PW can be added to 728 the related forwarding entries' OutgoingPortList to trigger Assert, 729 but that is only needed for those states with AC UpstreamPort. Note 730 that in PW-only case, it is OK for the arrival port and RPort(N) to 731 be the same. See Appendix Appendix B for examples. 733 When a router receives a Join(*,G) or a Prune(*,G) with upstream 734 neighbor N, it must process the message as defined in the state 735 machine below. Note that the macro computations of the various 736 macros resulting from this state machine transition is exactly as 737 specified in the PIM-SM RFC [PIM-SM]. 739 We define the following per-port (*,G,N) macro to help with the state 740 machine below. 742 Figure 1 : Downstream per-port (*,G) state machine in tabular form 743 +---------------++----------------------------------------+ 744 | || Previous State | 745 | ++------------+--------------+------------+ 746 | Event ||NoInfo (NI) | Join (J) | Prune-Pend | 747 +---------------++------------+--------------+------------+ 748 | Receive ||-> J state | -> J state | -> J state | 749 | Join(*,G) || Action | Action | Action | 750 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 751 +---------------++------------+--------------+------------+ 752 |Receive || - | -> PP state | -> PP state| 753 |Prune(*,G) and || | Start PPT(N) | | 754 |NumETsActive<=1|| | | | 755 +---------------++------------+--------------+------------+ 756 |Receive || - | -> J state | - | 757 |Prune(*,G) and || | Start PPT(N) | | 758 |NumETsActive>1 || | | | 759 +---------------++------------+--------------+------------+ 760 |PPT(N) expires || - | -> J state | -> NI state| 761 | || | Action | Action | 762 | || | PPTExpiry(N) |PPTExpiry(N)| 763 +---------------++------------+--------------+------------+ 764 |ET(N) expires || - | -> NI state | -> NI state| 765 |and || | Action | Action | 766 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)| 767 +---------------++------------+--------------+------------+ 768 |ET(N) expires || - | -> J state | - | 769 |and || | Action | | 770 |NumETsActive>1 || | ETExpiry(N) | | 771 +---------------++------------+--------------+------------+ 773 Action RxJoin(N): 775 If ET(N) is not already running, then start ET(N). Otherwise 776 restart ET(N). If N is not already in UpstreamNeighbors(*,G), 777 then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with 778 upstream neighbor N to be forwarded upstream. If there are RPF 779 Vector TLVs in the received (*,G) message and if they are 780 different from the recorded RpfVectorTlvs(*,G), then copy them 781 into RpfVectorTlvs(*,G). 783 Action PPTExpiry(N): 785 Same as Action ETExpiry(N) below, plus Send a Prune-Echo(*,G) with 786 upstream-neighbor N on the downstream port. 788 Action ETExpiry(N): 790 Disable timers ET(N) and PPT(N). Delete neighbor state 791 (Port,*,G,N). If there are no other (Port,*,G) states with 792 NumETsActive(Port,*,G) > 0, transition DownstreamJPState to 793 NoInfo. If there are no other (Port,*,G,N) state (different ports 794 but for the same N), remove N from UpstreamPorts(*,G) - this also 795 serves as a trigger for US FSM (JoinDesired(*,G,N) becomes FALSE). 797 2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages 799 A Join(S,G) or Prune(S,G) is considered "received" if the following 800 conditions are met: 802 o The port on which it arrived is not Rport(N) where N is the 803 upstream-neighbor N of the Join/Prune(S,G), or, 805 o if both RPort(N) and the arrival port are PWs, then there exists 806 at least one other (*,G,Nx) or (S,G,Nx) state with an AC 807 UpstreamPort. 809 For simplicity, the case where both RPort(N) and the arrival port are 810 PWs is referred to as PW-only Join/Prune in this document. The PW- 811 only Join/Prune handling is so that the RPort(N) PW can be added to 812 the related forwarding entries' OutgoingPortList to trigger Assert, 813 but that is only needed for those states with AC UpstreamPort. See 814 Appendix Appendix B for examples. 816 When a router receives a Join(S,G) or a Prune(S,G) with upstream 817 neighbor N, it must process the message as defined in the state 818 machine below. Note that the macro computations of the various 819 macros resulting from this state machine transition is exactly as 820 specified in the PIM-SM RFC [PIM-SM]. 822 Figure 2: Downstream per-port (S,G) state machine in tabular form 823 +---------------++----------------------------------------+ 824 | || Previous State | 825 | ++------------+--------------+------------+ 826 | Event ||NoInfo (NI) | Join (J) | Prune-Pend | 827 +---------------++------------+--------------+------------+ 828 | Receive ||-> J state | -> J state | -> J state | 829 | Join(S,G) || Action | Action | Action | 830 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 831 +---------------++------------+--------------+------------+ 832 |Receive || - | -> PP state | -> PP state| 833 |Prune (S,G) and|| | Start PPT(N) | | 834 |NumETsActive<=1|| | | | 835 +---------------++------------+--------------+------------+ 836 |Receive || - | -> J state | - | 837 |Prune(S,G) and || | Start PPT(N) | | 838 NumETsActive>1 || | | | 839 +---------------++------------+--------------+------------+ 840 |PPT(N) expires || - | -> J state | -> NI state| 841 | || | Action | Action | 842 | || | PPTExpiry(N) |PPTExpiry(N)| 843 +---------------++------------+--------------+------------+ 844 |ET(N) expires || - | -> NI state | -> NI state| 845 |and || | Action | Action | 846 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)| 847 +---------------++------------+--------------+------------+ 848 |ET(N) expires || - | -> J state | - | 849 |and || | Action | | 850 |NumETsActive>1 || | ETExpiry(N) | | 851 +---------------++------------+--------------+------------+ 853 Action RxJoin(N): 855 If ET(N) is not already running, then start ET(N). Otherwise, 856 restart ET(N). 858 If N is not already in UpstreamNeighbors(S,G), then add N to 859 UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream 860 neighbor N to be forwarded upstream. If there are RPF Vector TLVs 861 in the received (S,G) message and if they are different from the 862 recorded RpfVectorTlvs(S,G), then copy them into 863 RpfVectorTlvs(S,G). 865 Action PPTExpiry(N): 867 Same as Action ETExpiry(N) below, plus Send a Prune-Echo(S,G) with 868 upstream-neighbor N on the downstream port. 870 Action ETExpiry(N): 872 Disable timers ET(N) and PPT(N). Delete neighbor state 873 (Port,S,G,N). If there are no other (Port,S,G) states with 874 NumETsActive(Port,S,G) > 0, transition DownstreamJPState to 875 NoInfo. If there are no other (Port,S,G,N) state (different ports 876 but for the same N), remove N from UpstreamPorts(S,G) - this also 877 serves as a trigger for US FSM (JoinDesired(S,G,N) becomes FALSE). 879 2.6.5. Receiving (S,G,rpt) Join/Prune Messages 881 A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on 882 which it was received is not also the port on which the upstream- 883 neighbor N of the Join/Prune(S,G,rpt) was learnt. 885 While it is important to ensure that the (S,G) and (*,G) state 886 machines allow for handling per (S,G,N) states, it is not as 887 important for (S,G,rpt) states. It suffices to say that the 888 downstream (S,G,rpt) state machine is the same as what is defined in 889 section 4.5.4 of the PIM-SM RFC [PIM-SM]. 891 2.6.6. Sending Join/Prune Messages Upstream 893 This section applies only to a PIM Proxy/Relay PE and not to a PIM 894 Snooping PE. 896 A full PIM Proxy (not Relay) PE MUST implement the Upstream FSM for 897 which the procedures are similar to what is defined in section 4.5.6 898 of [PIM-SM]. 900 For the purposes of the Upstream FSM, a Join or Prune message with 901 upstream neighbor N is "seen" on a PIM Snooping PE if the port on 902 which the message was received is also Rport(N), and the port is an 903 AC. The AC requirement is needed because a Join received on the 904 Rport(N) PW must not suppress this PE's Join on that PW. 906 A PIM Relay PE does not implement the Upstream FSM. It simply 907 forwards received Join/Prune messages out of the same set of upstream 908 ports as in the PIM Proxy case. 910 In order to correctly facilitate assert among the CE routers, such 911 Join/Prunes need to sent not only towards the upstream neighbor, but 912 also on certain PWs as described below. 914 If RpfVectorTlvs(*,G) is not empty, then it must be encoded in a 915 Join(*,G) message sent upstream. 917 If RpfVectorTlvs(S,G) is not empty, then it must be encoded in a 918 Join(S,G) message sent upstream. 920 2.6.6.1. Where to send Join/Prune messages 922 The following rules apply, to both forwarded (in case of PIM Relay), 923 refresh and triggered (in case of PIM Proxy) (S,G)/(*,G) Join/Prune 924 messages. 926 o The upstream neighbor field in the Join/Prune to be sent is set to 927 the N in the corresponding Upstream FSM. 929 o if Rport(N) is an AC, send the message to Rport(N). 931 o Additionally, if OutgoingPortList(X,G,N) contains at lease one AC, 932 then the message MUST be sent to at least all the PWs in 933 UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for 934 (S,G)). Alternatively, the message MAY be sent to all PWs. 936 Sending to a subset of PWs as described above guarantees that if 937 traffic (of the same flow) from two upstream routers were to reach 938 this PE, then the two routers will receive from each other, 939 triggering assert. 941 Sending to all PWs guarantees that if two upstream routers both send 942 traffic for the same flow (even if it is to different sets of 943 downstream PEs), then they'll receive from each other, triggering 944 assert. 946 2.7. Bidirectional-PIM (PIM-BIDIR) 948 PIM-BIDIR is a variation of PIM-SM. The main differences between 949 PIM-SM and Bidirectional-PIM are as follows: 951 o There are no source-based trees, and source-specific multicast is 952 not supported (i.e., no (S,G) states) in PIM- BIDIR. 954 o Multicast traffic can flow up the shared tree in PIM-BIDIR. 956 o To avoid forwarding loops, one router on each link is elected as 957 the Designated Forwarder (DF) for each RP in PIM-BIDIR. 959 The main advantage of PIM-BIDIR is that it scales well for many-to- 960 many applications. However, the lack of source-based trees means 961 that multicast traffic is forced to remain on the shared tree. 963 As described in [PIM-BIDIR], parts of a PIM-BIDIR enabled network may 964 forward traffic without exchanging Join/Prune messages, for instance 965 between DF's and the RPL. 967 As the described procedures for Pim snooping rely on the presence of 968 Join/Prune messages, enabling Pim snooping on PIM-BIDIR networks 969 could break the PIM-BIDIR functionality. Deploying Pim snooping on 970 PIM-BIDIR enabled networks will require some further study. Some 971 thoughts are gathered in Appendix A. 973 2.8. Interaction with IGMP Snooping 975 Whenever IGMP Snooping is enabled in conjunction with PIM Snooping in 976 the same VPLS instance the PE SHOULD follow these rules: 978 o To maintain the list of multicast routers and ports on which they 979 are attached, the PE SHOULD NOT use the rules as described in 980 RFC4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered 981 by PIM Snooping . This list SHOULD then be used to apply the 982 forwarding rule as described in 2.1.1.(1) of RFC4541 [IGMP-SNOOP]. 984 o If the PE supports proxy-reporting, an IGMP membership learned 985 only on a port to which a PIM neighbor is attached but not 986 elsewhere SHOULD NOT be included in the summarized upstream report 987 sent to that port. 989 2.9. PIM-DM 991 The characteristics of PIM-DM is flood and prune behavior. Shortest 992 path trees are built as a multicast source starts transmitting. 994 2.9.1. Building PIM-DM Snooping States 996 PIM-DM Snooping states are built by snooping on the PIM-DM Join, 997 Prune, Graft and State Refresh messages received on AC/PWs and State- 998 Refresh Messages sent on AC/PWs. By snooping on these PIM-DM 999 messages, a PE builds the following states per (S,G,N) where S is the 1000 address of the multicast source, G is the Group address and N is the 1001 upstream neighbor to which Prunes/Grafts are sent by downstream CEs: 1003 Per PIM (S,G,N): 1005 Port PIM (S,G,N) Prune State: 1007 * DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" 1008 (P), "PrunePending" (PP)} 1010 * Prune Pending Timer (PPT) 1011 * Prune Timer (PT) 1013 * Upstream Port (valid if the PIM(S,G,N) Prune State is 1014 "Pruned"). 1016 2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine 1018 The downstream per-port PIM(S,G,N) state machine is as defined in 1019 section 4.4.2 of [PIM-DM] with a few changes relevant to PIM 1020 Snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of 1021 PIM-Snooping please be aware that the downstream states are built per 1022 (S, G, N, Downstream-Port} in PIM-Snooping and not per {Downstream- 1023 Interface, S, G} as in a PIM-DM router. As noted in the previous 1024 Section 2.9.1, the states (DownstreamPState) and timers (PPT and PT) 1025 are per (S,G,N,P). 1027 2.9.3. Triggering ASSERT election in PIM-DM 1029 Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all 1030 routers unless explicitly pruned. Since PIM-DM routers do not prune 1031 on non-RPF interfaces, PEs should typically not receive Prunes on 1032 Rport(RPF-neighbor). So the asserting routers should typically be in 1033 pim_oiflist(S,G). In most cases, assert election should occur 1034 naturally without any special handling since data traffic will be 1035 forwarded to the asserting routers. 1037 However, there are some scenarios where a prune might be received on 1038 a port which is also an upstream port (UP). If we prune the port 1039 from pim_oiflist(S,G), then it would not be possible for the 1040 asserting routers to determine if traffic arrived on their downstream 1041 port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) 1042 so that data traffic flows to the UP ports. 1044 2.10. PIM Proxy 1046 As noted earlier, PIM Snooping will work correctly only if Join 1047 Suppression is disabled in the VPLS. If Join Suppression is enabled 1048 in the VPLS, then PEs MUST do PIM Proxy/Relay for VPLS Multicast to 1049 work correctly. This section applies specifically to the full Proxy 1050 case and not Relay. 1052 2.10.1. Upstream PIM Proxy behavior 1054 A PIM Proxy PE consumes Join/Prune messages and regenerates PIM Join/ 1055 Prune messages to be sent upstream by implementing Upstream FSM as 1056 specified in the PIM RFC. This is the only difference from PIM 1057 Relay. 1059 The source IP address in PIM packets sent upstream SHOULD be the 1060 address of a PIM downstream neighbor in the corresponding join/prune 1061 state. The address picked MUST NOT be the upstream neighbor field to 1062 be encoded in the packet. The layer 2 encapsulation for the selected 1063 source IP address MUST be the encapsulation recorded in the PIM 1064 Neighbor database for that IP address. 1066 2.11. Directly Connected Multicast Source 1068 If there is a source in the CE network that connects directly into 1069 the VPLS instance, then multicast traffic from that source MUST be 1070 sent to all PIM routers on the VPLS instance apart from the IGMP 1071 receivers in the VPLS. If there is already (S,G) or (*,G) snooping 1072 state that is formed on any PE, this will not happen per the current 1073 forwarding rules and guidelines. So, in order to determine if 1074 traffic needs to be flooded to all routers, a PE must be able to 1075 determine if the traffic came from a host on that LAN. There are 1076 three ways to address this problem: 1078 o The PE would have to do ARP snooping to determine if a source is 1079 directly connected. 1081 o Another option is to have configuration on all PEs to say there 1082 are CE sources that are directly connected to the VPLS instance 1083 and disallow snooping for the groups for which the source is going 1084 to send traffic. This way traffic from that source to those 1085 groups will always be flooded within the provider network. 1087 o A third option is to require that sources of CE multicast traffic 1088 must be behind a router. 1090 This document recommends the third option - sources traffic must be 1091 behind a router. 1093 2.12. Data Forwarding Rules 1095 First we define the rules that are common to PIM-SM and PIM-DM PEs. 1096 Forwarding rules for each protocol type is specified in the sub- 1097 sections. 1099 If there is no matching forwarding state, then the PE SHOULD discard 1100 the packet, i.e., the UserDefinedPortList below SHOULD be empty. 1102 The following general rules MUST be followed when forwarding 1103 multicast traffic in a VPLS: 1105 o Traffic arriving on a port MUST NOT be forwarded back onto the 1106 same port. 1108 o Due to VPLS Split-Horizon rules, traffic ingressing on a PW MUST 1109 NOT be forwarded to any other PW. 1111 2.12.1. PIM-SM Data Forwarding Rules 1113 Per the rules in [PIM-SM] and per the additional rules specified in 1114 this document, 1116 OutgoingPortList(*,G) = immediate_olist(*,G) (+) 1117 UpstreamPorts(*,G) (+) 1118 Rport(PimDR) 1120 OutgoingPortList(S,G) = inherited_olist(S,G) (+) 1121 UpstreamPorts(S,G) (+) 1122 (UpstreamPorts(*,G) (-) 1123 UpstreamPorts(S,G,rpt)) (+) 1124 Rport(PimDR) 1126 [PIM-SM] specifies how immediate_olist(*,G) and inherited_olist(S,G) 1127 are built. PimDR is the IP address of the PIM DR in the VPLS. 1129 The PIM-SM Snooping forwarding rules are defined below in pseudocode: 1131 BEGIN 1132 iif is the incoming port of the multicast packet. 1133 S is the Source IP Address of the multicast packet. 1134 G is the Destination IP Address of the multicast packet. 1136 If there is (S,G) state on the PE 1137 Then 1138 OutgoingPortList = OutgoingPortList(S,G) 1139 Else if there is (*,G) state on the PE 1140 Then 1141 OutgoingPortList = OutgoingPortList(*,G) 1142 Else 1143 OutgoingPortList = UserDefinedPortList 1144 Endif 1146 If iif is an AC 1147 Then 1148 OutgoingPortList = OutgoingPortList (-) iif 1149 Else 1150 ## iif is a PW 1151 OutgoingPortList = OutgoingPortList (-) PWPorts 1152 Endif 1154 Forward the packet to OutgoingPortList. 1155 END 1157 First if there is (S,G) state on the PE, then the set of outgoing 1158 ports is OutgoingPortList(S,G). 1160 Otherwise if there is (*,G) state on the PE, the set of outgoing 1161 ports is OutgoingPortList(*,G). 1163 The packet is forwarded to the selected set of outgoing ports while 1164 observing the general rules above in Section 2.12 1166 2.12.2. PIM-DM Data Forwarding Rules 1168 The PIM-DM Snooping data forwarding rules are defined below in 1169 pseudocode: 1171 BEGIN 1172 iif is the incoming port of the multicast packet. 1173 S is the Source IP Address of the multicast packet. 1174 G is the Destination IP Address of the multicast packet. 1176 If there is (S,G) state on the PE 1177 Then 1178 OutgoingPortList = olist(S,G) 1179 Else 1180 OutgoingPortList = UserDefinedPortList 1181 Endif 1183 If iif is an AC 1184 Then 1185 OutgoingPortList = OutgoingPortList (-) iif 1186 Else 1187 ## iif is a PW 1188 OutgoingPortList = OutgoingPortList (-) PWPorts 1189 Endif 1191 Forward the packet to OutgoingPortList. 1192 END 1194 If there is forwarding state for (S,G), then forward the packet to 1195 olist(S,G) while observing the general rules above in section 1196 Section 2.12 1198 [PIM-DM] specifies how olist(S,G) is constructed. 1200 3. IANA Considerations 1202 This document makes no request of IANA. 1204 Note to RFC Editor: this section may be removed on publication as an 1205 RFC. 1207 4. Security Considerations 1209 Security considerations provided in VPLS solution documents (i.e., 1210 [VPLS-LDP] and [VPLS-BGP]) apply to this document as well. 1212 5. Contributors 1214 Yetik Serbest, Suresh Boddapati co-authored earlier versions. 1216 Karl (Xiangrong) Cai and Princy Elizabeth made significant 1217 contributions to bring the specification to its current state, 1218 especially in the area of Join forwarding rules. 1220 6. Acknowledgements 1222 Many members of the L2VPN and PIM working groups have contributed to 1223 and provided valuable comments and feedback to this draft, including 1224 Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere, 1225 Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah 1226 (Ciena), Himanshu Shah (Alcatel-Lucent). 1228 7. References 1230 7.1. Normative References 1232 [PIM-BIDIR] 1233 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1234 "Bidirectional Protocol Independent Multicast (BIDIR- 1235 PIM)", RFC 5015, 2007. 1237 [PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1238 Independent Multicast Version 2 - Dense Mode 1239 Specification", RFC 3973, 2005. 1241 [PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1242 "Protocol Independent Multicast- Sparse Mode (PIM-SM): 1243 Protocol Specification (Revised)", RFC 4601, 2006. 1245 [PIM-SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1246 IP", RFC 4607, 2006. 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, 1997. 1251 [RPF-VECTOR] 1252 Wijnands, I., Boers, A., and E. Rosen, "The Reverse Path 1253 Forwarding (RPF) Vector TLV", RFC 5496, 2009. 1255 7.2. Informative References 1257 [IGMP-SNOOP] 1258 Christensen, M., Kimball, K., and F. Solensky, 1259 "Considerations for IGMP and MLD Snooping PEs", RFC 4541, 1260 2006. 1262 [VPLS-BGP] 1263 Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1264 using BGP for Auto-Discovery and Signaling", RFC 4761, 1265 2007. 1267 [VPLS-LDP] 1268 Lasserre, M. and V. Kompella, "Virtual Private LAN 1269 Services using LDP Signaling", RFC 4762, 2007. 1271 [VPLS-MCAST-REQ] 1272 Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, 1273 "Requirements for Multicast Support in Virtual Private LAN 1274 Services", RFC 5501, 2009. 1276 [VPLS-MCAST-TREES] 1277 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 1278 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-11, Work 1279 in Progress. 1281 Appendix A. PIM-BIDIR Thoughts 1283 This section describes some guidelines that may be used to preserve 1284 PIM-BIDIR functionality in combination with Pim Snooping. 1286 In order to preserve PIM-BIDIR Pim snooping routers need to set up 1287 forwarding states so that : 1289 o on the RPL all traffic is forwarded to all Rport(N) 1291 o on any other interface traffic is always forwarded to the DF 1293 The information needed to setup these states may be obtained by : 1295 o determining the mapping between group(range) and RP 1297 o snooping and storing DF election information 1299 o determining where the RPL is, this could be achieved by static 1300 configuration, or by combining the information mentioned in 1301 previous bullets. 1303 A.1. PIM-BIDIR Data Forwarding Rules 1305 The PIM-BIDIR Snooping forwarding rules are defined below in 1306 pseudocode: 1308 BEGIN 1309 iif is the incoming port of the multicast packet. 1310 G is the Destination IP Address of the multicast packet. 1312 If there is forwarding state for G 1313 Then 1314 OutgoingPortList = olist(G) 1315 Else 1316 OutgoingPortList = UserDefinedPortList 1317 Endif 1319 If iif is an AC 1320 Then 1321 OutgoingPortList = OutgoingPortList (-) iif 1322 Else 1323 ## iif is a PW 1324 OutgoingPortList = OutgoingPortList (-) PWPorts 1325 Endif 1327 Forward the packet to OutgoingPortList. 1328 END 1330 If there is forwarding state for G, then forward the packet to 1331 olist(G) while observing the general rules above in Section 2.12 1333 [PIM-BIDIR] specifies how olist(G) is constructed. 1335 Appendix B. Example Network Scenario 1337 Let us consider the scenario in Figure 3. 1339 An Example Network for Triggering Assert 1341 +------+ AC3 +------+ 1342 | PE2 |-----| CE3 | 1343 /| | +------+ 1344 / +------+ | 1345 / | | 1346 / | | 1347 /PW12 | | 1348 / | /---\ 1349 / |PW23 | S | 1350 / | \---/ 1351 / | | 1352 / | | 1353 / | | 1354 +------+ / +------+ | 1355 +------+ | PE1 |/ PW13 | PE3 | +------+ 1356 | CE1 |-----| |-------------| |-----| CE4 | 1357 +------+ AC1 +------+ +------+ AC4 +------+ 1358 | 1359 |AC2 1360 +------+ 1361 | CE2 | 1362 +------+ 1364 In the examples below, JT(Port,S,G,N) is the downstream Join Expiry 1365 Timer on the specified Port for the (S,G) with upstream neighbor N. 1367 B.1. Pim Snooping Example 1369 In the network depicted in Figure 3, S is the source of a multicast 1370 stream (S,G). CE1 and CE2 both have two ECMP routes to reach the 1371 source. 1372 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1373 2. PE1 snoops on the Join(S,G) and builds forwarding states since it 1374 is received on an AC. It also floods the Join(S,G) in the VPLS. PE2 1375 snoops on the Join(S,G) and builds forwarding state since the Join(S,G) 1376 is targeting a neighbor residing on an AC. PE3 does not create 1377 forwarding state for (S,G) because this is a PW-only join and there is 1378 neither existing (*,G) state with an AC in UpstreamPorts(*,G) nor an 1379 existing (S,G) state with an AC in UpstreamPorts(S,G). Both PE2 and PE3 1380 will also flood the Join(S,G) in the VPLS 1382 The resulting states at the PEs is as follows: 1384 At PE1: 1385 JT(AC1,S,G,CE3) = JP_HoldTime 1386 UpstreamNeighbors(S,G) = { CE3 } 1387 UpstreamPorts(S,G) = { PW12 } 1388 OutgoingPortList(S,G) = { AC1, PW12 } 1390 At PE2: 1391 JT(PW12,S,G,CE3) = JP_HoldTime 1392 UpstreamNeighbors(S,G) = { CE3 } 1393 UpstreamPorts(S,G) = { AC3 } 1394 OutgoingPortList(S,G) = { PW12, AC3 } 1396 At PE3: 1397 No (S,G) state 1399 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1 1400 4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4. 1401 5. All PEs snoop on the Join(S,G), build forwarding state and flood the 1402 Join(S,G) in the VPLS. Note that for PE2 even though this is a PW-only 1403 join, forwarding state is built on this Join(S,G) since PE2 has existing 1404 (S,G) state with an AC in UpstreamPorts(S,G) 1406 The resulting states at the PEs: 1408 At PE1: 1409 JT(AC1,S,G,CE3) = active 1410 JT(AC2,S,G,CE4) = JP_HoldTime 1411 UpstreamNeighbors(S,G) = { CE3, CE4 } 1412 UpstreamPorts(S,G) = { PW12, PW13 } 1413 OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 } 1415 At PE2: 1416 JT(PW12,S,G,CE4) = JP_HoldTime 1417 JT(PW12,S,G,CE3) = active 1418 UpstreamNeighbors(S,G) = { CE3, CE4 } 1419 UpstreamPorts(S,G) = { AC3, PW23 } 1420 OutgoingPortList(S,G) = { PW12, AC3, PW23 } 1422 At PE3: 1423 JT(PW13,S,G,CE4) = JP_HoldTime 1424 UpstreamNeighbors(S,G) = { CE4 } 1425 UpstreamPorts(S,G) = { AC4 } 1426 OutgoingPortList(S,G) = { PW13, AC4 } 1428 6. The multicast stream (S,G) flows into the VPLS from the two CEs 1429 CE3 and CE4. PE2 forwards the stream received from CE3 to PW23 1430 and PE3 forwards the stream to AC4. This facilitates the CE 1431 routers to trigger assert election. Let us say CE3 becomes the 1432 assert winner. 1433 7. CE3 sends an Assert message to the VPLS. The PEs flood the 1434 Assert message without examining it. 1436 8. CE4 stops sending the multicast stream to the VPLS. 1437 9. CE2 notices an RPF change due to Assert and sends a Prune(S,G) 1438 with Upstream Neighbor = CE4. CE2 also sends a Join(S,G) with 1439 Upstream Neighbor = CE3. 1440 10. All the PEs start a prune-pend timer on the ports on which 1441 they received the Prune(S,G). When the prune-pend timer expires, 1442 all PEs will remove the downstream (S,G,CE4) states. 1444 Resulting states at the PEs: 1446 At PE1: 1447 JT(AC1,S,G,CE3) = active 1448 UpstreamNeighbors(S,G) = { CE3 } 1449 UpstreamPorts(S,G) = { PW12 } 1450 OutgoingPortList(S,G) = { AC1, AC2, PW12 } 1452 At PE2: 1453 JT(PW12,S,G,CE3) = active 1454 UpstreamNeighbors(S,G) = { CE3 } 1455 UpstreamPorts(S,G) = { AC3 } 1456 OutgoingPortList(S,G) = { PW12, AC3 } 1458 At PE3: 1459 JT(PW13,S,G,CE3) = JP_HoldTime 1460 UpstreamNeighbors(S,G) = { CE3 } 1461 UpstreamPorts(S,G) = { PW23 } 1462 OutgoingPortList(S,G) = { PW13, PW23 } 1464 Note that at this point at PE3, since there is no AC in 1465 OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in 1466 UpstreamPorts(*,G) or UpstreamPorts(S,G) respectively, the existing 1467 (S,G) state at PE3 can also be removed. So finally: 1469 At PE3: 1470 No (S,G) state 1472 Note that at the end of the assert election, there should be no 1473 duplicate traffic forwarded downstream and traffic should flow only 1474 on the desired path. Also note that there are no unnecessary (S,G) 1475 states on PE3 after the assert election. 1477 B.2. PIM Proxy Example with (S,G) / (*,G) interaction 1479 In the same network, let us assume CE4 is the Upstream Neighbor 1480 towards the RP for G. 1482 JPST(S,G,N) is the JP sending timer for the (S,G) with upstream 1483 neighbor N. 1485 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1487 2. PE1 consumes the Join(S,G) and builds forwarding state since the 1488 Join(S,G) is received on an AC. 1490 PE2 consumes the Join(S,G) and builds forwarding state since the 1491 Join(S,G) is targeting a neighbor residing on an AC. 1493 PE3 consumes the Join(S,G) but does not create forwarding state for 1494 (S,G) since this is a PW-only join and there is neither existing (*,G) 1495 state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with 1496 an AC in UpstreamPorts(S,G) 1498 The resulting states at the PEs is as follows: 1500 PE1 states: 1501 JT(AC1,S,G,CE3) = JP_HoldTime 1502 JPST(S,G,CE3) = t_periodic 1503 UpstreamNeighbors(S,G) = { CE3 } 1504 UpstreamPorts(S,G) = { PW12 } 1505 OutgoingPortList(S,G) = { AC1, PW12 } 1507 PE2 states: 1508 JT(PW12,S,G,CE3) = JP_HoldTime 1509 JPST(S,G,CE3) = t_periodic 1510 UpstreamNeighbors(S,G) = { CE3 } 1511 UpstreamPorts(S,G) = { AC3 } 1512 OutgoingPortList(S,G) = { PW12, AC3 } 1514 PE3 states: 1515 No (S,G) state 1517 Joins are triggered as follows: 1518 PE1 triggers a Join(S,G) targeting CE3. Since the Join(S,G) was received 1519 on an AC and is targeting a neighbor that is residing across a PW, the 1520 triggered Join(S,G) is sent on all PWs. 1522 PE2 triggers a Join(S,G) targeting CE3. Since the Joins(S,G) is 1523 targeting a neighbor residing on an AC, it only sends the join on AC3. 1525 PE3 ignores the Join(S,G) since this is a PW-only join and there is 1526 neither existing (*,G) state with an AC in UpstreamPorts(*,G) nor an 1527 existing (S,G) state with an AC in UpstreamPorts(S,G) 1529 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. 1531 4. Now let us say CE2 sends a Join(*,G) with UpstreamNeighbor(*,G) = CE4. 1533 5. PE1 consumes the Join(*,G) and builds forwarding state since the 1534 Join(*,G) is received on an AC. 1536 PE2 consumes the Join(*,G) and though this is a PW-only join, forwarding 1537 state is build on this Join(*,G) since PE2 has existing (S,G) state with 1538 an AC in UpstreamPorts(S,G). However, since this is a PW-only join, PE2 1539 only adds the PW towards PE3 (PW23) into UpstreamPorts(*,G) and hence 1540 into OutgoingPortList(*,G). It does not add the PW towards PE1 (PW12) 1541 into OutgoingPortsList(*,G) 1543 PE3 consumes the Join(*,G) and builds forwarding state since the 1544 Join(*,G) is targeting a neighbor residing on an AC. 1546 The resulting states at the PEs is as follows: 1548 PE1 states: 1549 JT(AC1,*,G,CE4) = JP_HoldTime 1550 JPST(*,G,CE4) = t_periodic 1551 UpstreamNeighbors(*,G) = { CE4 } 1552 UpstreamPorts(*,G) = { PW13 } 1553 OutgoingPortList(*,G) = { AC2, PW13 } 1555 JT(AC1,S,G,CE3) = active 1556 JPST(S,G,CE3) = active 1557 UpstreamNeighbors(S,G) = { CE3 } 1558 UpstreamPorts(S,G) = { PW12 } 1559 OutgoingPortList(S,G) = { AC1, PW12, PW13 } 1561 PE2 states: 1562 JT(PW12,*,G,CE4) = JP_HoldTime 1563 UpstreamNeighbors(*,G) = { CE4 } 1564 UpstreamPorts(G) = { PW23 } 1565 OutgoingPortList(*,G) = { PW23 } 1567 JT(PW12,S,G,CE3) = active 1568 JPST(S,G,CE3) = active 1569 UpstreamNeighbors(S,G) = { CE3 } 1570 UpstreamPorts(S,G) = { AC3 } 1571 OutgoingPortList(S,G) = { PW12, AC3, PW23 } 1573 PE3 states: 1574 JT(PW13,*,G,CE4) = JP_HoldTime 1575 JPST(*,G,CE4) = t_periodic 1576 UpstreamNeighbors(*,G) = { CE4 } 1577 UpstreamPorts(*,G) = { AC4 } 1578 OutgoingPortList(*,G) = { PW13, AC4 } 1580 Joins are triggered as follows: 1582 PE1 triggers a Join(*,G) targeting CE4. Since the Join(*,G) was received 1583 on an AC and is targeting a neighbor that is residing across a PW, the 1584 triggered Join(S,G) is sent on all PWs. 1586 PE2 does not trigger a Join(*,G) based on this join since this is a 1587 PW-only join. 1589 PE3 triggers a Join(*,G) targeting CE4. Since the Join(*,G) is targeting 1590 a neighbor residing on an AC, it only sends the join on AC4. 1592 6. In case traffic is not flowing yet (i.e. step 3 is delayed to come after 1593 step 6) and in the interim JPST(S,G,CE3) on PE1 expires, causing it to 1594 send a refresh Join(S,G) targeting CE3, since the refresh Join(S,G) is 1595 targeting a neighbor that is residing across a PW, the refresh Join(S,G) 1596 is sent on all PWs. 1598 7. Note that PE1 refreshes its JT timer based on reception of refresh joins 1599 from CE1 and CE2 1601 PE2 consumes the Join(S,G) and refreshes the JT(PW12,S,G,CE3) timer. 1603 PE3 consumes the Join(S,G). It also builds forwarding state on this 1604 Join(S,G), even though this is a PW-only join, since now PE2 has existing 1605 (*,G) state with an AC in UpstreamPorts(*,G). However, since this is a 1606 PW-only join, PE3 only adds the PW towards PE2 (PW23) into 1607 UpstreamPorts(S,G) and hence into OutgoingPortList(S,G). It does not add 1608 the PW towards PE1 (PW13) into OutgoingPortList(S,G). 1610 PE3 States: 1611 JT(PW13,*,G,CE4) = active 1612 JPST(S,G,CE4) = active 1613 UpstreamNeighbors(*,G) = { CE4 } 1614 UpstreamPorts(*,G) = { AC4 } 1615 OutgoingPortList(*,G) = { PW13, AC4 } 1617 JT(PW13,S,G,CE3) = JP_HoldTime 1618 UpstreamNeighbors(*,G) = { CE3 } 1619 UpstreamPorts(*,G) = { PW23 } 1620 OutgoingPortList(*,G) = { PW13, AC4, PW23 } 1622 Joins are triggered as follows: 1623 PE2 already has (S,G) state, so it does not trigger a Join(S,G) 1624 based on reception of this refresh join. 1626 PE3 does not trigger a Join(S,G) based on this join since this is a 1627 PW-only join. 1629 8. The multicast stream (S,G) flows into the VPLS from the two 1630 CEs, CE3 and CE4. PE2 forwards the stream received from CE3 to 1631 PW12 and PW23. At the same time PE3 forwards the stream 1632 received from CE4 to PW13 and PW23. 1634 The stream received over PW12 and PW13 is forwarded by PE1 to 1635 AC1 and AC2. 1637 The stream received by PE3 over PW23 is forwarded to AC4. The 1638 stream received by PE2 over PW23 is forwarded to AC3. Either of 1639 these facilitates the CE routers to trigger assert election. 1641 9. CE3 and/or CE4 send(s) Assert message(s) to the VPLS. The PEs 1642 flood the Assert message(s) without examining it. 1644 10. CE3 becomes the (S,G) assert winner and CE4 stops sending the 1645 multicast stream to the VPLS. 1647 11. CE2 notices an RPF change due to Assert and sends a 1648 Prune(S,G,rpt) with Upstream Neighbor = CE4. 1650 12. PE1 consumes the Prune(S,G,rpt) and since PruneDesired(S,G,Rpt,CE4) is 1651 TRUE, it triggers a Prune(S,G,rpt) to CE4. Since the prune is 1652 targeting a neighbor across a PW, it is sent on all PWs. 1654 PE2 consumes the Prune(S,G,rpt) and does not trigger any prune 1655 based on this Prune(S,G,rpt) since this was a PW-only prune. 1657 PE3 consumes the Prune(S,G,rpt) and since PruneDesired(S,G,rpt,CE4) 1658 is TRUE it sends the Prune(S,G,rpt) on AC4. 1660 PE1 states: 1661 JT(AC2,*,G,CE4) = active 1662 JPST(*,G,CE4) = active 1663 UpstreamNeighbors(*,G) = { CE4 } 1664 UpstreamPorts(*,G) = { PW13 } 1665 OutgoingPortList(*,G) = { AC2, PW13 } 1667 JT(AC2,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune 1668 JPST(S,G,CE4) = none, since this is sent along 1669 with the Join(*,G) to CE4 based 1670 on JPST(*,G,CE4) expiry 1671 UpstreamPorts(S,G,rpt) = { PW13 } 1672 UpstreamNeighbors(S,G,rpt) = { CE4 } 1674 JT(AC1,S,G,CE3) = active 1675 JPST(S,G,CE3) = active 1676 UpstreamNeighbors(S,G) = { CE3 } 1677 UpstreamPorts(S,G) = { PW12 } 1678 OutgoingPortList(S,G) = { AC1, PW12, AC2 } 1680 At PE2: 1681 JT(PW12,*,G,CE4) = active 1682 UpstreamNeighbors(*,G) = { CE4 } 1683 UpstreamPorts(*,G) = { PW23 } 1684 OutgoingPortList(*,G) = { PW23 } 1686 JT(PW12,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune 1687 JPST(S,G,CE4) = none, since this was created 1688 off a PW-only prune 1689 UpstreamPorts(S,G,rpt) = { PW23 } 1690 UpstreamNeighbors(S,G,rpt) = { CE4 } 1692 JT(PW12,S,G,CE3) = active 1693 JPST(S,G,CE3) = active 1694 UpstreamNeighbors(S,G) = { CE3 } 1695 UpstreamPorts(S,G) = { AC3 } 1696 OutgoingPortList(*,G) = { PW12, AC3 } 1698 At PE3: 1699 JT(PW13,*,G,CE4) = active 1700 JPST(*,G,CE4) = active 1701 UpstreamNeighbors(*,G) = { CE4 } 1702 UpstreamPorts(*,G) = { AC4 } 1703 OutgoingPortList(*,G) = { PW13, AC4 } 1705 JT(PW13,S,G,CE4) = JP_Holdtime with S,G,rpt prune flag 1706 JPST(S,G,CE4) = none, since this is sent along 1707 with the Join(*,G) to CE4 based 1708 on JPST(*,G,CE4) expiry 1709 UpstreamNeighbors(S,G,rpt) = { CE4 } 1710 UpstreamPorts(S,G,rpt) = { AC4 } 1712 JT(PW13,S,G,CE3) = active 1713 JPST(S,G,CE3) = none, since this state is 1714 created by PW-only join 1715 UpstreamNeighbors(S,G) = { CE3 } 1716 UpstreamPorts(S,G) = { PW23 } 1717 OutgoingPortList(S,G) = { PW23 } 1719 Even in this example, at the end of the (S,G) / (*,G) assert 1720 election, there should be no duplicate traffic forwarded downstream 1721 and traffic should flow only to the desired CEs. 1723 However, the reason we don't have duplicate traffic is because one of 1724 the CEs stops sending traffic due to assert, not because we don't 1725 have any forwarding state in the PEs to do this forwarding. 1727 Authors' Addresses 1729 Olivier Dornon 1730 Alcatel-Lucent 1731 50 Copernicuslaan 1732 Antwerp, B2018 1734 Email: olivier.dornon@alcatel-lucent.com 1736 Jayant Kotalwar 1737 Alcatel-Lucent 1738 701 East Middlefield Rd. 1739 Mountain View, CA 94043 1741 Email: jayant.kotalwar@alcatel-lucent.com 1743 Venu Hemige 1745 Email: vhemige@gmail.com 1747 Ray Qiu 1748 Juniper Networks, Inc. 1749 1194 North Mathilda Avenue 1750 Sunnyvale, CA 94089 1752 Email: rqiu@juniper.net 1754 Jeffrey Zhang 1755 Juniper Networks, Inc. 1756 10 Technology Park Drive 1757 Westford, MA 01886 1759 Email: zzhang@juniper.net