idnits 2.17.1 draft-ietf-pim-drlb-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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2014) is 3547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yiqun Cai 3 Internet-Draft Microsoft 4 Intended status: Standards Track Sri Vallepalli 5 Expires: January 4, 2015 Heidi Ou 6 Cisco Systems, Inc. 7 Andy Green 8 British Telecom 9 July 3, 2014 11 PIM Designated Router Load Balancing 12 draft-ietf-pim-drlb-05.txt 14 Abstract 16 On a multi-access network, one of the PIM routers is elected as a 17 Designated Router (DR). On the last hop network, the PIM DR is 18 responsible for tracking local multicast listeners and forwarding 19 traffic to these listeners if the group is operating in PIM-SM. In 20 this document, we propose a modification to the PIM-SM protocol that 21 allows more than one of these last hop routers to be selected so that 22 the forwarding load can be distributed among these routers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. GDR Candidates . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Hash Mask and Hash Algorithm . . . . . . . . . . . . . . 7 64 4.3. Modulo Hash Algorithm . . . . . . . . . . . . . . . . . . 8 65 4.4. PIM Hello Options . . . . . . . . . . . . . . . . . . . . 9 66 5. Hello Option Formats . . . . . . . . . . . . . . . . . . . . 9 67 5.1. PIM DR Load Balancing Capability (DRLBC) Hello Option . . 9 68 5.2. PIM DR Load Balancing GDR (DRLBGDR) Hello Option . . . . 10 69 6. Protocol Specification . . . . . . . . . . . . . . . . . . . 11 70 6.1. PIM DR Operation . . . . . . . . . . . . . . . . . . . . 11 71 6.2. PIM GDR Candidate Operation . . . . . . . . . . . . . . . 12 72 6.3. PIM Assert Modification . . . . . . . . . . . . . . . . . 12 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 With respect to PIM, this document follows the terminology that has 88 been defined in [RFC4601]. 90 This document also introduces the following new acronyms: 92 o GDR: GDR stands for "Group Designated Router". For each multicast 93 flow, either a (*,G) for ASM, or an (S,G) for SSM, a hash 94 algorithm (described below) is used to select one of the routers 95 as a GDR. The GDR is responsible for initiating the forwarding 96 tree building for the corresponding multicast flow. 98 o GDR Candidate: a last hop router that has potential to become a 99 GDR. A GDR Candidate must have the same DR priority and must run 100 the same GDR election hash algorithm as the DR router. It must 101 send and process new PIM Hello Options as defined in this 102 document. There might be more than one GDR Candidate on a LAN. 103 But only one can become GDR for a specific multicast flow. 105 2. Introduction 107 On a multi-access network such as an Ethernet, one of the PIM routers 108 is elected as a DR. The PIM DR has two roles in the PIM-SM protocol. 109 On the first hop network, the PIM DR is responsible for registering 110 an active source with the Rendezvous Point (RP) if the group is 111 operating in PIM-SM. On the last hop network, the PIM DR is 112 responsible for tracking local multicast listeners and forwarding to 113 these listeners if the group is operating in PIM-SM. 115 Consider the following last hop network in Figure 1: 117 ( core networks ) 118 | | | 119 | | | 120 R1 R2 R3 121 | | | 122 --(last hop LAN)-- 123 | 124 | 125 (many receivers) 127 Figure 1: Last Hop Network 129 Assume R1 is elected as the Designated Router. According to 130 [RFC4601], R1 will be responsible for forwarding traffic to that LAN 131 on behalf of any local members. In addition to keeping track of IGMP 132 and MLD membership reports, R1 is also responsible for initiating the 133 creation of source and/or shared trees towards the senders or the 134 RPs. 136 Forcing sole data plane forwarding responsibility on the PIM DR 137 proves a limitation in the protocol. In comparison, even though an 138 OSPF DR, or an IS-IS DIS, handles additional duties while running the 139 OSPF or IS-IS protocols, they are not required to be solely 140 responsible for forwarding packets for the network. On the other 141 hand, on a last hop LAN, only the PIM DR is asked to forward packets 142 while the other routers handle only control traffic (and perhaps drop 143 packets due to RPF failures). The forwarding load of a last hop LAN 144 is concentrated on a single router. 146 This leads to several issues. One of the issues is that the 147 aggregated bandwidth will be limited to what R1 can handle towards 148 this particular interface. These days, it is very common that the 149 last hop LAN usually consists of switches that run IGMP/MLD or PIM 150 snooping. This allows the forwarding of multicast packets to be 151 restricted only to segments leading to receivers who have indicated 152 their interest in multicast groups using either IGMP or MLD. The 153 emergence of the switched Ethernet allows the aggregated bandwidth to 154 exceed, some times by a large number, that of a single link. For 155 example, let us modify Figure 1 and introduce an Ethernet switch in 156 Figure 2. 158 ( core networks ) 159 | | | 160 | | | 161 R1 R2 R3 162 | | | 163 +=gi0===gi1===gi2=+ 164 + + 165 + switch + 166 + + 167 +=gi4===gi5===gi6=+ 168 | | | 169 H1 H2 H3 171 Figure 2: Last Hop Network with Ethernet Switch 173 Let us assume that each individual link is a Gigabit Ethernet. Each 174 router, R1, R2 and R3, and the switch have enough forwarding capacity 175 to handle hundreds of Gigabits of data. 177 Let us further assume that each of the hosts requests 500 Mbps of 178 data and different traffic is requested by each host. This 179 represents a total 1.5 Gbps of data, which is under what each switch 180 or the combined uplink bandwidth across the routers can handle, even 181 under failure of a single router. 183 On the other hand, the link between R1 and switch, via port gi0, can 184 only handle a throughput of 1Gbps. And if R1 is the only router, the 185 PIM DR elected using the procedure defined by [RFC4601], at least 500 186 Mbps worth of data will be lost because the only link that can be 187 used to draw the traffic from the routers to the switch is via gi0. 189 In other words, the entire network's throughput is limited by the 190 single connection between the PIM DR and the switch (or the last hop 191 LAN as in Figure 1). 193 The problem may also manifest itself in a different way. For 194 example, R1 happens to forward 500 Mbps worth of unicast data to H1, 195 and at the same time, H2 and H3 each requests 300 Mbps of different 196 multicast data. Once again packet drop happens on R1 while in the 197 mean time, there is sufficient forwarding capacity left on R2 and R3 198 and link capacity between the switch and R2/R3. 200 Another important issue is related to failover. If R1 is the only 201 forwarder on the last hop network, in the event of a failure when R1 202 goes out of service, multicast forwarding for the entire network has 203 to be rebuilt by the newly elected PIM DR. However, if there was a 204 way that allowed multiple routers to forward to the network for 205 different groups, failure of one of the routers would only lead to 206 disruption to a subset of the flows, therefore improving the overall 207 resilience of the network. 209 In this document, we propose a modification to the PIM-SM protocol 210 that allows more than one of these routers, called Group Designated 211 Router (GDR) to be selected so that the forwarding load can be 212 distributed among a number of routers. 214 3. Applicability 216 The proposed change described in this specification applies to PIM-SM 217 last hop routers only. 219 It does not alter the behavior of a PIM DR on the first hop network 220 This is because the source tree is built using the IP address of the 221 sender, not the IP address of the PIM DR that sends the registers 222 towards the RP. The load balancing between first hop routers can be 223 achieved naturally if an IGP provides equal cost multiple paths 224 (which it usually does in practice). And distributing the load to do 225 registering does not justify the additional complexity required to 226 support it. 228 4. Functional Overview 230 In the existing PIM DR election, when multiple last hop routers are 231 connected to a multi-access network (for example, an Ethernet), one 232 of them is selected to act as PIM DR. The PIM DR is responsible for 233 sending local Join/Prune messages towards the RP or source. To elect 234 the PIM DR, each PIM router on the network examines the received PIM 235 Hello messages and compares its DR priority and IP address with those 236 of its neighbors. The router with the highest DR priority is the PIM 237 DR. If there are multiple such routers, their IP addresses are used 238 as the tie-breaker, as described in [RFC4601]. 240 In order to share forwarding load among last hop routers, besides the 241 normal PIM DR election, the GDR is also elected on the last hop 242 multi-access network. There is only one PIM DR on the multi-access 243 network, but there might be multiple GDR Candidates. 245 For each multicast flow, that is (*,G) for ASM and (S,G) for SSM, a 246 hash algorithm is used to select one of the routers to be the GDR. A 247 new DR Load Balancing Capability (DRLBC) PIM Hello Option, which 248 contains hash algorithm type, is announced by routers on interfaces 249 where this specification is enabled. Last hop routers with the new 250 DRLBC Option advertised in its Hello, and using the same GDR election 251 hash algorithm and the same DR priority as the PIM DR, are considered 252 as GDR Candidates. 254 Hash Masks are defined for Source, Group and RP separately, in order 255 to handle PIM ASM/SSM. The masks, as well as a sorted list of GDR 256 Candidates' Addresses are announced by DR in a new DR Load Balancing 257 GDR (DRLBGDR) PIM Hello Option. 259 For each multicast flow, a hash algorithm is used to select one of 260 the routers to be the GDR. Hash Masks are defined for Source, Group 261 and RP separately, in order to handle PIM ASM/SSM. The masks are 262 announced in PIM Hello by DR as a DR Load Balancing GDR (DRLBGDR) 263 Hello Option. Besides that, a DR Load Balancing Capability (DRLBC) 264 Hello Option, which contains hash algorithm type, is also announced 265 by the router on interfaces where this specification is enabled. 266 Last hop routers with the new DRLBC Option advertised in its Hello, 267 and using the same GDR election hash algorithm and the same DR 268 priority as the PIM DR, are considered as GDR Candidates. 270 A hash algorithm based on the announced Source, Group or RP masks 271 allows one GDR to be assigned to a corresponding multicast state. 272 And that GDR is responsible for initiating the creation of the 273 multicast forwarding tree for multicast traffic. 275 4.1. GDR Candidates 277 GDR is the new concept introduced by this specification. GDR 278 Candidates are routers eligible for GDR election on the LAN. To 279 become a GDR Candidate, a router MUST support this specification, 280 have the same DR priority and run the same GDR election hash 281 algorithm as the DR on the LAN. 283 For example, assume there are 4 routers on the LAN: R1, R2, R3 and 284 R4, which all support this specification on the LAN. R1, R2 and R3 285 have the same DR priority while R4's DR priority is less preferred. 286 In this example, R4 will not be eligible for GDR election, because R4 287 will not become a PIM DR unless all of R1, R2 and R3 go out of 288 service. 290 Further assume router R1 wins the PIM DR election, and R1, R2 run the 291 same hash algorithm for GDR election, while R3 runs a different one. 292 Then only R1 and R2 will be eligible for GDR election, R3 will not. 294 As a DR, R1 will include its own Load Balancing Hash Masks, and also 295 the identity of R1 and R2 (the GDR Candidates) in its DRLBGDR Hello 296 Option. 298 4.2. Hash Mask and Hash Algorithm 300 A Hash Mask is used to extract a number of bits from the 301 corresponding IP address field (32 for v4, 128 for v6), and calculate 302 a hash value. A hash value is used to select a GDR from GDR 303 Candidates advertised by PIM DR. For example, 0.0.255.0 defines a 304 Hash Mask for an IPv4 address that masks the first, the second and 305 the fourth octets. 307 There are three Hash Masks defined, 309 o RP Hash Mask 311 o Source Hash Mask 313 o Group Hash Mask 315 The Hash Masks MUST be configured on the PIM routers that can 316 potentially become a PIM DR. 318 o If the group is ASM, and if the RP Hash Mask announced by the PIM 319 DR is not 0, calculate the value of hashvalue_RP to determine GDR. 321 o If the group is ASM and if the RP Hash Mask announced by the PIM 322 DR is 0, obtain the value of hashvalue_Group to to determine GDR. 324 o If the group is SSM, use hashvalue_SG to determine GDR. 326 A simple Modulo hash algorithm will be discussed in this document. 327 However, to allow other hash algorithm to be used, a 4-bytes "Hash 328 Algorithm Type" field is included in DRLBC Hello Option to specify 329 the hash algorithm used by a last hop router. 331 If different hash algorithm types are advertised among last hop 332 routers, only last hop routers running the same hash algorithm as the 333 DR (and having the same DR priority as the DR) are eligible for GDR 334 election. 336 4.3. Modulo Hash Algorithm 338 Modulo hash algorithm is discussed here as an example, with detailed 339 description on hashvalue_RP. 341 For ASM groups, with a non-zero RP_hash mask, hash value is 342 calculated as: 344 * hashvalue_RP = (((RP_address & RP_hashmask) >> N) & 0xFFFF) % M 346 RP_address is the address of the RP defined for the group. N is 347 the number of zeros, counted from the least significant bit of the 348 RP_hashmask. M is the number of GDR Candidates. 350 For example, Router X with IPv4 address 203.0.113.1, receives a 351 DRLBGDR Hello Option from the DR, which announces RP Hash Mask 352 0.0.255.0, and a list of GDR Candidates, sorted by IP addresses 353 from high to low, 203.0.113.3, 203.0.113.2 and 203.0.113.1. The 354 ordinal number assigned to those addresses would be: 356 0 for 203.0.113.3; 1 for 203.0.113.2; 2 for 203.0.113.1 (Router X) 358 Assume there are 2 RPs: RP1 192.0.2.1 for Group1 and RP2 359 198.51.100.2 for Group2. Following the modulo hash algorithm: 361 N is 8 for 0.0.255.0, and M is 3 for the total number of GDR 362 Candidates. The hashvalue_RP for RP1 192.0.2.1 is: 364 (((192.0.2.1 & 0.0.255.0) >> 8) & 0xFFFF % 3) = 2 % 3 = 2 366 matches the ordinal number assigned to Router X. Router X will be 367 the GDR for Group1, which uses 192.0.2.1 as the RP. 369 The hashvalue_RP for RP2 198.51.100.2 is: 371 (((198.51.100.2 & 0.0.255.0) >> 8) & 0xFFFF % 3) = 100 % 3 = 1 373 which is different from Router X's ordinal number 2, hence, Router 374 X will not be GDR for Group2. 376 If RP_hashmask is 0, a hash value for ASM group is calculated using 377 the group Hash Mask: 379 * hashvalue_Group = (((Group_address & Group_hashmask) >> N) & 380 0xFFFF) % M 382 Compare hashvalue_Group with Ordinal number assigned to Router X, 383 to decide if Router X is the GDR. 385 For SSM groups, a hash value is calculated using both the source and 386 group Hash Mask 388 * hashvalue_SG = ((((Source_address & Source_hashmask) >> N_S) & 389 0xFFFF) ^ (((Group_address & Group_hashmask) >> N_G) & 0xFFFF)) 390 % M 392 4.4. PIM Hello Options 394 When a last hop PIM router sends a PIM Hello from an interface with 395 this specification enabled, it includes a new option, called "Load 396 Balancing Capability (DRLBC)". 398 Besides this DRLBC Hello Option, the elected PIM DR also includes a 399 new "DR Load Balancing GDR (DRLBGDR) Hello Option". The DRLBGDR 400 Hello Option consists of three Hash Masks as defined above and also 401 the sorted list of all GDR Candidates' Address on the last hop 402 network. 404 The elected PIM DR uses DRLBC Hello Option advertised by all routers 405 on the last hop network to compose its DRLBGDR . The GDR Candidates 406 use DRLBGDR Hello Option advertised by PIM DR to calculate hash 407 value. 409 5. Hello Option Formats 411 5.1. PIM DR Load Balancing Capability (DRLBC) Hello Option 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type = TBD | Length = 4 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Hash Algorithm Type | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 3: Capability Hello Option 422 Type: TBD. 424 Length: 4 octets 426 Hash Algorithm Type: 0 for Modulo hash algorithm 428 This DRLBC Hello Option SHOULD be advertised by last hop routers from 429 interfaces with this specification enabled. 431 5.2. PIM DR Load Balancing GDR (DRLBGDR) Hello Option 433 0 1 2 3 434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type = TBD | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Group Mask | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Source Mask | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | RP Mask | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | GDR Candidate Address(es) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 4: GDR Hello Option 449 Type: TBD 451 Length: 453 Group Mask (32/128 bits): Mask 455 Source Mask (32/128 bits): Mask 457 RP Mask (32/128 bits): Mask 459 All masks MUST be in the same address family as the Hello IP 460 header. 462 GDR Address (32/128 bits): Address(es) of GDR Candidate(s) 464 All addresses must be in the same address family as the Hello IP 465 header. The addresses are sorted from high to low. The order is 466 converted to the ordinal number associated with each GDR candidate 467 in hash value calculation. For example, addresses advertised are 468 R3, R2, R1, the ordinal number assigned to R3 is 0, to R2 is 1 and 469 to R1 is 2. 471 If "Interface ID" option, as described in [RFC6395], presents in a 472 GDR Candicate's PIM Hello message, and the "Router ID" portion is 473 non-zero, 475 * For IPv4, the "GDR Candidate Address" will be set directly to 476 "Router ID". 478 * For IPv6, the "GDR Candidate Address" will be set to the 479 IPv4-IPv6 translated address of "Router ID", as described in 480 [RFC4291], that is the "Router-ID" is appended to the prefix of 481 96-bits zeros. 483 If the "Interface ID" option is not present in a GDR Candidate's 484 PIM Hello message, or if the "Interface ID" option is present, 485 but"Router ID" field is zero, the "GDR Candidate Address" will be 486 the IPv4 or IPv6 source address from PIM Hello message. 488 This DRLBGDR Hello Option SHOULD only be advertised by the elected 489 PIM DR. 491 6. Protocol Specification 493 6.1. PIM DR Operation 495 The DR election process is still the same as defined in [RFC4601]. A 496 DR that has this specification enabled on the interface, advertises 497 the new LBGRD Hello Option, which contains value of masks from user 498 configuration, followed by a sorted list of all GDR Candidates' 499 Addresses, from high to low. Moreover, same as non-DR routers, DR 500 also advertises DRLBC Hello Option to indicate its capability of 501 supporting this specification and the type of its GDR election hash 502 algorithm. 504 If a PIM DR receives a PIM Hello with DRLBGRD Option, the PIM DR 505 SHOULD ignore the TLV. 507 If a PIM DR receives a neighbor DRLBC Hello Option, which contains 508 the same hash algorithm type as the DR, and the neighbor has the same 509 DR priority as the DR, PIM DR SHOULD consider the neighbor as a GDR 510 Candidate and insert the GDR Candidate's Address into the sorted list 511 of DRLBGRD Option. 513 6.2. PIM GDR Candidate Operation 515 When an IGMP/MLD join is received, without this proposal, only PIM DR 516 will handle the join and potentially run into the issues described 517 earlier. Using this proposal, a hash algorithm is used on GDR 518 Candidate to determine which router is going to be responsible for 519 building forwarding trees on behalf of the host. 521 A router interface where this protocol is enabled advertises DRLBC 522 Hello Option in its PIM Hello, even if the router may not be 523 considered as a GDR Candidate, for example, due to low DR priority. 525 A GDR Candidate may receive a DRLBGDR Hello Option from PIM DR, with 526 different Hash Masks from those configured on it, The GDR Candidate 527 must use the Hash Masks advertised by the PIM DR to calculate the 528 hash value. 530 A GDR Candidate may receive a DRLBGDR Hello Option from a PIM router 531 which is not DR. The GDR Candidate must ignore such DRLBGDR Hello 532 Option. 534 A GDR Candidate may receive a Hello from the elected PIM DR, and the 535 PIM DR does not support this specification. The GDR election 536 described by this specification will not take place, that is only the 537 PIM DR joins the multicast tree. 539 6.3. PIM Assert Modification 541 It is possible that the identity of the GDR might change in the 542 middle of an active flow. Examples this could happen include: 544 o When a new PIM router comes up 546 o When a GDR restarts 547 When the GDR changes, existing traffic might be disrupted. 548 Duplicates or packet loss might be observed. To illustrate the case, 549 consider the following scenario: there are two streams G1 and G2. R1 550 is the GDR for G1, and R2 is the GDR for G2. When R3 comes up 551 online, it is possible that R3 becomes GDR for both G1 and G2, hence 552 R3 starts to build the forwarding tree for G1 and G2. If R1 and R2 553 stop forwarding before R3 completes the process, packet loss might 554 occur. On the other hand, if R1 and R2 continue forwarding while R3 555 is building the forwarding trees, duplicates might occur. 557 This is not a typical deployment scenario but it still might happen. 558 Here we describe a mechanism to minimize the impact. The motivation 559 is that we want to minimize packet loss. And therefore, we would 560 allow a small amount of duplicates and depend on PIM Assert to 561 minimize the duplication. 563 When the role of GDR changes as above, instead of immediately 564 stopping forwarding, R1 and R2 continue forwarding to G1 and G2 565 respectively, while at the same time, R3 build forwarding trees for 566 G1 and G2. This will lead to PIM Asserts. 568 Due to the introduction of GDR, this document suggests the following 569 modification to the Assert packet: if a router enables this 570 specification on its downstream interface, but it is not a GDR, it 571 would adjust its Assert metric to (PIM_ASSERT_INFINITY - 1). 573 Using the above example, for G1, assume R1 and R3 agree on the new 574 GDR, which is R3. R1 will set its Assert metric as 575 (PIM_ASSERT_INFINITY - 1). That will make R3, which has normal 576 metric in its Assert as the Assert winner. 578 For G2, assume it takes a little bit longer time for R2 to find out 579 that R3 is the new GDR and still thinks itself being the GDR while R3 580 already has assumed the role of GDR. Since both R2 and R3 think they 581 are GDRs, they further compare the metric and IP address. If R3 has 582 the better routing metric, or same metric but better tie-breaker, the 583 result will be consistent with GDR selection. If unfortunately, R2 584 has the better metric or same metric but better tie-breaker R2 will 585 become the Assert winner and continues to forward traffic. This will 586 continue until: 588 The next PIM Hello option from DR is seen that selects R3 as the 589 GDR. R3 will then build the forwarding tree and send an Assert. 591 The process continues until R2 agrees to the selection of R3 as being 592 the GDR, and set its own Assert metric to (PIM_ASSERT_INFINITY - 1), 593 which will make R3 the Assert winner. During the process, we will 594 see intermittent duplication of traffic but packet loss will be 595 minimized. In the unlikely case that R2 never relinquishes its role 596 as GDR (while every other router thinks otherwise), the proposed 597 mechanism also helps to keep the duplication to a minimum until 598 manual intervention takes place to remedy the situation. 600 7. IANA Considerations 602 Two new PIM Hello Option Types have been assigned to the DR Load 603 Balancing messages. [HELLO-OPT], this document recommends 34(0x22) 604 as the new "PIM DR Load Balancing Capability Hello Option", and 605 35(0x23) as the new "PIM DR Load Balancing GDR Hello Option". 607 8. Security Considerations 609 Security of the new DR Load Balancing PIM Hello Options is only 610 guaranteed by the security of PIM Hello message, so the security 611 considerations for PIM Hello messages as described in PIM-SM 612 [RFC4601] apply here. 614 9. Acknowledgement 616 The authors would like to thank Steve Simlo, Taki Millonis for 617 helping with the original idea, Bill Atwood, Bharat Joshi for review 618 comments, Stig Venaas, Toerless Eckert and Rishabh Parekh for helpful 619 conversation on the document. 621 10. References 623 10.1. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 629 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 630 Protocol Specification (Revised)", RFC 4601, August 2006. 632 [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) 633 Hello Option for PIM", RFC 6395, October 2011. 635 [RFC4291] Hinden, R. and L. S., "IP Version 6 Addressing 636 Architecture", RFC 6890, February 2006. 638 10.2. Informative References 640 [HELLO-OPT] 641 IANA, , "PIM Hello Options", PIM-HELLO-OPTIONS 642 http://www.iana.org/, March 2007. 644 Authors' Addresses 646 Yiqun Cai 647 Microsoft 648 La Avenida 649 Mountain View, CA 94043 650 USA 652 Email: yiqunc@microsoft.com 654 Sri Vallepalli 655 Cisco Systems, Inc. 656 Tasman Drive 657 San Jose, CA 95134 658 USA 660 Email: svallepa@cisco.com 662 Heidi Ou 663 Cisco Systems, Inc. 664 Tasman Drive 665 San Jose, CA 95134 666 USA 668 Email: hou@cisco.com 670 Andy Green 671 British Telecom 672 Adastral Park 673 Ipswich IP5 2RE 674 United Kingdom 676 Email: andy.da.green@bt.com