idnits 2.17.1 draft-venaas-pim-port-pfm-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1845 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft B. Ganesh 4 Intended status: Experimental K. Thiruvenkatasamy 5 Expires: September 12, 2019 R. Chokkanathapuram 6 Cisco Systems, Inc. 7 March 11, 2019 9 PIM Flooding Protocol over Reliable Transport 10 draft-venaas-pim-port-pfm-00 12 Abstract 14 The PIM Flooding Protocol (PFM) defined in RFC8364 relies on sending 15 periodic updates as it does not provide for any reliability. If a 16 message is lost, the information will be provided in the next 17 periodic update. 19 This document extends the Reliable Transport Mechanism for PIM in 20 RFC6559 to allow for sending PFM messages. This significantly 21 reduces the PFM signaling by not requiring frequent periodic updates, 22 and it provides for retransmission, allowing for quick recovery when 23 an IP packet is dropped. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 12, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Protocol specification . . . . . . . . . . . . . . . . . . . 3 62 4. PFM over PORT message definitions . . . . . . . . . . . . . . 5 63 4.1. PORT PFM Update . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. PORT PFM Request . . . . . . . . . . . . . . . . . . . . 7 65 4.3. PORT PFM Update Option . . . . . . . . . . . . . . . . . 8 66 4.4. PORT PFM Request Option . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The PIM Flooding Protocol (PFM) defined in [RFC8364] relies on 75 sending periodic updates as it does not provide for any reliability. 76 If a message is lost, the information will be provided in the next 77 periodic update. With PFM, a router will typically originate a full 78 update every 60 seconds. This ensures that in case of packet drops, 79 one usually will recover in 60 seconds. There is a trade-off between 80 the number of updates and the recovery time. 82 This document extends the Reliable Transport Mechanism for PIM in 83 [RFC6559] to allow for sending PFM messages. We will refer to it as 84 PORT (PIM Over Reliable Transport). The use of PORT significantly 85 reduces the PFM signaling by not requiring frequent periodic updates, 86 and it provides for retransmission, allowing for quick recovery when 87 an IP packet is dropped. There will still be some full updates, but 88 they can be sent much more rarely. If there is a packet drop, the 89 reliable transport (TCP/SCTP) will ensure retransmission. 91 The PORT sessions are established as specified in [RFC6559] between 92 PIM neighbors. The sessions may be used to send other PORT messages, 93 or they can be used only for PFM. Unless all the neighbors support 94 PFM over PORT, regular PFM is used. How to signal support and how a 95 router relays a PFM over PORT message as regular PFM and vice versa 96 will be discussed in a later revision. 98 2. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. Protocol specification 108 PFM messages are sent over PORT by sending PORT PFM Update messages. 109 They contain a PFM message as defined in [RFC8364]. They also 110 contain a Full ID and a Delta ID that together specifies an ID for 111 the update. Some updates are full updates, they contain all the 112 information an originator is announcing. This would be similar to 113 the periodic updates in regular PFM. Full updates over PORT are sent 114 after some a configurable number of deltas have been sent, or 115 whenever information needs to be withdrawn. Delta updates are used 116 for triggered updates, similar to triggered updates in regular PFM. 117 Each time there is some change a delta update can be triggered. 119 The Full ID is an unsigned 48 bit value and it is assumed that it is 120 always increasing. That is, any Full Update MUST always have a Full 121 ID larger than any previous updates ever sent using the same 122 Originator address. This MUST also be preserved if the router is 123 reloaded. For the protocol to work, it may also be necessary to 124 ensure this if an address used as an originator address is moved to a 125 different router. It is RECOMMENDED that implementations use the 126 number of seconds since 0h UTC on 1 January 1900 as the ID value. 127 This allows for this protocol to be used for about four million years 128 from the time of publication of this document. If for any reason the 129 clock on a router is adjusted to a value back in time, an 130 implementation would have to ensure that values are still increasing. 131 Since Full Updates do not need to be sent every second, one should in 132 this case be able to catch up. 134 The first time a router originates a PFM message, it sends a Full 135 update, even though it likely is triggered by some event. Full 136 updates always have the Delta ID set to zero. After that it may send 137 several Delta updates. For each Delta update, the Delta ID is 138 incremented, while the Full ID remains the same. After some time it 139 may decide to send a new full update. The Full ID in the full update 140 MUST be larger than the Full ID in the previous update, and Delta ID 141 is reset to zero. A Full update always has Delta ID zero, and a 142 Delta update always has a non-zero Delta ID. 144 When a router receives an update it performs RPF check as in regular 145 PFM, boundary processing as in regular PFM. For each interface where 146 the update would have been forwarded in regular PFM, it will be sent 147 over PORT to all PFM PORT neighbors on the interface. If there are 148 any neighbors on the interface not supporting PFM PORT it MAY revert 149 to sending unreliable PFM messages. 151 When a router receives a Full update it will remove any stored 152 information from the originator and store the information in the new 153 update. When it receives a Delta update it stores the update and 154 keeps all previous information. 156 Due to routers being restarted, PORT connections going down etc., 157 some routers MAY have missed some updates, potentially not having 158 received any updates when restarting. In order to receive the most 159 recent data from a neighbor it sends a PORT PFM Request message. For 160 each originator the router has stored information from, it will 161 include an option indicating the Full and Delta IDs of the last 162 message received from that originator. A router receiving the 163 Request compares the IDs of the specified originators with the latest 164 data it has for these originators. If it has a more recent full 165 update, it will first send it to the neighbor. Next, if it has more 166 recent delta updates, it will send all the delta updates in the order 167 they were received. This means that the requesting router receives 168 the messages in order. It will first get a full update if a more 169 recent version exists. The ID of this update may be much larger than 170 the previously seen ID. The first Delta update received, if any, 171 will have ID one if a Full update was received, or one larger than 172 the Delta ID in the request, if not. If multiple Delta updates are 173 received, the Delta ID will increment by one for each update. If the 174 router has stored information for any originators not included in the 175 request message, it will also send this information. It will first 176 send the stored Full update, and then the Delta updates. As 177 discussed above, the Delta updates MUST be sent in the order they 178 were received, first sending update one, then update two, and so 179 forth. 181 The Delta ID is an unsigned 16 bits value. It never wraps around. A 182 router MUST send a new full update if the Delta ID value is reaching 183 its maximum value. It is RECOMMENDED having a configurable limit for 184 how many Delta updates can be sent before sending a new Full update. 185 Sending Full updates often is in some ways wasteful, but it limits 186 how many deltas routers need to store, and they are also used to 187 remove information that no longer is needed. 189 When a router starts up, it is RECOMMENDED that before it originates 190 any messages, it sends a PORT PFM Request message to receive any 191 updates that neighbors may have stored for the originator address it 192 would use. It could simply not include an option with the originator 193 address it would use, and receive any information neighbors may have, 194 or it could could include an option, but with the Full ID set to a 195 value smaller than the Full ID it would use for the next Full Update. 196 E.g., if the ID is based on the number of seconds since the epoch, it 197 could send a request based on the current time. It would then 198 normally get no updates from the neighbors with its own ID. If it 199 does, it is RECOMMENDED to log an error, and ensure that the Full IDs 200 of the next future Full Updates are larger than what was received. 202 In order to handle extra ordinary cases where a router has originated 203 messages with an erroneously large Full ID, it is RECOMMENDED that 204 implementations provides a way for an administrator to clear the 205 stored PFM state on a router, as well as a way to trigger sending of 206 a Full Update on an originator. This means that as a last resort, an 207 administrator could clear the state for an originator on all the 208 routers, and optionally afterwards trigger a full update by the 209 originator. 211 4. PFM over PORT message definitions 213 We define a new PORT message for sending a PFM message. This 214 consists of an update version and a new PORT option containing a PFM 215 message as defined in [RFC8364]. We also define a new PORT message 216 for requesting a PFM update from a neighbor. This contains the 217 latest update version that the router has from each originator and 218 requests the neighbor to transmit any information that it is missing. 220 4.1. PORT PFM Update 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type = TBD1 | Message Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Reserved | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Interface | 229 | ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Full-update | 232 | +-------------------------------| 233 | ID | Delta-update ID | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | PORT Option Type | Option Value Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Value | 238 | . | 239 | . | 240 | . | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 \ . \ 243 / . / 244 \ . \ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | PORT Option Type | Option Value Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Value | 249 | . | 250 | . | 251 | . | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Type: Type is TBD. 256 Message Length: Length in bytes for the value part of the Type/ 257 Length/Value encoding. If no PORT Options are included, the 258 length is 12. If n PORT Options with Option Value lengths L1, L2, 259 ..., Ln are included, the message length is 12 + 4*n + L1 + L2 + 260 ... + Ln. 262 Reserved: Set to zero on transmission and ignored on receipt. 264 Interface ID: This MUST be the Interface ID of the Interface ID 265 Hello Option contained in the PIM Hello messages that the PIM 266 router is sending to the PIM neighbor. It indicates to the PIM 267 neighbor what interface to associate the update with. This is 268 similar to how the Interface ID is used in [RFC6559]. The 269 Interface ID allows us to do connection sharing while still 270 allowing the regular PFM RPF neighbor validation. 272 Full-update ID: If this is a full update, it is the ID of this 273 update. If this is a delta, then this is the ID of the last full 274 update. This is a 48 bit value. 276 Delta-update ID: If this is a delta update, this is the ID of the 277 delta. Note that the Full-update ID is also used for a delta. If 278 this is a full update, delta-update is set to 0. This is a 16 bit 279 value. 281 PORT Options: The general format is defined in [RFC6559] section 282 5.3. This message MUST contain exactly one PFM Update PORT 283 option. The PFM Update PORT option is defined below. It MAY 284 contain other options that are defined for use in a PORT PFM 285 Update message. 287 4.2. PORT PFM Request 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type = TBD2 | Message Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Reserved | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | PORT Option Type | Option Value Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Value | 299 | . | 300 | . | 301 | . | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 \ . \ 304 / . / 305 \ . \ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | PORT Option Type | Option Value Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Value | 310 | . | 311 | . | 312 | . | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Type: Type is TBD. 317 Message Length: Length in bytes for the value part of the Type/ 318 Length/Value encoding. If no PORT Options are included, the 319 length is 12. If n PORT Options with Option Value lengths L1, L2, 320 ..., Ln are included, the message length is 12 + 4*n + L1 + L2 + 321 ... + Ln. 323 Reserved: Set to zero on transmission and ignored on receipt. 325 PORT Options: The general format is defined in [RFC6559] section 326 5.3. This message MAY contain zero, one or multiple PFM Request 327 PORT options. The options indicate which versions the requesting 328 router has from which originators; one option per originator. No 329 options, means that the requesting router wants a full update for 330 all known originators. The PFM Request PORT option is defined 331 below. It MAY contain other options that are defined for use in a 332 PORT PFM Request message. 334 4.3. PORT PFM Update Option 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | PORT Option Type = TBD3 | Option Value Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | PFM Message | 342 | . | 343 | . | 344 | . | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Type: Type is TBD. 349 Option Value Length: The number of octets that make up the PFM 350 Message. 352 PFM Message: A PFM Message as defined in [RFC8364]. 354 4.4. PORT PFM Request Option 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | PORT Option Type = TBD4 | Option Value Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Originator Address (Encoded-Unicast format) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Full-update | 363 | +-------------------------------| 364 | ID | Delta-update ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Type: Type is TBD. 369 Option Value Length: The length in octets of the originator address 370 plus 6. 372 Originator Address: The address of an originator as defined in 373 [RFC8364]. 375 Full-update ID: The ID of the last full update that the router has 376 stored. It is requesting getting the most recent newer full 377 update, if any exists. Plus, any deltas after the last full 378 update. 380 Delta-update ID: The ID of the last delta update that the router 381 has stored. It is requesting getting the most recent newer full 382 update, using the Full-update ID, if it exists plus any deltas 383 after that. If there are no more recent full updates, then it is 384 requesting any delta updates more recent than this ID. 386 5. Security Considerations 388 To be completed. Largely similar to the considerations for PIM PORT. 389 One may use TCP/SCTP authentication mechanisms. 391 6. IANA considerations 393 To be completed. IANA would need to assign types for the messages 394 and options defined. 396 7. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. 404 Napierala, "A Reliable Transport Mechanism for PIM", 405 RFC 6559, DOI 10.17487/RFC6559, March 2012, 406 . 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM 413 Flooding Mechanism (PFM) and Source Discovery (SD)", 414 RFC 8364, DOI 10.17487/RFC8364, March 2018, 415 . 417 Authors' Addresses 419 Stig Venaas 420 Cisco Systems, Inc. 421 Tasman Drive 422 San Jose CA 95134 423 USA 425 Email: stig@cisco.com 427 Balaji Ganesh 428 Cisco Systems, Inc. 429 Tasman Drive 430 San Jose CA 95134 431 USA 433 Email: balagane@cisco.com 435 Kesavan Thiruvenkatasamy 436 Cisco Systems, Inc. 437 Tasman Drive 438 San Jose CA 95134 439 USA 441 Email: kethiruv@cisco.com 442 Ramakrishnan Chokkanathapuram 443 Cisco Systems, Inc. 444 Tasman Drive 445 San Jose CA 95134 446 USA 448 Email: ramaksun@cisco.com