idnits 2.17.1 draft-ietf-l2vpn-vpls-pim-snooping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1539. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IGMP-SNOOP], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2006) is 6488 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-01 -- No information found for draft-qiu-serbest-vpls-mcast-ldp - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Venu Hemige 3 Alcatel 4 Internet Engineering Task Force Yetik Serbest 5 Document: AT&T 6 draft-ietf-l2vpn-vpls-pim-snooping-00.txt Ray Qiu 7 Suresh Boddapati 8 Alcatel 9 July 2006 10 Category: Informational 11 Expires: January 2007 13 PIM Snooping over VPLS 15 Status of this memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 In Virtual Private LAN Service (VPLS), as also in IEEE Bridged 40 Networks, the switches simply flood multicast traffic on all ports in 41 the LAN by default. IGMP Snooping is commonly deployed to ensure 42 multicast traffic is not forwarded on ports without IGMP receivers. 43 The procedures and recommendations for IGMP Snooping are defined in 44 [IGMP-SNOOP]. But when any protocol other than IGMP is used, the 45 common practice is to simply flood multicast traffic to all ports. 46 PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM 47 Snooping procedures are important to restrict multicast traffic to 48 only the routers interested in receiving such traffic. 50 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 52 While most of the PIM Snooping procedures defined here also apply to 53 IEEE Bridged Networks, VPLS demands certain special procedures due to 54 the split-horizon rules that require the Provider Edge (PE) devices 55 to co-operate. This document describes the procedures and 56 recommendations for PIM-Snooping in VPLS to facilitate replication to 57 only those ports behind which there are interested PIM routers and/or 58 IGMP hosts. 60 This document also describes procedures for PIM Proxy. PIM Proxy is 61 required on PEs for VPLS Multicast to work correctly when Join 62 suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS 63 Multicast much better than just PIM Snooping. 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC 2119]. 71 Table of Contents 73 1. Introduction.............................................3 74 1.1. Assumptions............................................4 75 1.2. Definitions............................................4 76 2. Multicast Traffic over VPLS..............................5 77 2.1. Constraining of IP Multicast in a VPLS.................6 78 2.2. IPv6 Considerations....................................7 79 2.3. PIM-SM (*,*,RP) Considerations.........................7 80 2.4. PIM Snooping vs PIM Proxy..............................7 81 2.4.1. Differences between PIM Snooping and PIM Proxy.......8 82 3. PIM Snooping for VPLS....................................9 83 3.1. General Rules for PIM Snooping in VPLS.................9 84 3.1.1. Snooping PIM Packets................................10 85 3.2. Discovering PIM Routers...............................10 86 3.3. PIM-SM and PIM-SSM....................................11 87 3.3.1. Building PIM-SM Snooping States.....................11 88 3.3.2. Explaination for per (S,G,N) states.................13 89 3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages..........13 90 3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages..........16 91 3.3.5. Receiving (S,G,rpt) Join/Prune Messages.............17 92 3.3.6. Sending (*,G) Join/Prune Messages...................17 93 3.3.7. Sending (S,G) Join/Prune Messages...................18 94 3.3.8. Sending PIM Join/Prune message upstream.............18 95 3.3.9. Triggering ASSERT Election in PIM-SM................19 96 3.4. Bidirectional-PIM (PIM-BIDIR).........................22 97 3.4.1. Building PIM-BIDIR Snooping States..................23 98 3.5. PIM-DM................................................23 100 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 102 3.5.1. Building PIM-DM Snooping States.....................23 103 3.5.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine.23 104 3.5.3. Triggering ASSERT election in PIM-DM................24 105 3.6. PIM Proxy.............................................24 106 3.6.1. Downstream PIM Proxy behavior.......................24 107 3.6.2. Upstream PIM Proxy behavior.........................25 108 3.7. Directly Connected Multicast Source...................26 109 3.8. Data Forwarding Rules.................................26 110 3.8.1. PIM-SM Data Forwarding Rules........................27 111 3.8.2. PIM-BIDIR Data Forwarding Rules.....................28 112 3.8.3. PIM-DM Data Forwarding Rules........................28 113 4. IANA Considerations.....................................29 114 5. Security Considerations.................................29 115 6. References..............................................29 116 6.1. Normative References..................................29 117 6.2. Informative References................................30 119 1. Introduction 121 In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices 122 provide a logical interconnect such that Customer Edge (CE) devices 123 belonging to a specific VPLS instance appear to be connected by a 124 single LAN. Forwarding information base for particular VPLS instance 125 is populated dynamically by source MAC address learning. This is a 126 straightforward solution to support unicast traffic, with reasonable 127 flooding for unicast unknown traffic. Since a VPLS provides LAN 128 emulation for IEEE bridges as wells as for routers, the unicast and 129 multicast traffic need to follow the same path for layer-2 protocols 130 to work properly. As such, multicast traffic is treated as broadcast 131 traffic and is flooded to every site in the VPLS instance. 133 VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication 134 for multicast traffic at the ingress PE devices. When replicated at 135 the ingress PE, multicast traffic wastes bandwidth when: 136 1. Multicast traffic is sent to sites with no members, 137 2. Pseudo wires to different sites go through a shared path, and 138 3. Multicast traffic is forwarded along a shortest path tree as 139 opposed to the minimum cost spanning tree. 141 This document is addressing the first problem by IGMP and PIM 142 snooping. Problems #2 and #3 are orthogonal to #1 and outside the 143 scope of this document. The different mechanisms to tunnel IP 144 multicast traffic in a VPLS from the ingress PE to the egress PEs are 145 discussed in [VPLS-MCAST-TREES]. 147 Using VPLS in conjunction with IGMP and/or PIM snooping has the 148 following advantages: 150 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 152 - It improves VPLS to support IP multicast efficiently (not 153 necessarily optimum, as there can still be bandwidth waste if 154 traffic from a PE to other PE(s) is not forwarded along a 155 minimum cost spanning tree.), 156 - It prevents sending multicast traffic to sites with no 157 members. 159 Procedures for IGMP Snooping are specified in [IGMP-SNOOP]. This 160 document describes the procedures for Protocol Independent Multicast 161 (PIM) snooping over VPLS for efficient distribution of IP multicast 162 traffic. It also describes the rules when both IGMP and PIM are 163 active in a VPLS instance. 165 This document also describes procedures for PIM Proxy. PIM Proxy is 166 required on PEs for VPLS Multicast to work correctly when Join 167 suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS 168 Multicast much better than just PIM Snooping. 170 1.1. Assumptions 172 Since this draft describes the procedures for PIM Snooping and PIM 173 Proxy, the draft assumes that the reader has a good understanding of 174 the PIM protocols. The text in this draft is written in the same 175 style as the PIM RFCs to help correlate the concepts and to make it 176 easier to follow. In order to avoid replicating the text relating to 177 PIM protocol handling here, this draft assumes that the user will 178 infer such detail from the PIM RFC referenced in this document. 179 Deviations in protocol handling specific to PIM Snooping and PIM 180 Proxy are specified in this draft. There could be cross references 181 into definitions of macros and procedures from the PIM RFCs. 183 1.2. Definitions 185 There are several definitions referenced in this document that are 186 well described in the PIM RFCs [PIM-SM, PIM-BIDIR, PIM-DM]. 188 The following definitions and abbreviations are used throughout this 189 document: 191 - A port is defined as either an attachment circuit (AC) or a 192 Pseudo-Wire (PW). 193 - When we say a PIM message is 'received' on a port, it means 194 any one of the following: 195 o that a PIM Snooping switch snooped the PIM message. 196 o that a PIM message was received via LDP on a PW if LDP (as 197 defined in [VPLS-MCAST-LDP]) is used for propogating 198 multicast states among the PEs. 200 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 202 Abbreviations used in the document: 204 - S: IP Address of the Multicast Source. 205 - G: IP Address of the Multicast Group. 206 - N: Upstream Neighbor field in a Join/Prune/Graft message. 207 - Rport(X): Port on which neighbor X is learnt 209 Other definitions are explained in the sections where they are 210 introduced. 212 2. Multicast Traffic over VPLS 214 In VPLS, if a PE receives a frame from an Attachment Circuit (AC) 215 with no matching entry in the forwarding information base for that 216 particular VPLS instance, it floods the frame to all other PEs (which 217 are part of this VPLS instance) and to directly connected ACs (other 218 than the one that the frame is received from). The flooding of a 219 frame occurs when: 220 - The destination MAC address has not been learned, 221 - The destination MAC address is a broadcast address, 222 - The destination MAC address is a multicast address. 224 Malicious attacks (e.g., receiving unknown frames constantly) aside, 225 the first situation is handled by VPLS solutions as long as 226 destination MAC address can be learned. After that point on, the 227 frames will not be flooded. A PE is REQUIRED to have safeguards, 228 such as unknown unicast limiting and MAC table limiting, against 229 malicious unknown unicast attacks. 231 There is no way around flooding broadcast frames. To prevent runaway 232 broadcast traffic from adversely affecting the VPLS service and the 233 SP network, a PE is REQUIRED to have tools to rate limit the 234 broadcast traffic as well. 236 Similar to broadcast frames, multicast frames are flooded as well, as 237 a PE cannot know where multicast members reside. Rate limiting 238 multicast traffic, while possible, should be should be done carefully 239 since several network control protocols relies on multicast. For one 240 thing, layer-2 and layer-3 protocols utilize multicast for their 241 operation. For instance, Bridge Protocol Data Units (BPDUs) use an 242 IEEE assigned all bridges multicast MAC address, and OSPF is 243 multicast to all OSPF routers multicast MAC address. If the rate- 244 limiting of multicast traffic is not done properly, the customer 245 network will experience instability and poor performance. For the 246 other, it is not straightforward to determine the right rate limiting 247 parameters for multicast. 249 A VPLS solution MUST NOT affect the operation of customer layer-2 250 protocols (e.g., BPDUs). Additionally, a VPLS solution MUST NOT 251 affect the operation of layer-3 protocols. 253 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 255 In the following section, we describe procedures to constrain the 256 flooding of IP multicast traffic in a VPLS. 258 2.1. Constraining of IP Multicast in a VPLS 260 For a PE in a VPLS (a layer-2 device) to constrain IP multicast 261 traffic, it needs to be able to learn which CEs are interested in 262 receiving multicast traffic for what flows. 264 The most obvious solution is to snoop IP multicast control traffic at 265 the PEs. Snooping as a solution to constrain multicast traffic makes 266 sense under the following circumstances: 267 - The CE-CE protocol the PEs snoop is a popular and widely 268 deployed protocol. 269 - It does not require any changes on the CEs and it should be 270 completely transparent to the CEs. 272 Using VPLS in conjunction with IGMP and/or PIM snooping has the 273 following advantages: 274 - It improves VPLS to support IP multicast efficiently (not 275 necessarily optimum, as there can still be bandwidth waste if 276 traffic from a PE to other PE(s) is not forwarded along a 277 minimum cost spanning tree.), 278 - It prevents sending multicast traffic to sites with no 279 members. 281 Other routing protocols such as DVMRP or MOSPF are outside the scope 282 of this document. 284 In the following sub-sections, we provide some guidelines for the 285 implementation of PIM snooping in VPLS. Snooping techniques need to 286 be employed on ACs at the downstream PEs. Snooping techniques can 287 also be employed on PWs at the upstream PEs. This may work well for 288 small to medium scale deployments. However, if there are a large 289 number of VPLS instances with a large number of PEs per instances, 290 then the amount of snooping required at the upstream PEs can 291 overwhelm the upstream PEs. In [VPLS-MCAST-LDP] and [VPLS-MCAST-BGP], 292 procedures are defined to exchange multicast membership information 293 between the PEs using LDP or BGP. Using a reliable mechanism like LDP 294 or BGP allows the upstream PEs to eliminate the requirement to snoop 295 on PWs. It also eliminates the need to refresh multicast states on 296 the upstream PEs. 298 This document also describes the guidelines for PIM Proxy in VPLS. 299 The specifications in this document could be used for either PIM 300 Snooping or PIM Proxy. The PIM Proxy solution is described in section 301 3.6. Differences that need to be observed while implementing one or 302 the other and recommendations on which method to employ in different 303 scenarios are noted in section 2.4. 305 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 307 2.2. IPv6 Considerations 309 In VPLS, PEs forward Ethernet frames received from CEs and as such 310 are agnostic of the layer-3 protocol used by the CEs. However, as an 311 IGMP and PIM snooping switch, the PE would have to look deeper into 312 the IP and IGMP/PIM packets and build snooping state based on that. 313 The PIM Protocol specifications handle both IPv4 and IPv6. The 314 specification for PIM Snooping in this draft can be applied to both 315 IPv4 and IPv6 payloads. 317 2.3. PIM-SM (*,*,RP) Considerations 319 This draft does not address (*,*,RP) states in the VPLS network. 320 Although [PIM-SM] specifies that routers MUST support (*,*,RP) 321 states, there are very few implementations that actually support it 322 in actual deployments. Given the complexity of supporting (*,*,RP) 323 states and knowing that there is little to no use to supporting it, 324 this draft omits the specification relating to (*,*,RP) support. 326 2.4. PIM Snooping vs PIM Proxy 328 PIM Snooping switches simply snoop on PIM packets as they are being 329 forwarded in the VPLS. As such it truly provides transparent LAN 330 services since no customer packets are modified or consumed or new 331 packets introduced in the VPLS. It is also slightly simpler to 332 implement than PIM Proxy. However for PIM Snooping to work correctly, 333 it is a requirement that CE routers MUST disable Join suppression in 334 the VPLS. 336 Given that a large number of existing CE deployments do not support 337 disabling of Join suppression and given the operational complexity 338 for a provider to manage disabling of Join suppression in the VPLS, 339 it becomes a difficult solution to deploy. Another disadvantage of 340 PIM Snooping as a solution is that it does not scale as well as PIM 341 Proxy. If there are a large number of CEs in a VPLS, then every CE 342 will see every other CE's Join/Prune messages. 344 PIM Proxy on the PEs has the advantage that it does not require Join 345 suppression to be disabled in the VPLS. Multicast as a VPLS service 346 can be very easily be provided without requiring any changes on the 347 CE routers. It also helps scale VPLS Multicast very well since the 348 PEs intelligently forward only one Join/Prune message for a given 349 flow and only to the upstream CE. 351 PIM Proxy as a solution however loses the transparency argument since 352 Join/Prunes could get modified or even consumed at a PE. Also, new 353 packets could get introduced in the VPLS. However, this loss of 354 transparency is limited to PIM control packets. It is in the interest 355 of optimizing multicast in the VPLS and helping a VPLS network scale 356 much better. Data traffic will still be completely transparent. 358 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 360 Both PIM Snooping and PIM Proxy procedures can be used in conjunction 361 with [VPLS-MCAST-LDP] for propogating multicast states among the PEs. 362 If [VPLS-MCAST-LDP] is used for propogating multicast states among 363 the PEs, then both PIM Snooping and PIM Proxy switches do not process 364 any PIM packets arriving on a PW. 366 2.4.1. Differences between PIM Snooping and PIM Proxy 368 For PIM-SM and PIM-BIDIR, a PIM Snooping/Proxy Switch only needs to 369 examine PIM Hello and Join/Prune messages. PIM Proxy for PIM-DM is 370 for future study and is not currently specified in this draft. 372 The proxy proposal is to perform proxy of only the Join/Prune 373 messages while snooping Hello messages. Details on the PIM Proxy 374 solution are discussed in section 3.6. This section is presented 375 here to say that most of the procedures to follow (unless explicitly 376 specified) are common to both PIM Snooping and PIM Proxy. 378 Differences between a PIM Snooping switch and a PIM Proxy switch can 379 be summarized as the following: 381 +------------------------------|--------------------------------+ 382 | PIM Snooping | PIM Proxy | 383 +==============================|================================+ 384 | 1. PIM Snooping switches | 1. PIM Proxy switches also | 385 | snoop Hello and Join/Prune| snoop PIM Hello messages | 386 | messages while they are | while they are transparently| 387 | transparently flooded in | flooded in the VPLS. But | 388 | the VPLS. | they consume PIM Join/Prune | 389 | | messages and do not flood | 390 | | them as is in the VPLS. | 391 +------------------------------|--------------------------------+ 392 | 2. PIM Snooping switches do | 2. PIM Proxy switches may | 393 | not originate any PIM | originate new or modified | 394 | packets. They may however | PIM packets. | 395 | originate PIM messages to | | 396 | be sent via LDP on PWs. | | 397 +------------------------------|--------------------------------+ 399 Other than the above simple differences, most of the procedures are 400 common to PIM Snooping and PIM Proxy. There are additional 401 simplifications to PIM Snooping that can be made if [VPLS-MCAST-LDP] 402 is not used for PE-PE communication, but otherwise the procedures for 403 PIM Snooping and PIM Proxy are mostly the same. In the text to 404 follow, we describe the text as procedures for PIM Snooping. Unless 405 otherwise specified, such procedures apply to PIM Proxy as well. 407 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 409 3. PIM Snooping for VPLS 411 IGMP snooping procedures described in [IGMP-SNOOP] provide efficient 412 delivery of IP multicast traffic in a given VPLS service when end 413 stations are connected to the VPLS. However, when VPLS is offered as 414 a WAN service it is likely that the CE devices are routers and would 415 run PIM between them. To provide efficient IP multicasting in such 416 cases, it is necessary that the PE routers offering the VPLS service 417 do PIM snooping. 419 PIM is a multicast routing protocol, which runs exclusively between 420 routers. PIM shares many of the common characteristics of a routing 421 protocol, such as discovery messages (e.g., neighbor discovery using 422 Hello messages), topology information (e.g., multicast tree), and 423 error detection and notification (e.g., dead timer and designated 424 router election). On the other hand, PIM does not participate in any 425 kind of exchange of databases, as it uses the unicast routing table 426 to provide reverse path information for building multicast trees. 427 There are a few variants of PIM. In PIM-DM ([PIM-DM]), multicast 428 data is pushed towards the members similar to broadcast mechanism. 429 PIM-DM constructs a separate delivery tree for each multicast group. 430 As opposed to PIM-DM, other PIM flavors (PIM-SM [PIM-SM], PIM-SSM 431 [PIM-SSM], and PIM-BIDIR [PIM-BIDIR]) invoke a pull methodology 432 instead of push technique. 434 PIM routers periodically exchange Hello messages to discover and 435 maintain stateful sessions with neighbors. After neighbors are 436 discovered, PIM routers can signal their intentions to join or prune 437 specific multicast groups. This is accomplished by having downstream 438 routers send an explicit Join/Prune message (for the sake of 439 generalization, consider Graft messages for PIM-DM as Join messages) 440 to the upstream routers. The Join/Prune message can be group 441 specific (*,G) or group and source specific (S,G). 443 In PIM snooping, a PE snoops on the PIM message exchange between 444 routers, and builds its multicast states. 446 Based on the multicast states, it forwards IP multicast traffic 447 accordingly to avoid unnecessary flooding. 449 In the following sub-sections, snooping mechanisms for each variety 450 of PIM are specified. 452 3.1. General Rules for PIM Snooping in VPLS 454 The following rules for the correct operation of IGMP/PIM snooping 455 MUST be followed. 457 - IGMP messages, PIM messages and multicast data traffic 458 forwarded by PEs MUST follow the split-horizon rule for mesh 459 PWs as defined in [VPLS-LDP]. 461 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 463 - IGMP/PIM snooping states in a PE MUST be per VPLS instance. 464 - Multicast traffic MUST be replicated per PW and AC basis, 465 i.e., even if there are more than one PIM neighbor behind a 466 PW/AC, only one replication MUST be sent to that PW/AC. 468 3.1.1. Snooping PIM Packets 470 PIM-SM and PIM-BIDIR snooping PEs need to snoop on just the PIM Hello 471 and PIM Join/Prune messages to build its multicast states. 473 - PIM-DM snooping PEs have to also snoop on PIM Graft and PIM 474 State Refresh messages. 476 3.2. Discovering PIM Routers 478 A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs. 479 PIM Hellos are used by the snooping switch to discover PIM routers 480 and their characteristics. 482 For each neighbor discovered by a PE, it includes an entry in the PIM 483 Neighbor Database with the following fields: 485 - Layer 2 encapsulation for the Router sending the PIM Hello. 486 - IP Address and address family of the Router sending the PIM 487 Hello. 488 - Port (AC / PW) on which the PIM Hello was received. 489 - Hello TLVs 491 The PE should be able to interpret and act on Hello TLVs currently 492 defined in the PIM RFCs. The TLVs of particular interest in this 493 document are: 495 - Hello-Hold-Time 496 - Tracking Support 497 - DR Priority 499 Please refer to [PIM-SM] for a list of the Hello TLVs. 501 When a PIM Hello is received, the PE MUST reset the neighbor-expiry- 502 timer to Hello-Hold-Time. If a PE does not receive a Hello message 503 from a router within Hello-Hold-Time, the PE MUST remove that 504 neighbor from its PIM Neighbor Database. If a PE receives a Hello 505 message from a router with Hello-Hold-Time value set to zero, the PE 506 MUST remove that router from the PIM snooping state immediately. 508 From the PIM Neighbor Database, a PE MUST be able to use the 509 procedures defined in [PIM-SM] to identify the Designated Router in 511 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 513 the VPLS instance. It should also be able to determine if Tracking 514 Support is active in the VPLS instance. 516 3.3. PIM-SM and PIM-SSM 517 The key characteristic of PIM-SM and PIM-SSM is explicit join 518 behavior. In this model, multicast traffic is only forwarded to 519 locations that specifically request it. The root node of a tree is 520 the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or 521 the first hop router that is directly connected to the multicast 522 source in the case of a shortest path tree. All the procedures 523 described in this section apply to both PIM-SM and PIM-SSM, except 524 for the fact that there is no (*,G) state in PIM-SSM. 526 The procedures to discover PIM-SM routers in a VPLS instance are as 527 described in section 3.2. 529 3.3.1. Building PIM-SM Snooping States 531 PIM-SM and PIM-SSM Snooping states are built by snooping on the PIM- 532 SM Join/Prune messages received on AC/PWs. 533 The downstream state machine of a PIM-SM snooping switch very closely 534 resembles the downstream state machine of PIM-SM routers. The 535 downstream state consists of: 537 Per downstream (Port, *, G): 538 - DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 539 Pending" (PP) } 541 Per downstream (Port, *, G, N): 542 - Prune Pending Timer (PPT(N)) 543 - Join Expiry Timer (ET(N)) 545 Per downstream (Port, S, G): 546 - DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune 547 Pending" (PP) } 549 Per downstream (Port, S, G, N): 550 - Prune Pending Timer (PPT(N)) 551 - Join Expiry Timer (ET(N)) 553 Per downstream (Port, S, G, rpt): 554 - DownstreamJPRptState: One of { "NoInfo" (NI), "Pruned" (P), 555 "Prune Pending" (PP) } 557 Per downstream (Port, S, G, rpt, N): 558 - Prune Pending Timer (PPT(N)) 559 - Join Expiry Timer (ET(N)) 561 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 563 Where S is the address of the multicast source, G is the Group 564 address and N is the upstream neighbor field in the Join/Prune 565 message. Notice that unlike on PIM-SM routers where PPT and ET are 566 per (Interface, S, G), PIM Snooping switches have to maintain PPT and 567 ET per (Port, S, G, N). The reasons for this are explained in section 568 3.3.2. 570 Apart from the above states, we define the following state 571 summarization macros. 573 UpstreamNeighbors(*,G): If there is one or more Join(*,G) received on 574 any port with upstream neighbor N and ET(N) is active, then N is 575 added to UpstreamNeighbors(*,G). This set is used to determine if a 576 Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent 577 upstream. 579 UpstreamNeighbors(S,G): If there is one or more Join(S,G) received on 580 any port with upstream neighbor N and ET(N) is active, then N is 581 added to UpstreamNeighbors(S,G). This set is used to determine if a 582 Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent 583 upstream. 585 UpstreamPorts(G): This is the set of all ports on which the Upstream 586 Neighbors in UpstreamNeighbors(*,G) and the UpstreamNeighbors(S,G) 587 for the given G are learnt. This set is used in section 3.3.8. to 588 determine the ports on which Join/Prune messages must be sent. Data 589 traffic MUST also be forwarded to these ports to facilitate assert 590 election in the VPLS. 592 PWPorts: This is the set of all PWs. 594 OutgoingPortList(*,G): This is the set of all ports to which traffic 595 needs to be forwarded on a (*,G) match. Split Horizon rules apply as 596 noted in section 3.8. 598 OutgoingPortList(S,G): This is the set of all ports to which traffic 599 needs to be forwarded on an (S,G) match. Split Horizon rules apply as 600 noted in section 3.8. 602 NumETsActive(Port,*,G): Number of (Port,*,G,N) entries that have 603 Expiry Timer running. This macro keeps track of the number of 604 Join(*,G)s that are received on this Port with different upstream 605 neighbors. 607 NumETsActive(Port,S,G): Number of (Port,S,G,N) entries that have 608 Expiry Timer running. This macro keeps track of the number of 609 Join(*,G)s that are received on this Port with different upstream 610 neighbors. 612 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 614 JoinAttributes(*,G): Join attributes [PIM-JOIN-ATTR] are TLVs that 615 may be present in received Join(*,G) messages. If present, they must 616 be copied to JoinAttributes(*,G). 618 JoinAttributes(S,G): Join attributes [PIM-JOIN-ATTR] are TLVs that 619 may be present in received Join(S,G) messages. If present, they must 620 be copied to JoinAttributes(S,G). 622 Since there are a few differences between the downstream state 623 machines of PIM-SM Routers and PIM-SM snooping switches, we specify 624 the details of the downstream state machine of PIM-SM snooping 625 switches at the risk of repeating most of the text documented in 626 [PIM-SM]. 628 3.3.2. Explaination for per (S,G,N) states 630 In PIM Routing protocols, states are built per (S,G). On a router, an 631 (S,G) has only one RPF-Neighbor. However, a PIM Snooping switch does 632 not have the Layer 3 routing information available to the routers in 633 order to determine the RPF-Neighbor for a multicast flow. It merely 634 discovers it by snooping the Join/Prune message. A PE could have 635 snooped on two or more different Join/Prune messages for the same 636 (S,G) that could have carried different Upstream-Neighbor fields. 637 This could happen during transient network conditions or due to dual- 638 homed sources. A PE cannot make assumptions on which one to pick, but 639 instead must facilitate the CE routers decide which Upstream Neighbor 640 gets elected the RPF-Neighbor. And for this purpose, the PE will have 641 to track downstream and upstream Join/Prune states per (S,G,N). 643 3.3.3. Receiving (*,G) PIM-SM Join/Prune Messages 645 A Join(*,G) or Prune(*,G) is "received" when the port on which it was 646 received is not also the port on which the upstream-neighbor N of the 647 Join/Prune(*,G) was learnt. 649 When a router receives a Join(*,G) or a Prune(*,G) with upstream 650 neighbor N, it must process the message as defined in the state 651 machine below. Note that the macro computations of the various macros 652 resulting from this state machine transition is exactly as specified 653 in the PIM-SM RFC [PIM-SM]. 655 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 657 We define the following per-port (*,G,N) macro to help with the state 658 machine below. 660 Figure 1: Downstream per-port (*,G) state machine in tabular form 662 +---------------++----------------------------------------+ 663 | || Previous State | 664 | ++------------+--------------+------------+ 665 | Event ||NoInfo (NI) | Join (J) | Prune-Pend | 666 +---------------++------------+--------------+------------+ 667 | Receive ||-> J state | -> J state | -> J state | 668 | Join(*,G) || Action | Action | Action | 669 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 670 +---------------++------------+--------------+------------+ 671 |Receive || - | -> PP state | -> PP state| 672 |Prune(*,G) and || | Start PPT(N) | | 673 |NumETsActive<=1|| | | | 674 +---------------++------------+--------------+------------+ 675 |Receive || - | -> J state | - | 676 |Prune(*,G) and || | Start PPT(N) | | 677 NumETsActive>1 || | | | 678 +---------------++------------+--------------+------------+ 679 |PPT(N) expires || - | -> J state | -> NI state| 680 | || | Action | Action | 681 | || | PPTExpiry(N) |PPTExpiry(N)| 682 +---------------++------------+--------------+------------+ 683 |ET(N) expires || - | -> NI state | -> NI state| 684 |and || | Action | Action | 685 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)| 686 +---------------++------------+--------------+------------+ 687 |ET(N) expires || - | -> J state | -> NI state| 688 |and || | Action | Action | 689 |NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)| 690 +---------------++------------+--------------+------------+ 692 Action RxJoin(N): 694 If ET(N) is not already running, then start ET(N). Otherwise restart 695 ET(N). 696 If N is not already in UpstreamNeighbors(*,G), then add N to 697 UpstreamNeighbors(*,G) and trigger a Join(*,G) with upstream neighbor 698 N to be forwarded upstream as specified in section 3.3.8. 699 Record N as RPF_Neighbor(*,G). 700 If there are Join Attributes in the received (S,G) message and if the 701 Join Attributes are different from the recorded JoinAttributes(S,G), 702 then copy them into JoinAttributes(S,G). Also trigger a Join(S,G) 703 with upstream neighbor N to be forwarded upstream as specified in 704 section 3.3.8. 706 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 708 Action PPTExpiry(N): 710 Disable timers ET(N) and PPT(N). If there are no other (Port,*,G) 711 states with NumETsActive(Port,*,G) > 0, then trigger a Prune(*,G) 712 with upstream neighbor N to be forwarded upstream as specified in 713 section 3.3.8. Then delete N from UpstreamNeighbors(*,G). 715 Send a Prune-Echo(*,G) with upstream-neighbor N on the downstream 716 port. 718 Action ETExpiry(N): 720 Disable timers ET(N) and PPT(N). If there are no other (Port,*,G) 721 states with NumETsActive(Port,*,G) > 0, then trigger a Prune(*,G) 722 with upstream neighbor N to be forwarded upstream as specified in 723 section 3.3.8. Then delete N from UpstreamNeighbors(*,G). 725 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 727 3.3.4. Receiving (S,G) PIM-SM Join/Prune Messages 729 A Join(S,G) or Prune(S,G) is "received" when the port on which it was 730 received is not also the port on which the upstream-neighbor N of the 731 Join/Prune(S,G) was learnt. 733 When a router receives a Join(S,G) or a Prune(S,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 macros 736 resulting from this state machine transition is exactly as specified 737 in the PIM-SM RFC [PIM-SM]. 739 Figure 2: Downstream per-port (S,G) state machine in tabular form 740 +---------------++----------------------------------------+ 741 | || Previous State | 742 | ++------------+--------------+------------+ 743 | Event ||NoInfo (NI) | Join (J) | Prune-Pend | 744 +---------------++------------+--------------+------------+ 745 | Receive ||-> J state | -> J state | -> J state | 746 | Join(S,G) || Action | Action | Action | 747 | || RxJoin(N) | RxJoin(N) | RxJoin(N) | 748 +---------------++------------+--------------+------------+ 749 |Receive || - | -> PP state | -> PP state| 750 |Prune (S,G) and|| | Start PPT(N) | | 751 |NumETsActive<=1|| | | | 752 +---------------++------------+--------------+------------+ 753 |Receive || - | -> J state | - | 754 |Prune(S,G) and || | Start PPT(N) | | 755 NumETsActive>1 || | | | 756 +---------------++------------+--------------+------------+ 757 |PPT(N) expires || - | -> J state | -> NI state| 758 | || | Action | Action | 759 | || | PPTExpiry(N) |PPTExpiry(N)| 760 +---------------++------------+--------------+------------+ 761 |ET(N) expires || - | -> NI state | -> NI state| 762 |and || | Action | Action | 763 |NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N)| 764 +---------------++------------+--------------+------------+ 765 |ET(N) expires || - | -> J state | -> NI state| 766 |and || | Action | Action | 767 |NumETsActive>1 || | ETExpiry(N) | ETExpiry(N)| 768 +---------------++------------+--------------+------------+ 770 Action RxJoin(N): 772 If ET(N) is not already running, then start ET(N). Otherwise, restart 773 ET(N). 775 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 777 If N is not already in UpstreamNeighbors(S,G), then add N to 778 UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream neighbor 779 N to be forwarded upstream as specified in section 3.3.8. 780 Record N as RPF_Neighbor(S,G). 781 If there are Join Attributes in the received (S,G) message and if the 782 Join Attributes are different from the recorded JoinAttributes(S,G), 783 then copy them into JoinAttributes(S,G). Also trigger a Join(S,G) 784 with upstream neighbor N to be forwarded upstream as specified in 785 section 3.3.8. 787 Action PPTExpiry(N): 789 Disable timers ET(N) and PPT(N). If there are no other (Port,S,G) 790 states with NumETsActive(Port,S,G) > 0, then trigger a Prune(S,G) 791 with upstream neighbor N to be forwarded upstream as specified in 792 section 3.3.8. Then delete N from UpstreamNeighbors(S,G). 794 Send a Prune-Echo(S,G) with upstream-neighbor N on the downstream 795 port. 797 Action ETExpiry(N): 799 Disable timers ET(N) and PPT(N). If there are no other (Port,S,G) 800 states with NumETsActive(Port,S,G) > 0, then trigger a Prune(S,G) 801 with upstream neighbor N to be forwarded upstream as specified in 802 section 3.3.8. Then delete N from UpstreamNeighbors(S,G). 804 3.3.5. Receiving (S,G,rpt) Join/Prune Messages 806 A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on which 807 it was received is not also the port on which the upstream-neighbor N 808 of the Join/Prune(S,G,rpt) was learnt. 810 While it is important to ensure that the (S,G) and (*,G) state machines 811 allow for handling per (S,G,N) states, it is not as important for 812 (S,G,rpt) states. It suffices to say that the downstream (S,G,rpt) 813 state machine is the same as what is defined in section 4.5.4 of the 814 PIM-SM RFC [PIM-SM]. 816 3.3.6. Sending (*,G) Join/Prune Messages 818 A PIM Snooping PE MUST implement the Upstream (*,G) state machine for 819 which the procedures are similar to what is defined in section 4.5.6 820 of [PIM-SM]. Section 3.3.8. of this draft specifies how the message 821 should be sent. 823 For the purposes of the Upstream (*,G) state machine, a Join(*,G) or 824 Prune(*,G) message with upstream neighbor N is "seen" on a PIM 825 Snooping switch if the port on which the message was received is also 826 the port on which the upstream neighbor N was learnt. 828 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 830 3.3.7. Sending (S,G) Join/Prune Messages 832 A PIM Snooping PE MUST implement the Upstream (S,G) state machine for 833 which the procedures are similar to what is defined in section 4.5.6 834 of [PIM-SM]. Section 3.3.8. of this draft specifies how the message 835 should be sent. 837 For the purposes of the Upstream (S,G) state machine, a Join(*,G) or 838 Prune(*,G) message with upstream neighbor N is "seen" on a PIM 839 Snooping switch if the port on which the message was received is also 840 the port on which the upstream neighbor N was learnt. 842 3.3.8. Sending PIM Join/Prune message upstream. 844 The downstream Join/Prune state machines above describe when PIM 845 Join/Prune packets must be forwarded upstream and with what upstream 846 neighbor field. In order to correctly facilitate assert among the CE 847 routers, such Join/Prunes need to sent not only towards the upstream 848 neighbor, but also on certain PWs. 850 If JoinAttributes(*,G) is not empty, then it must be encoded in a 851 Join(*,G) message sent upstream. 853 If JoinAttributes(S,G) is not empty, then it must be encoded in a 854 Join(S,G) message sent upstream. 856 If the Join/Prune message being sent out is a refresh Join(*,G) 857 message, then send the refresh Join(*,G) on all ports in 858 UpstreamPorts(G). The Upstream Neighbor field should be the recorded 859 RPF_Neighbor(*,G). 861 If the Join/Prune message being sent out is a refresh Join(S,G) 862 message, then send the refresh Join(S,G) on all ports in 863 UpstreamPorts(G). The Upstream Neighbor field should be the recorded 864 RPF_Neighbor(S,G). 866 If the Join/Prune message being sent out is a triggered Join/Prune 867 message (due to an event in the downstream Join/Prune state machine), 868 then the following rules apply. These rules apply to both (S,G) and 869 (*,G) Join/Prune messages to be sent out: 870 - The upstream neighbor field N in the Join/Prune to be sent is 871 dictated by the downstream Join/Prune state machine 872 transition. 873 - If the downstream Join/Prune event was on an AC port, then 874 send the upstream Join/Prune message to all PWs in 875 UpstreamPorts(G). Send the Join/Prune message to Rport(N) 876 also. 877 - If the downstream Join/Prune event was on a PW port and if 878 Rport(N) is a PW, then silently discard the Join/Prune 880 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 882 message without sending it. If Rport(N) is an AC, then send 883 the Join/Prune message on that AC. 885 The source IP address in PIM packets sent upstream SHOULD be the 886 address of a PIM neighbor in the VPLS. The address picked MUST NOT be 887 the upstream neighbor field to be encoded in the packet. The layer 2 888 encapsulation for the selected source IP address MUST be the 889 encapsulation recorded in the PIM Neighbor database for that IP 890 address. 892 3.3.9. Triggering ASSERT Election in PIM-SM 894 In PIM-SM, there are scenarios where multiple routers could be 895 forwarding the same multicast traffic on a LAN. When this happens, 896 using PIM Assert Election process by sending PIM Assert Messages, 897 routers ensure that only the Assert Winner forwards traffic on the 898 LAN. In a typical LAN, the Assert Election is a data driven event and 899 happens only if a router sees traffic on the interface to which it 900 should be forwarding the traffic. Therefore, in the case of VPLS, in 901 order to trigger Assert Election and stop duplicate traffic, it is 902 necessary that two routers that are forwarding duplicate traffic for 903 an (S,G)/(*,G) see each other's traffic. 905 PIM Snooping switches must hence ensure that they not only forward 906 multicast traffic for an (S,G) on the ports on which they snooped 907 Joins(S,G)/Joins(*,G), but also on the ports on which such Joins were 908 forwarded (i.e. towards the upstream neighbor(s)). Traffic should not 909 be forwarded on the port on which it was received. So if two or more 910 Joins(S,G) each carrying a different upstream neighbor field were 911 snooped at a PE, then the ports on which such Joins were snooped 912 along with the ports on which the upstream neighbors were learnt must 913 be added to the outgoing port list. 915 VPLS Split Horizon Rules dictate that traffic arriving on a PW MUST 916 NOT be forwarded onto other PW(s). Let us consider the example in 917 Figure 3: So at a downstream PE (say PE1), if a Join(S,G) with 918 Upstream Neighbor N1 was sent on one PW (say PW12) and another 919 Join(S,G) with Upstream Neighbor N2 was sent on another PW (say 920 PW13), then duplicate traffic will arrive on both PW12 and PW13. Due 921 to VPLS Split Horizon Rules, traffic from PW12 cannot be forwarded 922 onto PW13 and vice-versa. However, as long as the upstream PEs (PE2 923 and PE3) also snoop on the Joins/Prunes, then per the rules in the 924 previous paragraph, they will add the PW towards both upstream 925 neighbors N1 and N2 to the outgoing port list. 927 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 929 Let us consider the scenario in Figure 3. 931 Figure 3: An Example Scenario for Triggering Assert 933 +------+ AC3 +------+ 934 | PE2 |-----| CE3 | 935 /| | | | 936 / +------+ +------+ 937 / | | 938 / | | 939 /PW12 | | 940 / | +-----+ 941 / |PW23 | S | 942 / | +-----+ 943 / | | 944 / | | 945 / | | 946 +------+ +------+ / +------+ +------+ 947 | CE1 | | PE1 |/ PW13 | PE3 | | CE4 | 948 | |-----| |-------------| |-----| | 949 +------+ AC1 +------+ +------+ AC4 +------+ 950 | 951 |AC2 952 +------+ 953 | CE2 | 954 | | 955 +------+ 957 In the scenario depicted in Figure 3, both CE1 and CE2 have two ECMP 958 routes to reach the source "S". Hence, CE1 may pick CE3 as its next 959 hop ("Upstream Neighbor"), and CE2 may pick CE4 as its next hop. As 960 a result, both CE1 and CE2 will receive duplicate traffic for a 961 moment. If Assert procedures are not invoked by CE3 and CE4, the 962 duplicate traffic on the LAN will persist forever. Following is the 963 sequence of events that illustrates how duplicate traffic is 964 resolved. Note that this illustration assumes PIM Snooping in the 965 VPLS with Join Suppression disabled on the CEs. Procedures for PIM 966 Proxy are slightly different and will be covered in section 3.6. 968 1. CE1 sends a Join(S,G) with N=CE3. 969 2. When PE1 snoops on the Join(S,G), it adds CE3 to its 970 UpstreamNeighbors(S,G). It also adds AC1 and PW12 to its 971 OutgoingPortList(S,G). UpstreamNeighbors(S,G) on PE1 = 972 {CE3}. OutgoingPortList(S,G) on PE1 = {AC1, PW12}. 973 3. PE1 floods the Join(S,G) in the VPLS. If using LDP (as 974 explained in [VPLS-MCAST-LDP]), PE1 also sends the Join(S,G) 975 via LDP on PW12 (the PW towards UpstreamNeighbors(S,G)). 977 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 979 4. When PE2 receives the Join(S,G), it adds CE3 to its 980 UpstreamNeighbors(S,G) and it also adds PW12 and AC3 to its 981 OutgoingPortList(S,G). UpstreamNeighbors(S,G) on PE2 = 982 {CE3}. OutgoingPortList(S,G) on PE2 = {PW12, AC3}. 984 The above is all that needs to occur in most cases where there is no 985 assert. 987 5. CE2 sends a Join(S,G) with N=CE4. 988 6. This results in PE1 adding CE4 to its 989 UpstreamNeighbors(S,G). It also adds AC2 and PW13 to its 990 OutgoingPortList(S,G). UpstreamNeighbors(S,G) at PE1 = 991 {CE3, CE4}. OutgoingPortList(S,G) on PE2 = {AC1, AC2, PW12, 992 PW13}. 993 7. PE1 floods the join in the VPLS. If using LDP, since the 994 Join was received on an AC AND since a neighbor was added 995 to UpstreamNeighbors(S,G), it sends a Join(S,G) via LDP on 996 the PWs towards UpstreamNeighbors(S,G) {PW12, PW13}. 997 8. PE2 receives the Join(S,G) and adds CE4 to 998 UpstreamNeighbors(S,G). It also adds PW23 to its 999 OutgoingPortList(S,G). UpstreamNeighbors(S,G) = {CE3, CE4}. 1000 OutgoingPortList(S,G) on PE2 = {PW12, AC3, PW23}. 1001 9. PE3 receives the Join(S,G) too. It adds CE4 to its 1002 UpstreamNeighbors(S,G). And it adds PW13 and AC4 to its 1003 OutgoingPortList(S,G). UpstreamNeighbors(S,G) = {CE4}. 1004 OutgoingPortList(S,G) on PE3 = {PW13, AC4}. 1006 So even before duplicate traffic starts flowing, the Outgoing 1007 interface list on the PEs are (i.e., the forwarding plane): 1009 PE1: {AC1, AC2, PW12, PW13} 1010 PE2: {PW12, AC3, PW23} 1011 PE3: {PW13, AC4} 1013 By building such a forwarding state when Joins are processed, there 1014 needs to be no additional action taken by the PEs when duplicate 1015 traffic is received. Traffic arriving from CE3 will be forwarded to 1016 CE4 thus allowing for CE3 and CE4 to transparently trigger assert 1017 election. This makes the PIM Snooping completely a control-plane 1018 protocol without any data-plane interaction. When the assert election 1019 is complete, if CE3 becomes the assert winner, then 1021 10. CE2 sends a Prune(S,G) with N=CE4 and a Join(S,G) with 1022 N=CE3. 1023 11. When PE1 snoops the Prune(S,G), it removes CE4 from its 1024 UpstreamNeighbors(S,G). It also removes AC2 and PW13 from 1025 the OutgoingPortList(S,G). The Join(S,G) will result in AC2 1026 added back to OutgoingPortList(S,G). OutgoingPortList(S,G) 1027 on PE1 = {AC1, AC2, PW12}. 1028 12. PE1 floods the messages in the VPLS. If LDP is used, 1029 since the Prune was received on an AC and since a neighbor 1030 was removed from UpstreamNeighbors(S,G), the Prune(S,G) 1032 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1034 will be sent on the PWs towards UpstreamNeighbors(S,G) 1035 {PW12, PW13}. The Join(S,G) need not be sent to {PW12} 1036 since the CE3 was already in UpstreamNeighbors(S,G). 1037 13. PE2 receives the Prune directed to CE4. As a result, PE2 1038 removes CE4 from its UpstreamNeighbors(S,G). It also 1039 removes PW23 from its OutgoingPortList(S,G). 1040 UpstreamNeighbors(S,G) on PE2 = {CE3}. 1041 OutgoingPortList(S,G) on PE2 = {PW12, AC3}. 1042 14. PE3 receives the Prune too. As a result, PE3 removes CE4 1043 from its UpstreamNeighbors(S,G). It also removes PW13 and 1044 AC4 from its OutgoingPortList(S,G). So, PE3 purges state 1045 for that (S,G). 1047 After assert election, the forwarding state should be: 1049 PE1: {AC1, PW12} 1050 PE2: {PW12, AC2} 1051 PE3: {} 1053 Other more complex duplicate traffic scenarios can exist due to the 1054 existence of (S,G) and/or (*,G) states and/or IGMP receiver states in 1055 a VPLS. The inheritance rules in PIM-SM and the rules specified in 1056 this draft should ensure that assert is triggered among the CEs in 1057 all scenarios. 1059 3.4. Bidirectional-PIM (PIM-BIDIR) 1060 PIM-BIDIR is a variation of PIM-SM. The main differences between 1061 PIM-SM and Bidirectional-PIM are as follows: 1062 - There are no source-based trees, and source-specific 1063 multicast is not supported (i.e., no (S,G) states) in PIM- 1064 BIDIR. 1065 - Multicast traffic can flow up the shared tree in PIM-BIDIR. 1066 - To avoid forwarding loops, one router on each link is elected 1067 as the Designated Forwarder (DF) for each RP in PIM-BIDIR. 1069 The main advantage of PIM-BIDIR is that it scales well for many-to- 1070 many applications. However, the lack of source-based trees means 1071 that multicast traffic is forced to remain on the shared tree. 1073 The procedures to discover PIM-SM routers in a VPLS instance are as 1074 described in section 3.2. For PIM-BIDIR to work properly, all 1075 routers within the domain must know the address of the RP. During RP 1076 discovery time, PIM routers elect DF per subnet for each RP. The 1077 algorithm to elect the DF is as follows: all PIM neighbors in a 1078 subnet advertise their unicast route to elect the RP and the router 1079 with the best route is elected. 1081 Snooping for PIM-BIDIR is much simpler than it is for PIM-SM. The 1082 complexity resulting from various combinations of (S,G), (*,G), IGMP 1084 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1086 and assert states makes PIM-SM procedures fairly complex. PIM-BIDIR 1087 has none of those issues since PIM-BIDIR builds only (*,G) states and 1088 all routers on a LAN agree on who the upstream neighbor, i.e. DF(RP) 1089 is. So the snooping procedures for PIM-BIDIR is very much like that 1090 on a PIM-BIDIR router [PIM-BIDIR]. 1092 3.4.1. Building PIM-BIDIR Snooping States 1093 The PEs MUST snoop on PIM-BIDIR Join/Prune messages and build states 1094 as described in [PIM-BIDIR]. The PEs SHOULD simply flood all other 1095 PIM packet types. Since there are no special procedures required for 1096 PIM-BIDIR snooping, we simply refer the reader to the [PIM-BIDIR] 1097 draft. 1099 3.5. PIM-DM 1100 The characteristics of PIM-DM is flood and prune behavior. Shortest 1101 path trees are built as a multicast source starts transmitting. 1103 The procedures to discover PIM-DM routers are as explained in section 1104 3.2. 1106 3.5.1. Building PIM-DM Snooping States 1108 PIM-DM Snooping states are built by snooping on the PIM-DM Join, 1109 Prune, Graft and State Refresh messages received on AC/PWs and State- 1110 Refresh Messages sent on AC/PWs. By snooping on these PIM-DM 1111 messages, a PE builds the following states per (S,G,N) where S is the 1112 address of the multicast source, G is the Group address and N is the 1113 upstream neighbor to which Prunes/Grafts are sent by downstream CEs: 1115 Per PIM (S,G,N): 1117 Per Port PIM (S,G,N) Prune State: 1118 - DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" 1119 (P), "PrunePending" (PP)} 1120 - Prune Pending Timer (PPT) 1121 - Prune Timer (PT) 1122 - Upstream Port (valid if the PIM(S,G,N) Prune State is 1123 "Pruned"). 1125 3.5.2. PIM-DM Downstream Per-Port PIM(S,G,N) State Machine 1127 The downstream per-port PIM(S,G,N) state machine is as defined in 1128 section 4.4.2 of [PIM-DM] with a few changes relevant to PIM 1129 Snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of 1130 PIM-Snooping please be aware that the downstream states are built per 1132 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1134 (S, G, N, Downstream-Port} in PIM-Snooping and not per {Downstream- 1135 Interface, S, G} as in a PIM-DM router. As noted in the previous 1136 section 3.5.1. , the states (DownstreamPState) and timers (PPT and 1137 PT) are per (S,G,N,P). 1139 3.5.3. Triggering ASSERT election in PIM-DM 1141 Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all 1142 routers unless explicitly pruned. Since PIM-DM routers do not prune 1143 on non-RPF interfaces, PEs should typically not receive Prunes on 1144 Rport(RPF-neighbor). So the asserting routers should typically be in 1145 pim_oiflist(S,G). In most cases, assert election should occur 1146 naturally without any special handling since data traffic will be 1147 forwarded to the asserting routers. 1149 However, there are some scenarios where a prune might be received on 1150 a port which is also an upstream port (UP). If we prune the port from 1151 pim_oiflist(S,G), then it would not be possible for the asserting 1152 routers to determine if traffic arrived on their downstream port. 1153 This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that 1154 data traffic flows to the UP ports. 1156 3.6. PIM Proxy 1158 As noted earlier in section 2.4. , PIM Snooping will work correctly 1159 only if Join Suppression is disabled in the VPLS. If Join Suppression 1160 is enabled in the VPLS, then PEs MUST do PIM Proxy for VPLS Multicast 1161 to work correctly. 1163 A PIM Proxy switch behaves like a PIM Router by doing most of the 1164 functionality of a PIM Router. The complexity however is much lesser 1165 on a switch since many of the issues that a PIM Router has to deal 1166 with are not relevant on a switch. A PIM Router needs to be able to 1167 build and maintain RP-Sets. They also have to deal with the Register 1168 and Assert State Machines. There are other complexities for a PIM 1169 Router resulting from inter-domain multicast. A PIM Snooping or PIM 1170 Proxy switch can be agnostic of all of this. All that a PIM Proxy 1171 switch cares about is building multicast states using PIM Hellos and 1172 PIM Join/Prune message. As such it's complexity is greatly reduced. 1174 Other than the procedures defined here, the rest of the procedures 1175 that apply to PIM Snooping apply to PIM Proxy as well. 1177 3.6.1. Downstream PIM Proxy behavior 1179 A PIM-SM or PIM-BIDIR Proxy PE is interested in the Hello and 1180 Join/Prune messages. The proposed PIM Proxy solution for PIM-SM and 1181 PIM-BIDIR is to proxy only Join/Prune messages. PIM Proxy for PIM-DM 1182 is for future study. 1184 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1186 PIM Hellos MUST be snooped while being flooded in the VPLS. 1188 PIM Join/Prune messages arriving at an AC MUST be consumed. If [VPLS- 1189 MCAST-LDP] is not used to distribute multicast states among the PEs, 1190 then PIM Join/Prune messages arriving at a PW MUST also be consumed. 1192 All other PIM packet types are flooded in the VPLS without needing 1193 observation. 1195 Performing only proxy of Join/Prune messages keeps the switch 1196 behavior very similar to that of a PIM router without introducing too 1197 much additional complexity. It keeps the PIM Proxy solution fairly 1198 simple. Since Join/Prunes are forwarded by a PE along the slow-path 1199 and all other PIM packet types are forwarded along the fast-path, it 1200 is very likely that packets forwarded along the fast-path will arrive 1201 "ahead" of Join/Prune packets at a CE router (note the stress on the 1202 fact that fast-path messages will never arrive after Join/Prunes). Of 1203 particular importance are Hello packets sent along the fast-path. We 1204 can construct a variety of scenarios resulting in out of order 1205 delivery of Hellos and Join/Prune messages. However, there should be 1206 no deviation from normal expected behavior observed at the CE router 1207 receiving these messages out of order. 1209 The other option for a PIM Proxy solution is to proxy both Hello and 1210 Join/Prune messages that a PE is interested in building states for. 1211 If Hellos are being proxied, then it becomes necessary that the PE 1212 proxy all other PIM packet types also. Because if Hellos are received 1213 after other packet types are received at a CE router, then bad things 1214 will happen. That means every PIM packet has to be sent along the 1215 slow-path. This greatly increases the complexity on the CE router, it 1216 is very compute intensive and does not scale well. Also, proxying 1217 Hellos will result in added latency to delivery of Hello messages to 1218 a CE and that affects multicast convergence in the VPLS. 1220 3.6.2. Upstream PIM Proxy behavior 1222 Since a PIM Proxy switch consumes Join/Prune messages, it must also 1223 originate PIM Join/Prune messages to be sent upstream. If [VPLS- 1224 MCAST-LDP] is employed, then triggered Join/Prune messages are sent 1225 via LDP to forward PIM Join/Prunes on PWs. Join/Prune messages need 1226 not be refreshed on PWs when [VPLS-MCAST-LDP] is employed. On ACs, 1227 both triggered and refresh Join/Prunes are forwarded as PIM packets. 1229 The source IP address in PIM packets sent upstream SHOULD be the 1230 address of a PIM neighbor in the VPLS. The address picked MUST NOT be 1231 the upstream neighbor field to be encoded in the packet. The layer 2 1232 encapsulation for the selected source IP address MUST be the 1233 encapsulation recorded in the PIM Neighbor database for that IP 1234 address. 1236 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1238 If Explicit Tracking is disabled in the VPLS, then it does not matter 1239 what Source IP Address is picked in the packets sent upstream as long 1240 as we adhere to the rule in the previous paragraph. However, if 1241 Explicit Tracking is enabled in the VPLS, then we cannot do this. In 1242 fact, it would be wrong to even enable PIM Proxy in the VPLS since 1243 the CE routers may wish to receive the Join/Prunes from every 1244 interested CE router. If a PE determines that Explicit Tracking is 1245 enabled in the VPLS, it MUST disable PIM Proxy and SHOULD follow PIM 1246 Snooping procedures instead. 1248 3.7. Directly Connected Multicast Source 1249 If there is a source in the CE network that connects directly into 1250 the VPLS instance, then multicast traffic from that source MUST be 1251 sent to all PIM routers on the VPLS instance apart from the igmp 1252 receivers in the VPLS. If there is already (S,G) or (*,G) snooping 1253 state that is formed on any PE, this will not happen per the current 1254 forwarding rules and guidelines. So, in order to determine if 1255 traffic needs to be flooded to all routers, a PE must be able to 1256 determine if the traffic came from a host on that LAN. There are 1257 three ways to address this problem: 1258 - The PE would have to do ARP snooping to determine if a source 1259 is directly connected. 1260 - Another option is to have configuration on all PEs to say 1261 there are CE sources that are directly connected to the VPLS 1262 instance and disallow snooping for the groups for which the 1263 source is going to send traffic. This way traffic from that 1264 source to those groups will always be flooded within the 1265 provider network. 1266 - A third option is to require that sources of CE multicast 1267 routers must appear behind a router. 1269 3.8. Data Forwarding Rules 1271 First we define the rules that are common to PIM-SM, PIM-BIDIR and 1272 PIM-DM PEs. Forwarding rules for each protocol type is specified in 1273 the sub-sections. 1275 If there is no matching forwarding state, then the PE MAY either 1276 discard the packet or send it towards all the snooped PIM CE routers 1277 or to a configured set of ports. How this is determined is outside 1278 the scope of this document. 1280 The following rules MUST be followed when forwarding multicast 1281 traffic in a VPLS: 1283 - Traffic arriving on a port MUST NOT be forwarded back onto 1284 the same port. 1286 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1288 - Due to VPLS Split-Horizon rules, traffic ingressing on a PW 1289 MUST NOT be forwarded to any other PW. 1291 3.8.1. PIM-SM Data Forwarding Rules 1293 Per the rules in [PIM-SM] and per the additional rules specified in 1294 this document, 1296 OutgoingPortList(*,G) = inherited_olist(*,G) (+) UpstreamPorts(G) 1297 (+) Rport(PimDR) 1299 OutgoingPortList(S,G) = inherited_olist(S,G) (+) UpstreamPorts(G) 1300 (+) Rport(PimDR) 1302 [PIM-SM] specifies how inherited_olist(*,G) and inherited_olist(S,G) 1303 are built. PimDR is the IP address of the PIM DR in the VPLS. 1305 The PIM-SM Snooping forwarding rules are defined below in pseudocode: 1307 BEGIN 1308 iif is the incoming port of the multicast packet. 1309 S is the Source IP Address of the multicast packet. 1310 G is the Destination IP Address of the multicast packet. 1312 If there is (S,G) state on the PE 1313 Then 1314 OutgoingPortList = OutgoingPortList(S,G) 1315 Else if there is (*,G) state on the PE 1316 Then 1317 OutgoingPortList = OutgoingPortList(*,G) 1318 Else 1319 OutgoingPortList = UserDefinedPortList 1320 Endif 1322 If iif is an AC 1323 Then 1324 OutgoingPortList = OutgoingPortList (-) iif 1325 Else 1326 ## iif is a PW 1327 OutgoingPortList = OutgoingPortList (-) PWPorts 1328 Endif 1330 Forward the packet to OutgoingPortList. 1331 END 1333 First if there is (S,G) state on the PE, then the set of outgoing 1334 ports is OutgoingPortList(S,G). 1336 Otherwise if there is (*,G) state on the PE, the set of outgoing 1337 ports is OutgoingPortList(*,G). 1339 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1341 The packet is forwarded to the selected set of outgoing ports while 1342 observing the rules above in section 3.8. 1344 3.8.2. PIM-BIDIR Data Forwarding Rules 1346 The PIM-BIDIR Snooping forwarding rules are defined below in 1347 pseudocode: 1349 BEGIN 1350 iif is the incoming port of the multicast packet. 1351 G is the Destination IP Address of the multicast packet. 1353 If there is forwarding state for G 1354 Then 1355 OutgoingPortList = olist(G) 1356 Else 1357 OutgoingPortList = UserDefinedPortList 1358 Endif 1360 If iif is an AC 1361 Then 1362 OutgoingPortList = OutgoingPortList (-) iif 1363 Else 1364 ## iif is a PW 1365 OutgoingPortList = OutgoingPortList (-) PWPorts 1366 Endif 1368 Forward the packet to OutgoingPortList. 1369 END 1371 If there is forwarding state for G, then forward the packet to 1372 olist(G) while observing the rules above in section 3.8. 1374 [PIM-BIDIR] specifies how olist(G) is contructed. 1376 3.8.3. PIM-DM Data Forwarding Rules 1378 The PIM-DM Snooping data forwarding rules are defined below in 1379 pseudocode: 1381 BEGIN 1382 iif is the incoming port of the multicast packet. 1383 S is the Source IP Address of the multicast packet. 1384 G is the Destination IP Address of the multicast packet. 1386 If there is (S,G) state on the PE 1387 Then 1388 OutgoingPortList = olist(S,G) 1389 Else 1390 OutgoingPortList = UserDefinedPortList 1392 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1394 Endif 1396 If iif is an AC 1397 Then 1398 OutgoingPortList = OutgoingPortList (-) iif 1399 Else 1400 ## iif is a PW 1401 OutgoingPortList = OutgoingPortList (-) PWPorts 1402 Endif 1404 Forward the packet to OutgoingPortList. 1405 END 1407 If there is forwarding state for (S,G), then forward the packet to 1408 olist(S,G) while observing the rules above in section 3.8. 1410 [PIM-DM] specifies how olist(S,G) is contructed. 1412 4. IANA Considerations 1413 This document does not require any IANA assignments or action. 1415 5. Security Considerations 1417 Security considerations provided in VPLS solution documents (i.e., 1418 [VPLS-LDP] and [VPLS-BGP) apply to this document as well. 1420 6. References 1422 6.1. Normative References 1424 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1425 Requirement Levels", BCP 14, RFC 2119, March 1997. 1426 [PIM-DM] Deering, S., et al. "Protocol Independent Multicast 1427 Version 2 - Dense Mode Specification", RFC 3973, 1428 January 2005. 1429 [PIM-SM] Fenner, W, et al. "Protocol Independent Multicast- 1430 Sparse Mode (PIM-SM): Protocol Specification 1431 (Revised)", draft-ietf-pim-sm-v2-new-11.txt, April 1432 2005. 1433 [PIM-SSM] Holbrook, H., et al. "Source-Specific Multicast for 1434 IP", work in progress 1435 [PIM-BIDIR] Handley, M., et al. "Bi-directional Protocol 1436 Independent Multicast (BIDIR-PIM)", work in 1437 progress 1438 [PIM-JOIN-ATTR] Boers, A, et al, "Format for using TLVs in PIM 1439 messages", draft-ietf-pim-join-attributes-01.txt, 1440 Work in progress 1442 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1444 6.2. Informative References 1446 [VPLS-LDP] Lasserre, M, et al. "Virtual Private LAN Services 1447 over MPLS", work in progress 1448 [VPLS-BGP] Kompella, K, et al. "Virtual Private LAN Service", 1449 work in progress 1450 [IGMP-SNOOP] Christensen, M., et al. "Considerations for IGMP 1451 and MLD Snooping Switches", work in progress 1452 [VPLS-MCAST-LDP] Qui, R, Serbest, Y, et al, "Using LDP for VPLS 1453 Multicast", draft-qiu-serbest-vpls-mcast-ldp-00.txt, 1454 Work in progress 1455 [VPLS-MCAST-BGP] Aggarwal, R, et al, "Propagation of VPLS IP 1456 Multicast Group Membership Information", draft- 1457 raggarwa-l2vpn-vpls-mcast-ctrl-00.txt, Work in 1458 progress 1459 [VPLS-MCAST-TREES] Aggarwal, R, et al. "Multicast in VPLS", 1460 draft-raggarwa-l2vpn-vpls-mcast-01.txt, 1461 Work in progress. 1463 Authors' Addresses 1465 Venu Hemige 1466 Alcatel North America 1467 701 East Middlefield Rd. 1468 Mountain View, CA 94043 1469 Venu.hemige@alcatel.com 1471 Yetik Serbest 1472 AT&T Labs 1473 9505 Arboretum Blvd. 1474 Austin, TX 78759 1475 Yetik_serbest@labs.sbc.com 1477 Ray Qiu 1478 Alcatel North America 1479 701 East Middlefield Rd. 1480 Mountain View, CA 94043 1481 Ray.Qiu@alcatel.com 1483 Suresh Boddapati 1484 Alcatel North America 1485 701 East Middlefield Rd. 1486 Mountain View, CA 94043 1487 Suresh.boddapati@alcatel.com 1489 Rob Nath 1490 Riverstone Networks 1491 5200 Great America Parkway 1492 Santa Clara, CA 95054 1493 Rnath@riverstonenet.com 1495 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1497 Sunil Khandekar 1498 Alcatel North America 1499 701 East Middlefield Rd. 1500 Mountain View, CA 94043 1501 Sunil.khandekar@alcatel.com 1503 Vach Kompella 1504 Alcatel North America 1505 701 East Middlefield Rd. 1506 Mountain View, CA 94043 1507 Vach.kompella@alcatel.com 1509 Marc Lasserre 1510 Riverstone Networks 1511 Marc@riverstonenet.com 1513 Himanshu Shah 1514 Ciena 1515 hshah@ciena.com 1517 Intellectual Property Statement 1519 The IETF takes no position regarding the validity or scope of any 1520 Intellectual Property Rights or other rights that might be claimed to 1521 pertain to the implementation or use of the technology described in 1522 this document or the extent to which any license under such rights 1523 might or might not be available; nor does it represent that it has 1524 made any independent effort to identify any such rights. Information 1525 on the procedures with respect to rights in RFC documents can be 1526 found in BCP 78 and BCP 79. 1528 Copies of IPR disclosures made to the IETF Secretariat and any 1529 assurances of licenses to be made available, or the result of an 1530 attempt made to obtain a general license or permission for the use of 1531 such proprietary rights by implementers or users of this 1532 specification can be obtained from the IETF on-line IPR repository at 1533 http://www.ietf.org/ipr. 1535 The IETF invites any interested party to bring to its attention any 1536 copyrights, patents or patent applications, or other proprietary 1537 rights that may cover technology that may be required to implement 1538 this standard. Please address the information to the IETF at ietf- 1539 ipr@ietf.org. 1541 Full copyright statement 1543 Copyright (C) The Internet Society (2006). 1545 This document is subject to the rights, licenses and restrictions 1546 contained in BCP 78, and except as set forth therein, the authors 1547 retain all their rights. 1549 Draft draft-ietf-l2vpn-vpls-pim-snooping-00.txt Nov, 2005 1551 This document and the information contained herein are provided on an 1552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.