idnits 2.17.1 draft-ietf-pim-dr-improvement-02.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 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 184: '...rs. But the BDR MUST not forward the ...' RFC 2119 keyword, line 284: '... 0x0, the router MUST elect the DR due...' 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 (December 5, 2016) is 2697 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: June 8, 2017 ZTE Corporation 6 December 5, 2016 8 PIM DR Improvement 9 draft-ietf-pim-dr-improvement-02.txt 11 Abstract 13 PIM is worldly deployed multicast protocol. This document will 14 improve the stability of PIM protocol, decrease the lost of multicast 15 packets when the PIM DR (Designed Router) is down. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 8, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. PIM hello message format . . . . . . . . . . . . . . . . . . 3 54 3.1. DR Address Option format . . . . . . . . . . . . . . . . 3 55 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 56 4. The Protocol Treatment . . . . . . . . . . . . . . . . . . . 4 57 4.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 58 4.2. Sending Hello Messages . . . . . . . . . . . . . . . . . 6 59 4.3. Receiving Hello Messages . . . . . . . . . . . . . . . . 6 60 4.4. The treatment . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 Multicast technology is used widely. Many modern technology use PIM 71 technology, such as IPTV, Net-Meeting, and so on. There are many 72 events that will influence the quality of multicast services. The 73 change of unicast routes will cause the lost of multicast packets. 74 The change of DR cause the lost of multicast packets too. 76 When a DR on a share-media LAN is down, other routers will elect a 77 new DR until the expiration of Hello-Holdtime. The default value of 78 Hello-Holdtime is 105 seconds. Although the value of Hello-Holdtime 79 can be changed by manual, when the DR is down, there are still many 80 multicast packets will be lost. The quality of IPTV and Net-Meeting 81 will be influenced. 83 \ / 84 \ / 85 ------- ------- 86 | A | | B | 87 ------- ------- 88 | DR | 89 | | 90 ------- ------- 91 | SW |-----------------------------| SW | 92 ------- ------- 93 | | 94 Figure 1: An example of multicast network 96 For example, there were two routers on one Ethernet. RouterA was 97 elected to DR. When RouterA is down, the multicast packets are 98 discarded until the RouterB is elected to DR and RouterB imports the 99 multicast flows successfully. 101 We suppose that there is only a RouterA in the Ethernet at first in 102 Figure 1. RouterA is the DR which is responsible for forwarding 103 multicast flows. When RouterB connects the Ethernet, RouterB will be 104 elected to DR because a higher priority. So RouterA will stop 105 forwarding multicast packets. The multicast flows will not recover 106 until RouterB joins the multicast group after it is elected to DR. 108 2. Terminology 110 Backup Designated Router (BDR): A shared-media LAN like Ethernet may 111 have multiple PIM-SM routers connected to it. Except for DR, a 112 router which will act on behalf of directly connected hosts with 113 respect to the PIM-SM protocol. But BDR will not forward the flows. 114 When DR is down, the BDR will forward multicast flows immediately. A 115 single BDR is elected per interface like the DR. 117 3. PIM hello message format 119 In [RFC4601] and [RFC7761], the PIM hello message format was defined. 120 In this document, we define two new option values which are including 121 Type, Length, and Value. 123 0 1 2 3 124 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 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 126 | Hello message format | 127 | | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 129 | OptionType + OptionLength | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 131 | OptionValue | 132 | | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 134 Figure 2: Hello message format 136 3.1. DR Address Option format 138 o OptionType : The value is TBD. 140 o OptionLength: If the network is support IPv4, the OptionLength is 141 4 octets. If the network is support IPv6, the OptionLength is 16 142 octets. 144 o OptionValue: The OptionValue is IP address of DR. If the network 145 is support IPv4, the value is IPv4 address of DR. If the network 146 is support IPv6, the value is IPv6 address of DR. 148 3.2. BDR Address Option format 150 o OptionType : The value is TBD. 152 o OptionLength: If the network is support IPv4, the OptionLength is 153 4 octets. If the network is support IPv6, the OptionLength is 16 154 octets. 156 o OptionValue: The OptionValue is IP address of BDR. If the network 157 is support IPv4, the value is IPv4 address of BDR. If the network 158 is support IPv6, the value is IPv6 address of BDR. 160 4. The Protocol Treatment 162 A new router starts to send hello messages with the values of DR and 163 BDR are all set to 0 after its interface is enabled in PIM on a 164 share-media LAN. When the router receives hello messages from other 165 routers on the same share-media LAN, the router will check if the 166 value of DR is filled. If the value of DR is filled with IP address 167 of router which is sending hello messages, the router will store the 168 IP address as the DR address of this interface. 170 Then the new router compare the priority and IP address itself to the 171 stored IP address of DR and BDR according to the algorithm of 172 [RFC4601] and [RFC7761]. If the new router notices that it is better 173 to be DR than the existed DR or BDR. The router will make itself the 174 BDR, and send new hello messages with its IP address as BDR and 175 existed DR. If the router notices that the existed DR has the 176 highest priority in the share-media LAN, but the existed BDR is set 177 to 0x0 in the received hello messages, or the existed BDR is not 178 better than the new router, the new router will elect itself to BDR. 179 If the router notices that it is not better to be DR than existed DR 180 and BDR, the router will respect the existed DR and BDR. 182 When the new router becomes the new BDR, the router will join the 183 existed multicast groups, import multicast flows from upstream 184 routers. But the BDR MUST not forward the multicast flows to avoid 185 the duplicate multicast packets in the share-media LAN. The new 186 router will monitor the DR. The method that BDR monitors the DR may 187 be BFD technology or other ways that can be used to detect link/node 188 failure quickly. When the DR becomes unavailable because of the down 189 or other reasons, the BDR will forward multicast flows immediately. 191 4.1. Election Algorithm 193 The DR and BDR election is according the rules defined below, the 194 algorithm is similar to the DR election definition in [RFC2328]. 196 (1) Note the current values for the network's Designated Router and 197 Backup Designated Router. This is used later for comparison 198 purposes. 200 (2) Calculate the new Backup Designated Router for the network as 201 follows. Those routers that have not declared themselves to be 202 Designated Router are eligible to become Backup Designated Router. 203 The one which have the highest priority will be chosen to be Backup 204 Designed Router. In case of a tie, the one having the highest Router 205 ID is chosen. 207 (3) Calculate the new Designated Router for the network as follows. 208 If one or more of the routers have declared themselves Designated 209 Router (i.e., they are currently listing themselves as Designated 210 Router in their Hello Packets) the one having highest Router Priority 211 is declared to be Designated Router. In case of a tie, the one 212 having the highest Router ID is chosen. If no routers have declared 213 themselves Designated Router, assign the Designated Router to be the 214 same as the newly elected Backup Designated Router. 216 (4) If Router X is now newly the Designated Router or newly the 217 Backup Designated Router, or is now no longer the Designated Router 218 or no longer the Backup Designated Router, repeat steps 2 and 3, and 219 then proceed to step 5. For example, if Router X is now the 220 Designated Router, when step 2 is repeated X will no longer be 221 eligible for Backup Designated Router election. Among other things, 222 this will ensure that no router will declare itself both Backup 223 Designated Router and Designated Router. 225 (5) As a result of these calculations, the router itself may now be 226 Designated Router or Backup Designated Router. 228 The reason behind the election algorithm's complexity is the desire 229 for the DR stability. 231 The above procedure may elect the same router to be both Designated 232 Router and Backup Designated Router, although that router will never 233 be the calculating router (Router X) itself. The elected Designated 234 Router may not be the router having the highest Router Priority. If 235 Router X is not itself eligible to become Designated Router, it is 236 possible that neither a Backup Designated Router nor a Designated 237 Router will be selected in the above procedure. Note also that if 238 Router X is the only attached router that is eligible to become 239 Designated Router, it will select itself as Designated Router and 240 there will be no Backup Designated Router for the network. 242 4.2. Sending Hello Messages 244 According to Section 4.3.1 in [RFC4601] and [RFC7761], when a new 245 router's interface is enabled in PIM protocol, the router send hello 246 messages with the values of DR and BDR are filled with 0x0. Then the 247 interface is in waiting state and start the hold-timer which is like 248 the neighbor hold-timer. When the hold-timer is expired, the 249 interface will elect the DR and BDR according to the DR election 250 rules. 252 When a new router sets itself BDR after receive hello messages from 253 other routers, the router send hello messages with the value of DR is 254 set to the IP address of existed DR and the value of BDR is set to 255 the IP address of the router itself. 257 When a existed BDR sets itself non DR and non BDR after receive hello 258 messages from other routers, the router will send hello messages with 259 the value of DR is set to existed DR and the value of BDR is set to 260 new BDR. 262 DR newcomer 263 \ / 264 ----- ----- ----- 265 | A | | B | | C | 266 ----- ----- ----- 267 | | | 268 | | | 269 ------------------------------------------- LAN 270 Figure 3 272 For example, there is a stable LAN that include RouterA and RouterB. 273 RouterA is the DR which has the best priority. RouterC is a 274 newcomer. RouterC sends hello packet with the DR and BDR is all set 275 to zero. 277 If RouterC cannot send hello packet with the DR/BDR capability, 278 Router C may send the hello packet according the rule defined 279 in[RFC4601] and [RFC7761]. 281 4.3. Receiving Hello Messages 283 When the values of DR and BDR which are carried by hello messages are 284 received is all set to 0x0, the router MUST elect the DR due to the 285 algorithm of [RFC4601] and [RFC7761] after the hold-timer expires. 286 And elect a new BDR which are the best choice except DR. 288 In case the value of DR which is carried by received hello messages 289 is not 0x0, and the value of BDR is set to 0x0, when the hold-timer 290 expires there is no hello packet from other router is received, the 291 router will elect itself to BDR. 293 In case the values of DR and BDR that are carried by received hello 294 messages are all larger than 0x0. The router will mark the existed 295 DR, and compare itself and the BDR in message. When the router 296 notice that it is better to be DR than existed BDR. The router will 297 elect itself to the BDR. 299 When a router receives a new hello message with the values of DR and 300 BDR are set to 0x0. The router will compare the new router with 301 existed information. If the router noticed that the new router is 302 better to be DR than itself, or the new router is better to be BDR 303 than the existed BDR, the router will set the BDR to the new router. 305 As illustrated in Figure 3, after RouterC sends hello packet, RouterC 306 will not elect the DR until hold-timer expired. During the period, 307 RouterC should receive the hello packets from RouterA and RouterB. 308 RouterC accepts the result that RouterA is the DR. In case RouterC 309 has the lowest priority than RouterA and RouterB, RouterC will also 310 accept that Router B is the BDR. In case RouterC has the 311 intermediate priority among the three routers, RouterC will treat 312 itself as new BDR after the hold-timer expired. In case RouterC has 313 the highest priority among the three routers, RouterC will treat 314 RouterA which is the existed DR as DR, and RouterC will treat itself 315 as new BDR. If the network administrator thinks that RouterC should 316 be new DR, the DR changing should be triggered manually. 318 Exception: During the hold-timer period, RouterC receives only the 319 hello packet from RouterA. When the hold-timer expired, RouterC 320 treats RouterA as DR. and RouterC treats itself as BDR. In case 321 RouterC only receives the hello packet from RouterB during the hold- 322 timer period, RouterC will compare the priority between RouterB and 323 itself to elect the new DR. In these situations, some interfaces or 324 links go wrong in the LAN. 326 4.4. The treatment 328 When all the routers on a shared-media LAN are start to work on the 329 same time, the election result of DR is same as [RFC4601] and 330 [RFC7761]. And all the routers will elect a BDR which is suboptimum 331 to DR. The routers in the network will store the DR and BDR. The 332 hello messages sent by all the routers are same with the value of DR 333 and BDR are all set. 335 When a new router start to work on a shared-media LAN and receive 336 hello messages from other routers that the value of DR is set. The 337 new router will not change the existed DR even if it is superior to 338 the existed DR. If the new router is superior to existed BDR, the 339 new router will replace the existed BDR. 341 When the routers receive hello message from a new router, the routers 342 will compare the new router and all the other routers on the LAN. If 343 the new router is superior to existed BDR, the new router will be new 344 BDR. Then the old BDR will send prune message to upstream routers. 346 As a result, the BDR is the one which has the highest priority except 347 DR. Once the DR is elected, the DR will not change until it fails or 348 manually adjustment. After the DR and BDR are elected, the routers 349 in the network will store the address of DR and BDR. 351 5. Compatibility 353 If the LAN is a hybrid network that there are some routers which have 354 DR/BDR capability and the other routers which have not DR/BDR 355 capability. In order to avoid duplicated multicast flows in the LAN, 356 all the routers should go backward to use the algorithm defined in 357 [RFC4601] and [RFC7761]. 359 6. Deployment suggestion 361 If there are two and more routers on a share-media LAN, and the 362 multicast services is sensitive to the lost of multicast packets, the 363 function of DR and BDR defined in this document should be deployed. 365 7. Security Considerations 367 For general PIM Security Considerations. 369 8. IANA Considerations 371 IANA is requested to allocate OptionTypes in TLVs of hello message. 372 Include DR and BDR. 374 9. Normative References 376 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 377 DOI 10.17487/RFC2328, April 1998, 378 . 380 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 381 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 382 Protocol Specification (Revised)", RFC 4601, 383 DOI 10.17487/RFC4601, August 2006, 384 . 386 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 387 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 388 Multicast - Sparse Mode (PIM-SM): Protocol Specification 389 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 390 2016, . 392 Authors' Addresses 394 Zheng(Sandy) Zhang 395 ZTE Corporation 396 No. 50 Software Ave, Yuhuatai Distinct 397 Nanjing 398 China 400 Email: zhang.zheng@zte.com.cn 402 Fangwei Hu 403 ZTE Corporation 404 No.889 Bibo Rd 405 Shanghai 406 China 408 Email: hu.fangwei@zte.com.cn 410 BenChong Xu 411 ZTE Corporation 412 No. 68 Zijinghua Road, Yuhuatai Distinct 413 Nanjing 414 China 416 Email: xu.benchong@zte.com.cn