idnits 2.17.1 draft-ietf-pim-dr-improvement-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4601], [RFC7761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '...rs. But the BDR MUST not forward the ...' RFC 2119 keyword, line 198: '...R / BDR election SHOULD be handled in ...' RFC 2119 keyword, line 316: '... 0x0, the router MUST elect the DR usi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the new router becomes the new BDR, the router will join the existed multicast groups, import multicast flows from upstream routers. But the BDR MUST not forward the multicast flows to avoid the duplicate multicast packets in the share-media LAN. The new router will monitor the DR. The method that BDR monitors the DR may be BFD technology or other ways that can be used to detect link/node failure quickly. When the DR becomes unavailable because of the down or other reasons, the BDR will forward multicast flows immediately. -- The document date (June 6, 2017) is 2513 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) == Unused Reference: 'HRW' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC2362' is defined on line 425, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW' ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Zheng. Zhang 3 Internet-Draft Fangwei. Hu 4 Intended status: Standards Track BenChong. Xu 5 Expires: December 8, 2017 ZTE Corporation 6 Mankamana. Prasad Mishra 7 Cisco Systems 8 June 6, 2017 10 PIM DR Improvement 11 draft-ietf-pim-dr-improvement-03.txt 13 Abstract 15 PIM is widely deployed multicast protocol. PIM protocol is defined 16 in [RFC4601] and [RFC7761]. As deployment for PIM protocol growing 17 day by day, user expect least traffic loss and fast convergence in 18 case of any network failure. This document provides extension to 19 existing defined protocol which would improve stability of PIM 20 protocol with respect to traffic loss and convergence time when the 21 PIM DR is down. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 8, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. PIM hello message format . . . . . . . . . . . . . . . . . . 3 60 3.1. DR Address Option format . . . . . . . . . . . . . . . . 4 61 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 62 4. The Protocol Treatment . . . . . . . . . . . . . . . . . . . 4 63 4.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 64 4.2. Sending Hello Messages . . . . . . . . . . . . . . . . . 6 65 4.3. Receiving Hello Messages . . . . . . . . . . . . . . . . 7 66 4.4. The treatment . . . . . . . . . . . . . . . . . . . . . . 8 67 4.5. Sender side . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Multicast technology is used widely. Many modern technology use PIM 78 technology, such as IPTV, Net-Meeting, and so on. There are many 79 events that will influence the quality of multicast services. The 80 change of unicast routes will cause the lost of multicast packets. 81 The change of DR cause the lost of multicast packets too. 83 When a DR on a share-media LAN is down, other routers will elect a 84 new DR until the expiration of Hello-Holdtime. The default value of 85 Hello-Holdtime is 105 seconds. Although the value of Hello-Holdtime 86 can be changed by manual, when the DR is down, there are still many 87 multicast packets will be lost. The quality of IPTV and Net-Meeting 88 will be influenced. 90 \ / 91 \ / 92 ------- ------- 93 | A | | B | 94 ------- ------- 95 | DR | 96 | | 97 ------- ------- 98 | SW |-----------------------------| SW | 99 ------- ------- 100 | | 101 Figure 1: An example of multicast network 103 For example, there were two routers on one Ethernet. RouterA was 104 elected to DR. When RouterA is down, the multicast packets are 105 discarded until the RouterB is elected to DR and RouterB imports the 106 multicast flows successfully. 108 We suppose that there is only a RouterA in the Ethernet at first in 109 Figure 1. RouterA is the DR which is responsible for forwarding 110 multicast flows. When RouterB connects the Ethernet, RouterB will be 111 elected to DR because a higher priority. So RouterA will stop 112 forwarding multicast packets. The multicast flows will not recover 113 until RouterB joins the multicast group after it is elected to DR. 115 2. Terminology 117 Backup Designated Router (BDR): A shared-media LAN like Ethernet may 118 have multiple PIM-SM routers connected to it. Except for DR, a 119 router which will act on behalf of directly connected hosts with 120 respect to the PIM-SM protocol. But BDR will not forward the flows. 121 When DR is down, the BDR will forward multicast flows immediately. A 122 single BDR is elected per interface like the DR. 124 3. PIM hello message format 126 In [RFC4601] and [RFC7761], the PIM hello message format was defined. 127 In this document, we define two new option values which are including 128 Type, Length, and Value. 130 0 1 2 3 131 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 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 133 | Hello message format | 134 | | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 136 | OptionType + OptionLength | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 138 | OptionValue | 139 | | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 141 Figure 2: Hello message format 143 3.1. DR Address Option format 145 o OptionType : The value is TBD. 147 o OptionLength: If the network is support IPv4, the OptionLength is 148 4 octets. If the network is support IPv6, the OptionLength is 16 149 octets. 151 o OptionValue: The OptionValue is IP address of DR. If the network 152 is support IPv4, the value is IPv4 address of DR. If the network 153 is support IPv6, the value is IPv6 address of DR. 155 3.2. BDR Address Option format 157 o OptionType : The value is TBD. 159 o OptionLength: If the network is support IPv4, the OptionLength is 160 4 octets. If the network is support IPv6, the OptionLength is 16 161 octets. 163 o OptionValue: The OptionValue is IP address of BDR. If the network 164 is support IPv4, the value is IPv4 address of BDR. If the network 165 is support IPv6, the value is IPv6 address of BDR. 167 4. The Protocol Treatment 169 A new router starts to send hello messages with the values of DR and 170 BDR are all set to 0 after its interface is enabled in PIM on a 171 share-media LAN. When the router receives hello messages from other 172 routers on the same share-media LAN, the router will check if the 173 value of DR is filled. If the value of DR is filled with IP address 174 of router which is sending hello messages, the router will store the 175 IP address as the DR address of this interface. 177 Then the new router compare the priority and IP address itself to the 178 stored IP address of DR and BDR according to the algorithm of 179 [RFC4601] and [RFC7761]. If the new router notices that it is better 180 to be DR than the existed DR or BDR. The router will make itself the 181 BDR, and send new hello messages with its IP address as BDR and 182 existed DR. If the router notices that the existed DR has the 183 highest priority in the share-media LAN, but the existed BDR is set 184 to 0x0 in the received hello messages, or the existed BDR is not 185 better than the new router, the new router will elect itself to BDR. 186 If the router notices that it is not better to be DR than existed DR 187 and BDR, the router will respect the existed DR and BDR. 189 When the new router becomes the new BDR, the router will join the 190 existed multicast groups, import multicast flows from upstream 191 routers. But the BDR MUST not forward the multicast flows to avoid 192 the duplicate multicast packets in the share-media LAN. The new 193 router will monitor the DR. The method that BDR monitors the DR may 194 be BFD technology or other ways that can be used to detect link/node 195 failure quickly. When the DR becomes unavailable because of the down 196 or other reasons, the BDR will forward multicast flows immediately. 198 DR / BDR election SHOULD be handled in two ways. Selection of which 199 procedure to use would be totally dependent on deployment scenario. 201 1. When new router is added in existing steady state of network, if 202 the new router notices that it is better to be DR than the existing 203 DR. It does elect itself as DR as procedure defined in RFC 7761. 204 This method must be used when user is ok to have transition in 205 network. This option should be used if deployment requirement is to 206 adopt with new DR as and when they are available, and intermediate 207 network transition is acceptable. 209 2. If the new router notices that it is better to be DR than the 210 existed DR or BDR, the router will make itself the BDR, and send new 211 hello message with its IP address as BDR and existed DR. Uses of 212 this option would have less transition in network. This option 213 should be used when deployment requirement is to have minimum 214 transition in network unless there is some failure. 216 4.1. Election Algorithm 218 The DR and BDR election is according the rules defined below, the 219 algorithm is similar to the DR election definition in [RFC2328]. 221 (1) Note the current values for the network's Designated Router and 222 Backup Designated Router. This is used later for comparison 223 purposes. 225 (2) Calculate the new Backup Designated Router for the network as 226 follows. Those routers that have not declared themselves to be 227 Designated Router are eligible to become Backup Designated Router. 228 The one which have the highest priority will be chosen to be Backup 229 Designed Router. In case of a tie, the one having the highest Router 230 ID is chosen. 232 (3) Calculate the new Designated Router for the network as follows. 233 If one or more of the routers have declared themselves Designated 234 Router (i.e., they are currently listing themselves as Designated 235 Router in their Hello Packets) the one having highest Router Priority 236 is declared to be Designated Router. In case of a tie, the one 237 having the highest Router ID is chosen. If no routers have declared 238 themselves Designated Router, assign the Designated Router to be the 239 same as the newly elected Backup Designated Router. 241 (4) If Router X is now newly the Designated Router or newly the 242 Backup Designated Router, or is now no longer the Designated Router 243 or no longer the Backup Designated Router, repeat steps 2 and 3, and 244 then proceed to step 5. For example, if Router X is now the 245 Designated Router, when step 2 is repeated X will no longer be 246 eligible for Backup Designated Router election. Among other things, 247 this will ensure that no router will declare itself both Backup 248 Designated Router and Designated Router. 250 (5) As a result of these calculations, the router itself may now be 251 Designated Router or Backup Designated Router. 253 The reason behind the election algorithm's complexity is the desire 254 for the DR stability. 256 The above procedure may elect the same router to be both Designated 257 Router and Backup Designated Router, although that router will never 258 be the calculating router (Router X) itself. The elected Designated 259 Router may not be the router having the highest Router Priority. If 260 Router X is not itself eligible to become Designated Router, it is 261 possible that neither a Backup Designated Router nor a Designated 262 Router will be selected in the above procedure. Note also that if 263 Router X is the only attached router that is eligible to become 264 Designated Router, it will select itself as Designated Router and 265 there will be no Backup Designated Router for the network. 267 4.2. Sending Hello Messages 269 According to Section 4.3.1 in [RFC4601] and [RFC7761], when a new 270 router's interface is enabled in PIM protocol, the router send hello 271 messages with the values of DR and BDR are filled with 0x0. Then the 272 interface is in waiting state and start the hold-timer which is like 273 the neighbor hold-timer. When the hold-timer is expired, the 274 interface will elect the DR and BDR according to the DR election 275 rules. 277 When a new router sets itself BDR after receive hello messages from 278 other routers, the router send hello messages with the value of DR is 279 set to the IP address of existed DR and the value of BDR is set to 280 the IP address of the router itself. 282 When a existed BDR sets itself non DR and non BDR after receive hello 283 messages from other routers, the router will send hello messages with 284 the value of DR is set to existed DR and the value of BDR is set to 285 new BDR. 287 DR newcomer 288 \ / 289 ----- ----- ----- 290 | A | | B | | C | 291 ----- ----- ----- 292 | | | 293 | | | 294 ------------------------------------------- LAN 295 Figure 3 297 For example, there is a stable LAN that include RouterA and RouterB. 298 RouterA is the DR which has the best priority. RouterC is a 299 newcomer. RouterC sends hello packet with the DR and BDR is all set 300 to zero. 302 If RouterC cannot send hello packet with the DR/BDR capability, 303 Router C may send the hello packet according the rule defined 304 in[RFC4601] and [RFC7761]. 306 If deployment requirement is to adopt with new DR as and when they 307 are available, a new router with highest priority or best IP address 308 sends hello packet with DR and BDR all set to zero at first. It 309 sends hello packet with itself set to DR after it finish join all the 310 existing multicast groups. Then existed DR compares with the new 311 router, the new router will be final DR. 313 4.3. Receiving Hello Messages 315 When the values of DR and BDR which are carried by hello messages are 316 received is all set to 0x0, the router MUST elect the DR using 317 procedure defined in [RFC4601] and [RFC7761] after the hold-timer 318 expires. And elect a new BDR which is the best choice except DR. 320 In case the value of DR which is carried by received hello messages 321 is not 0x0, and the value of BDR is set to 0x0, when the hold-timer 322 expires there is no hello packet from other router is received, the 323 router will elect itself to BDR. 325 In case either of the values of DR and BDR that are carried by 326 received hello messages are larger than 0x0. The router will mark 327 the existed DR, and compare itself and the BDR in message. When the 328 router notice that it is better to be DR than existed BDR. The 329 router will elect itself to the BDR. 331 When a router receives a new hello message with the values of DR and 332 BDR are set to 0x0. The router will compare the new router with 333 existed information. If the router noticed that the new router is 334 better to be DR than itself, or the new router is better to be BDR 335 than the existed BDR, the router will set the BDR to the new router. 337 When existed DR receives hello packet with DR set larger than zero, 338 algorithm defined in section 4.1 can be used to select the final DR. 340 As illustrated in Figure 3, after RouterC sends hello packet, RouterC 341 will not elect the DR until hold-timer expired. During the period, 342 RouterC should receive the hello packets from RouterA and RouterB. 343 RouterC accepts the result that RouterA is the DR. In case RouterC 344 has the lowest priority than RouterA and RouterB, RouterC will also 345 accept that Router B is the BDR. In case RouterC has the 346 intermediate priority among the three routers, RouterC will treat 347 itself as new BDR after the hold-timer expired. In case RouterC has 348 the highest priority among the three routers, RouterC will treat 349 RouterA which is the existed DR as DR, and RouterC will treat itself 350 as new BDR. If the network administrator thinks that RouterC should 351 be new DR, the DR changing should be triggered manually. 353 Exception: During the hold-timer period, RouterC receives only the 354 hello packet from RouterA. When the hold-timer expired, RouterC 355 treats RouterA as DR. and RouterC treats itself as BDR. In case 356 RouterC only receives the hello packet from RouterB during the hold- 357 timer period, RouterC will compare the priority between RouterB and 358 itself to elect the new DR. In these situations, some interfaces or 359 links go wrong in the LAN. 361 4.4. The treatment 363 When all the routers on a shared-media LAN are start to work on the 364 same time, the election result of DR is same as [RFC4601] and 365 [RFC7761]. And all the routers will elect a BDR which is suboptimum 366 to DR. The routers in the network will store the DR and BDR. The 367 hello messages sent by all the routers are same with the value of DR 368 and BDR are all set. 370 When a new router start to work on a shared-media LAN and receive 371 hello messages from other routers that the value of DR is set. The 372 new router will not change the existed DR even if it is superior to 373 the existed DR. If the new router is superior to existed BDR, the 374 new router will replace the existed BDR. 376 When the routers receive hello message from a new router, the routers 377 will compare the new router and all the other routers on the LAN. If 378 the new router is superior to existed BDR, the new router will be new 379 BDR. Then the old BDR will send prune message to upstream routers. 381 As a result, the BDR is the one which has the highest priority except 382 DR. Once the DR is elected, the DR will not change until it fails or 383 manually adjustment. After the DR and BDR are elected, the routers 384 in the network will store the address of DR and BDR. 386 4.5. Sender side 388 DR/BDR function also can be used in source side that multiple routers 389 and source is in same share-media network. The algorithm is the same 390 as the receiver side. Only the BDR need not build multicast tree 391 from downstream router. 393 5. Compatibility 395 If the LAN is a hybrid network that there are some routers which have 396 DR/BDR capability and the other routers which have not DR/BDR 397 capability. In order to avoid duplicated multicast flows in the LAN, 398 all the routers should go backward to use the algorithm defined in 399 [RFC4601] and [RFC7761]. 401 6. Deployment suggestion 403 If there are two and more routers on a share-media LAN, and the 404 multicast services is sensitive to the lost of multicast packets, the 405 function of DR and BDR defined in this document should be deployed. 407 7. Security Considerations 409 For general PIM Security Considerations. 411 8. IANA Considerations 413 IANA is requested to allocate OptionTypes in TLVs of hello message. 414 Include DR and BDR. 416 9. Normative References 418 [HRW] IEEE, "Using name-based mappings to increase hit rates", 419 IEEE HRW, February 1998. 421 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 422 DOI 10.17487/RFC2328, April 1998, 423 . 425 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 426 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 427 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 428 Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, 429 June 1998, . 431 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 432 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 433 Protocol Specification (Revised)", RFC 4601, 434 DOI 10.17487/RFC4601, August 2006, 435 . 437 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 438 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 439 Multicast - Sparse Mode (PIM-SM): Protocol Specification 440 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 441 2016, . 443 Authors' Addresses 445 Zheng(Sandy) Zhang 446 ZTE Corporation 447 No. 50 Software Ave, Yuhuatai Distinct 448 Nanjing 449 China 451 Email: zhang.zheng@zte.com.cn 452 Fangwei Hu 453 ZTE Corporation 454 No.889 Bibo Rd 455 Shanghai 456 China 458 Email: hu.fangwei@zte.com.cn 460 BenChong Xu 461 ZTE Corporation 462 No. 68 Zijinghua Road, Yuhuatai Distinct 463 Nanjing 464 China 466 Email: xu.benchong@zte.com.cn 468 Mankamana Prasad Mishra 469 Cisco Systems 470 821 Alder Drive, 471 MILPITAS, CALIFORNIA 95035 472 UNITED STATES 474 Email: mankamis@cisco.com