idnits 2.17.1 draft-zhang-pim-dr-improvement-01.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 182: '...rs. But the BDR MUST not forward the ...' RFC 2119 keyword, line 211: '... 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. When the DR becomes unavailable because of the down or other reasons, the BDR will forward multicast flows immediately. -- The document date (January 21, 2016) is 3016 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: 'I-D.ietf-pim-rfc4601bis' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 287, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pim-rfc4601bis' ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Z. Zhang 3 Internet-Draft Fangwei. Hu 4 Intended status: Standards Track BenChong. Xu 5 Expires: July 24, 2016 ZTE Corporation 6 January 21, 2016 8 PIM DR Improvement 9 draft-zhang-pim-dr-improvement-01.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 July 24, 2016. 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 Option format . . . . . . . . . . . . . . . . . . . . 3 55 3.2. BDR Option format . . . . . . . . . . . . . . . . . . . . 4 56 4. The Protocol Treatment . . . . . . . . . . . . . . . . . . . 4 57 4.1. Sending Hello Messages . . . . . . . . . . . . . . . . . 5 58 4.2. Receiving Hello Messages . . . . . . . . . . . . . . . . 5 59 4.3. The election of DR and BDR . . . . . . . . . . . . . . . 5 60 5. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Multicast technology is used widely. Many modern technology use PIM 69 technology, such as IPTV, Net-Meeting, and so on. There are many 70 events that will influence the quality of multicast services. Except 71 the unicast routes changing will cause the lost of multicast packets. 72 The change of DR cause the lost of multicast packets too. 74 When a DR on a share-media LAN is down, other routers will elect a 75 new DR until the expiration of Hello-Holdtime. The default value of 76 Hello-Holdtime is 105 seconds. Although the value of Hello-Holdtime 77 can be changed by manual, when the DR is down, there are still many 78 multicast packets will be lost. The quality of IPTV and Net-Meeting 79 will be influenced. 81 \ / 82 \ / 83 ------- ------- 84 | A | | B | 85 ------- ------- 86 | DR | 87 | | 88 ------- ------- 89 | SW |-----------------------------| SW | 90 ------- ------- 91 | | 92 Figure 1: An example of multicast network 94 For example, there were two routers on one Ethernet. RouterA was 95 elected to DR. When RouterA is down, the multicast packets are 96 discarded until the RouterB is elected to DR and RouterB imports the 97 multicast flows successfully. 99 We suppose that there is only a RouterA in the Ethernet at first in 100 Figure 1. RouterA is the DR who is responsible for forwarding 101 multicast flows. When RouterB connects the Ethernet, RouterB will be 102 elected to DR because a high priority. So RouterA will stop 103 forwarding multicast packets. The multicast flows will not recover 104 until RouterB joins the multicast group after it is elected to DR. 106 2. Terminology 108 Backup Designated Router (BDR): A shared-media LAN like Ethernet may 109 have multiple PIM-SM routers connected to it. Except for DR, a other 110 router who will act on behalf of directly connected hosts with 111 respect to the PIM-SM protocol. But BDR will not forward the flows. 112 When DR is down, the BDR will forward multicast flows immediately. A 113 single BDR is elected per interface like the DR. 115 3. PIM hello message format 117 In RFC4601, the PIM hello message format was defined. In this 118 document, we define two new option values which are including Type, 119 Length, and Value. 121 0 1 2 3 122 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 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 124 | Hello message format | 125 | | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 127 | OptionType + OptionLength | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 129 | OptionValue | 130 | | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 132 Figure 2: Hello message format 134 3.1. DR Option format 136 o OptionType : The value is TBD. 138 o OptionLength: If the network is support IPv4, the OptionLength is 139 4 octets. If the network is support IPv6, the OptionLength is 16 140 octets. 142 o OptionValue: The OptionValue is IP address of DR. If the network 143 is support IPv4, the value is IPv4 address of DR. If the network 144 is support IPv6, the value is IPv6 address of DR. 146 3.2. BDR Option format 148 o OptionType : The value is TBD. 150 o OptionLength: If the network is support IPv4, the OptionLength is 151 4 octets. If the network is support IPv6, the OptionLength is 16 152 octets. 154 o OptionValue: The OptionValue is IP address of BDR. If the network 155 is support IPv4, the value is IPv4 address of BDR. If the network 156 is support IPv6, the value is IPv6 address of BDR. 158 4. The Protocol Treatment 160 A new router starts to send hello messages with the values of DR and 161 BDR are all set to 0 after its interface is enabled in PIM on a 162 share-media LAN. When the router receive hello messages from other 163 routers on the same share-media LAN, the router will check if the 164 value of DR or BDR is filled. If the value of DR or BDR is filled 165 with IP address of router who is sending hello messages, the router 166 will store the IP address. 168 Then the new router compare the priority and IP address itself to the 169 stored IP address of DR and BDR accord to the algorithm of RFC 4601. 170 If the new router notices that it is better to be DR than the existed 171 DR or BDR. The router will make itself the BDR, and send new hello 172 messages with its IP address as BDR and existed DR. If the router 173 notices that the existed DR is most priority in the share-media LAN, 174 but the existed BDR is set to 0x0 in the received hello messages, or 175 the existed BDR is not better than the new router to be DR except 176 existed DR, the router will elect itself to BDR. If the router 177 notices that it is not better to be DR than existed DR and BDR, the 178 router will respect the PIM protocol. 180 When the new router becomes the new BDR, the router will join the 181 existed multicast groups, import multicast flows from upstream 182 routers. But the BDR MUST not forward the multicast flows to avoid 183 the duplicate multicast packets in the share-media LAN. The new 184 router will monitor the DR. When the DR becomes unavailable because 185 of the down or other reasons, the BDR will forward multicast flows 186 immediately. 188 4.1. Sending Hello Messages 190 When a new router's interface is enabled in PIM protocol, the router 191 send hello messages with the values of DR and BDR are filled with 192 0x0. 194 When a new router sets itself BDR after receive hello messages from 195 other routers, the router send hello messages with the value of DR is 196 set to the IP address of existed DR and the value of BDR is set to 197 the IP address of the router itself. 199 When a new router notices the existed DR and BDR is more priority 200 than itself. The router will send hello messages with the values of 201 DR and BDR are filled with existed DR and BDR. 203 When a existed router sets itself non DR and non BDR after receive 204 hello messages from other routers, the router will send hello 205 messages with the value of DR is set to existed DR and the value of 206 BDR is set to new BDR. 208 4.2. Receiving Hello Messages 210 When the values of DR and BDR which are carried by hello messages are 211 received is all set to 0x0, the router MUST elect the DR due to the 212 algorithm of RFC4601. And elect a new BDR which are the best choice 213 except DR. 215 When the value of DR which is carried by received hello messages is 216 not 0x0, and the value of BDR is set to 0x0, the router will elect 217 itself to BDR. 219 When the values of DR and BDR that carried by received hello messages 220 are all larger than 0x0. The router will mark the existed DR, and 221 compare itself and the BDR in message. When the router notice that 222 it is better to be DR than existed BDR. The router will elect itself 223 to the BDR. 225 When a router receives a new hello message with the values of DR and 226 BDR are set to 0x0. The router will compare the new router with 227 itself. If the router noticed that the new router is better to be DR 228 than itself, the router will set the BDR to the new router. 230 4.3. The election of DR and BDR 232 When all the routers on a shared-media LAN are start to work on the 233 same time, the election of DR is same as RFC4601. And all the 234 routers will elect a BDR which is suboptimum to DR. The hello 235 messages sent by all the routers are same with the value of DR and 236 BDR are all set. 238 When a new router start to work on a shared-media LAN and receive 239 hello messages from other routers that the value of DR is set at 240 least. The new router will not change the existed DR even if it is 241 superior to the existed DR. If the new router is superior to existed 242 BDR, the new router will replace the place of BDR on the LAN. 244 When an existed router receives hello messages from a new router, and 245 the existed router is DR on the LAN, the existed DR router will 246 compare the new router and all the other routers on the LAN. If the 247 new router is superior to all the other routers, the existed DR 248 router will treat the new router as new BDR. 250 When an existed router receives hello messages from a new router, and 251 the existed router is BDR on the LAN, the existed BDR will compare 252 itself and the new router. If the new router is superior to itself, 253 the existed BDR will elect the new router as new BDR, and set itself 254 for nothing. Then the old BDR will send prune message to upstream 255 routers. 257 When an existed router receives hello messages from a new router, and 258 the existed router is neither DR nor BDR on the LAN, the existed 259 router will compare the existed BDR and the new router. If the new 260 router is superior to all the other routers, the existed DR router 261 will treat the new router as new BDR. 263 5. Deployment suggestion 265 If there are two and more routers on a share-media LAN, and the 266 multicast services is sensitive due to the lost of multicast packets, 267 the LAN should deploy the function of DR and BDR in this document. 269 6. Security Considerations 271 For general PIM Security Considerations. 273 7. IANA Considerations 275 IANA is requested to allocate OptionTypes in TLVs of hello message. 276 Include DR and BDR. 278 8. Normative References 280 [I-D.ietf-pim-rfc4601bis] 281 Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 282 Parekh, R., Zhang, J., and L. Zheng, "Protocol Independent 283 Multicast - Sparse Mode (PIM-SM): Protocol Specification 284 (Revised)", draft-ietf-pim-rfc4601bis-06 (work in 285 progress), August 2015. 287 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 288 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 289 Protocol Specification (Revised)", RFC 4601, 290 DOI 10.17487/RFC4601, August 2006, 291 . 293 Authors' Addresses 295 Zheng(Sandy) Zhang 296 ZTE Corporation 297 No. 50 Software Ave, Yuhuatai Distinct 298 Nanjing 299 China 301 Email: zhang.zheng@zte.com.cn 303 Fangwei Hu 304 ZTE Corporation 305 No.889 Bibo Rd 306 Shanghai 307 China 309 Email: hu.fangwei@zte.com.cn 311 BenChong Xu 312 ZTE Corporation 313 No. 68 Zijinghua Road, Yuhuatai Distinct 314 Nanjing 315 China 317 Email: xu.benchong@zte.com.cn