idnits 2.17.1 draft-ietf-pim-source-discovery-bsr-08.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2018) is 2263 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands 3 Internet-Draft S. Venaas 4 Intended status: Experimental Cisco Systems, Inc. 5 Expires: July 20, 2018 M. Brig 6 Aegis BMD Program Office 7 A. Jonasson 8 Swedish Defence Material Administration (FMV) 9 January 16, 2018 11 PIM Flooding Mechanism and Source Discovery 12 draft-ietf-pim-source-discovery-bsr-08 14 Abstract 16 PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared 17 trees to forward multicast packets from new sources. Once last hop 18 routers receive packets from a new source, they may join the Shortest 19 Path Tree for the source for optimal forwarding. This draft defines 20 a new mechanism that provides a way to support PIM-SM without the 21 need for PIM registers, RPs or shared trees. Multicast source 22 information is flooded throughout the multicast domain using a new 23 generic PIM flooding mechanism. This allows last hop routers to 24 learn about new sources without receiving initial data packets. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 20, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Testing and Deployment Experiences . . . . . . . . . . . . . 4 64 3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 4 65 3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6 66 3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7 67 3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7 68 3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 8 69 3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9 70 3.4.2. Processing and Forwarding of PFM Messages . . . . . . 9 71 4. Distributing Source Group Mappings . . . . . . . . . . . . . 10 72 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 10 73 4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 11 74 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 12 75 4.4. The First Packets and Bursty Sources . . . . . . . . . . 12 76 4.5. Resiliency to Network Partitioning . . . . . . . . . . . 13 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 8.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared 88 trees to forward multicast packets to Last Hop Routers (LHR). After 89 the first packet is received by a LHR, the source of the multicast 90 stream is learned and the Shortest Path Tree (SPT) can be joined. 91 This draft defines a new mechanism that provides a way to support 92 PIM-SM without the need for PIM registers, RPs or shared trees. 93 Multicast source information is flooded throughout the multicast 94 domain using a new generic PIM flooding mechanism. By removing the 95 need for RPs and shared trees, the PIM-SM procedures are simplified, 96 improving router operations, management and making the protocol more 97 robust. Also the data packets are only sent on the SPTs, providing 98 optimal forwarding. 100 This mechanism has some similarities to PIM Dense Mode (PIM-DM) with 101 its State-Refresh signaling [RFC3973], except that there is no 102 initial flooding of data packets for new sources. It provides the 103 traffic efficiency of PIM-SM, while being as easy to deploy as PIM- 104 DM. The downside is that it cannot provide forwarding of initial 105 packets from a new source, see Section 4.4. PIM-DM is very different 106 from PIM-SM and not as mature, Experimental vs Internet Standard, and 107 there are only a few implementations. The solution in this document 108 consists of a lightweight source discovery mechanism on top of the 109 Source-Specific Multicast (SSM) parts of PIM-SM. It is feasable to 110 implement only a subset of PIM-SM to provide SSM support, and in 111 addition implement the mechanism in this draft to offer a source 112 discovery mechanism for applications that do not provide their own 113 source discovery. 115 This document defines a generic flooding mechanism for distributing 116 information throughout a PIM domain. While the forwarding rules are 117 largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any 118 router can originate information, and it allows for flooding of any 119 kind of information. Each message contains one or more pieces of 120 information encoded as TLVs (type, length and value). This document 121 defines one TLV used for distributing information about active 122 multicast sources. Other documents may define additional TLVs. 124 Note that this document is experimental. While the flooding 125 mechanism is largely similar to BSR, there are some concerns about 126 scale as there can be multiple routers distributing information, and 127 potentially larger amount of data that needs to be processed and 128 stored. Distributing knowledge of active sources in this way is new, 129 and there are some concerns, mainly regarding potentially large 130 amounts of source states that need to be distributed. While there 131 has been some testing in the field, we need to learn more about the 132 forwarding efficiency, both the amount of processing per router, and 133 propagation delay, and the amount of state that can be distributed. 134 In particular, how many active sources one can support without 135 consuming too many resources. There are also parameters that can be 136 tuned regarding how frequently information is distributed, and it is 137 not clear what parameters are useful for different types of networks. 139 1.1. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 1.2. Terminology 147 RP: Rendezvous Point 149 BSR: Bootstrap Router 151 RPF: Reverse Path Forwarding 153 SPT: Shortest Path Tree 155 FHR: First Hop Router, directly connected to the source 157 LHR: Last Hop Router, directly connected to the receiver 159 PFM: PIM Flooding Mechanism 161 PFM-SD: PFM Source Discovery 163 SG Mapping: Multicast source group mapping 165 2. Testing and Deployment Experiences 167 A prototype of this specification has been implemented and there has 168 been some limited testing in the field. The prototype was tested in 169 a network with low bandwidth radio links. The network has frequent 170 topology changes, including frequent link or router failures. 171 Previously existing mechanisms like PIM-SM and PIM-DM were tested. 173 With PIM-SM the existing RP election mechanisms were found to be too 174 slow. With PIM-DM, issues were observed with new multicast sources 175 starving low bandwidth links even when there are no receivers, in 176 some cases such that there was no bandwidth left for prune messages. 178 For the PFM-SD prototype tests, all routers were configured to send 179 PFM-SD for directly connected source and to cache received 180 announcements. Applications such as SIP with multicast subscriber 181 discovery, multicast voice conferencing, position tracking and NTP 182 were successfully tested. The tests went quite well. Packets were 183 rerouted as needed and there were no unnecessary forwarding of 184 packets. Ease of configuration was seen as a plus. 186 3. A Generic PIM Flooding Mechanism 188 The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used 189 mechanism for distributing dynamic Group to RP mappings in PIM. It 190 is responsible for flooding information about such mappings 191 throughout a PIM domain, so that all routers in the domain can have 192 the same information. BSR as defined, is only able to distribute 193 Group to RP mappings. This document defines a more generic mechanism 194 that can flood any kind of information. Administrative boundaries, 195 see Section 3.2, may be configured to limit to which parts of a 196 network the information is flooded. 198 The forwarding rules are identical to BSR, except that one can 199 control whether routers should forward unsupported data types. For 200 some types of information it is quite useful that it can be 201 distributed without all routers having to support the particular 202 type, while there may also be types where it is necessary for every 203 single router to support it. The mechanism includes an originator 204 address which is used for RPF checking to restrict the flooding, and 205 prevent loops, just like BSR. Like BSR, messages are forwarded hop 206 by hop. Note that there is no equivalent to the BSR election 207 mechanism;, there can be multiple originators. This mechanism is 208 named the PIM Flooding Mechanism (PFM). 210 3.1. PFM Message Format 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |PIM Ver| Type |N| Reserved | Checksum | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Originator Address (Encoded-Unicast format) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 |T| Type 1 | Length 1 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Value 1 | 222 | . | 223 | . | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | . | 226 | . | 227 |T| Type n | Length n | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Value n | 230 | . | 231 | . | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 PIM Version, Reserved and Checksum: As specified in [RFC7761]. 236 Type: PIM Message Type. Value (pending IANA) for a PFM message. 238 [N]o-Forward bit: When set, this bit means that the PFM message is 239 not to be forwarded. This bit is defined to prevent Bootstrap 240 message forwarding in [RFC5059]. 242 Originator Address: The address of the router that originated the 243 message. This can be any address assigned to the originating 244 router, but MUST be routable in the domain to allow successful 245 forwarding. The format for this address is given in the Encoded- 246 Unicast address in [RFC7761]. 248 [T]ransitive bit: Each TLV in the message includes a bit called the 249 Transitive bit that controls whether the TLV is forwarded by 250 routers that do not support the given type. See Section 3.4.2. 252 Type 1..n: A message contains one or more TLVs, in this case n 253 TLVs. The Type specifies what kind of information is in the 254 Value. The type range is from 0 to 32767 (15 bits). 256 Length 1..n: The length of the the value field in octets. 258 Value 1..n: The value associated with the type and of the specified 259 length. 261 3.2. Administrative Boundaries 263 PFM messages are generally forwarded hop by hop to all PIM routers. 264 However, similar to BSR, one may configure administrative boundaries 265 to limit the information to certain domains or parts of the network. 266 Implementations MUST have a way of defining a set of interfaces on a 267 router as administrative boundaries for all PFM messages, or 268 optionally for certain TLVs, allowing for different boundaries for 269 different TLVs. Usually one wants boundaries to be bidirectional, 270 but an implementation MAY also provide unidirectional boundaries. 271 When forwarding a message, a router MUST NOT send it out an interface 272 that is an outgoing boundary, including bidirectional boundary, for 273 all PFM messages. If an interface is an outgoing boundary for 274 certain TLVs, the message MUST NOT be sent out the interface if it is 275 a boundary for all the TLVs in the message. Otherwise the router 276 MUST remove all the boundary TLVs from the message and send the 277 message with the remaining TLVs. Also, when receiving a PFM message 278 on an interface, the message MUST be discarded if the interface is an 279 incoming boundary, including bidirectional boundary, for all PFM 280 messages. If the interface is an incoming boundary for certain TLVs, 281 the router MUST ignore all boundary TLVs. If all the TLVs in the 282 message are boundary TLVs, then the message is effectively ignored. 283 Note that when forwarding an incoming message, the boundary is 284 applied before forwarding. If the message was discarded or all the 285 TLVs were ignored, then no message is forwarded. When a message is 286 forwarded, it MUST NOT contain any TLVs for which the incoming 287 interface is an incoming, or bidirectional, boundary. 289 3.3. Originating PFM Messages 291 A router originates a PFM message when it needs to distribute 292 information using a PFM message to other routers in the network. 293 When a message is originated depends on what information is 294 distributed. For instance this document defines a TLV to distribute 295 information about active sources. When a router has a new active 296 source, a PFM message should be sent as soon as possible. Hence a 297 PFM message should be sent every time there is a new active source. 298 However, the TLV also contains a holdtime and PFM messages need to be 299 sent periodically. Generally speaking, a PFM message would typically 300 be sent when there is a local state change, causing information to be 301 distributed with PFM to change. Also, some information may need to 302 be sent periodically. These messages are called triggered and 303 periodic messages, respectively. Each TLV definition will need to 304 define when a triggered PFM message needs to be originated, and also 305 whether to send periodic messages, and how frequent. 307 Unless otherwise specified by the TLV definitions, there is no 308 relationship between different TLVs, and an implementation can choose 309 whether to combine TLVs in one message or across separate messages. 310 It is RECOMMENDED to combine multiple TLVs in one message, to reduce 311 the number of messages, but it is also RECOMMENDED that the message 312 is small enough to avoid fragmentation at the IP layer. When a 313 triggered PFM message needs to be sent due to a state change, a 314 router MAY send a message containing only the information that 315 changed. If there are many changes occuring at about the same time, 316 it might be possible to combine multiple changes in one message. In 317 the case where periodic messages are also needed, an implementation 318 MAY include periodic PFM information in a triggered PFM. E.g., if 319 some information needs to be sent every 60 seconds and a triggered 320 PFM is about to be sent 20 seconds before the next periodic PFM was 321 scheduled, the triggered PFM might include the periodic information 322 and the next periodic PFM can then be scheduled 60 seconds after 323 that, rather than 20 seconds later. 325 When a router originates a PFM message, it puts one of its own 326 addresses in the originator field. An implementation MUST allow an 327 administrator to configure which address is used. For a message to 328 be received by all routers in a domain, all the routers need to have 329 a route for this address due to the RPF based forwarding. Hence an 330 administrator needs to be careful which address to choose. When this 331 is not configured, an implementation MUST NOT use a link-local 332 address. It is RECOMMENDED to use an address of a virtual interface 333 such that the originator can remain unchanged and routable 334 independent of which physical interfaces or links may go down. 336 The No-Forward bit MUST NOT be set, except for the case when a router 337 receives a PIM Hello from a new neighbor, or a PIM Hello with a new 338 Generation Identifier, defined in [RFC7761], is received from an 339 existing neighbor. In that case an implementation MAY send PFM 340 messages containing relevant information so that the neighbor can 341 quickly get the correct state. The definition of the different PFM 342 message TLVs need to specify what, if anything, needs to be sent in 343 this case. If such a PFM message is sent, the No-Forward bit MUST be 344 set, and the message must be sent within 60 seconds after the 345 neighbor state change. The processing rules for PFM messages will 346 ensure that any other neighbors on the same link ignores the message. 347 This behavior and the choice of 60 seconds is similar to what is 348 defined for the No-Forward bit in [RFC5059]. 350 3.4. Processing PFM Messages 352 A router that receives a PFM message MUST perform the initial checks 353 specified here. If the checks fail, the message MUST be dropped. An 354 error MAY be logged, but otherwise the message MUST be dropped 355 silently. If the checks pass, the contents is processed according to 356 the processing rules of the included TLVs. 358 3.4.1. Initial Checks 360 In order to do further processing, a message MUST meet the following 361 requirements. The message MUST be from a directly connected PIM 362 neighbor, the destination address MUST be ALL-PIM-ROUTERS. Also, the 363 interface MUST NOT be an incoming, nor bidirectional, administrative 364 boundary for PFM messages, see Section 3.2. If No-Forward is not 365 set, the message MUST be from the RPF neighbor of the originator 366 address. If No-Forward is set, this system, the router doing these 367 checks, MUST have enabled the PIM protocol within the last 60 368 seconds. See Section 3.3 for details. In pseudo-code the algorithm 369 is as follows: 371 if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR 372 (PFM.src_ip_address is not a PIM neighbor) OR 373 (PFM.dst_ip_address != ALL-PIM-ROUTERS) OR 374 (Incoming interface is admin boundary for PFM)) { 375 drop the message silently, optionally log error. 376 } 377 if (PFM.no_forward_bit == 0) { 378 if (PFM.src_ip_address != 379 RPF_neighbor(PFM.originator_ip_address)) { 380 drop the message silently, optionally log error. 381 } 382 } else if (more than 60 seconds elapsed since PIM enabled)) { 383 drop the message silently, optionally log error. 384 } 386 Note that src_ip_address is the source address in the IP header of 387 the PFM message. Originator is the originator field inside the PFM 388 message, and is the router that originated the message. When the 389 message is forwarded hop by hop, the originator address never 390 changes, while the source address will be an address belonging to the 391 router that last forwarded the message. 393 3.4.2. Processing and Forwarding of PFM Messages 395 When the message is received, the initial checks above must be 396 performed. If it passes the checks, then for each included TLV, 397 perform processing according to the specification for that TLV. 399 After processing, the messsage is forwarded. Some TLVs may be 400 omitted or modified in the forwarded message. This depends on 401 administrative boundaries, see Section 3.2, the type specification 402 and the setting of the Transitive bit for the TLV. If a router 403 supports the type, then the TLV is forwarded with no changes unless 404 otherwise specified by the type specification. A router not 405 supporting the given type MUST include the TLV in the forwarded 406 message if and only if the Transitive bit is set. Whether a router 407 supports the type or not, the value of the Transitive bit MUST be 408 preserved if the TLV is included in the forwarded message. The 409 message is forwarded out of all interfaces with PIM neighbors 410 (including the interface it was received on). As specified in 411 Section 3.2, if an interface is an outgoing boundary for any TLVs, 412 the message MUST NOT be sent out the interface if it is an outgoing 413 boundary for all the TLVs in the message. Otherwise the router MUST 414 remove any outgoing boundary TLVs of the interface from the message 415 and send the message out that interface with the remaining TLVs. 417 4. Distributing Source Group Mappings 419 The generic flooding mechanism (PFM) defined in the previous section 420 can be used for distributing source group mappings about active 421 multicast sources throughout a PIM domain. A Group Source Holdtime 422 (GSH) TLV is defined for this purpose. 424 4.1. Group Source Holdtime TLV 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |1| Type = 1 | Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Group Address (Encoded-Group format) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Src Count | Src Holdtime | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Src Address 1 (Encoded-Unicast format) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Src Address 2 (Encoded-Unicast format) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | . | 440 | . | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Src Address m (Encoded-Unicast format) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 1: The Transitive bit is set to 1. This means that this type will 446 be forwarded even if a router does not support it. See 447 Section 3.4.2. 449 Type: This TLV has type 1. 451 Length: The length of the value in octets. 453 Group Address: The group that sources are to be announced for. The 454 format for this address is given in the Encoded-Group format in 455 [RFC7761]. 457 Src Count: The number of source addresses that are included. 459 Src Holdtime: The Holdtime (in seconds) for the included source(s). 461 Src Address: The source address for the corresponding group. The 462 format for these addresses is given in the Encoded-Unicast address 463 in [RFC7761]. 465 4.2. Originating Group Source Holdtime TLVs 467 A PFM message MAY contain one or more Group Source Holdtime (GSH) 468 TLVs. This is used to flood information about active multicast 469 sources. Each FHR that is directly connected to an active multicast 470 source originates PFM messages containing GSH TLVs. How a multicast 471 router discovers the source of the multicast packet and when it 472 considers itself the FHR follows the same procedures as the 473 registering process described in [RFC7761]. When a FHR has decided 474 that a register needs to be sent per [RFC7761], the SG is not 475 registered via the PIM SM register procedures, but the SG mapping is 476 included in an GSH TLV in a PFM message. Note, only the SG mapping 477 is distributed in the message, not the entire packet as would have 478 been done with a PIM register. The PFM messages containing the GSH 479 TLV are periodically sent for as long as the multicast source is 480 active, similar to how PIM registers are periodically sent. The 481 default announcement period is 60 seconds, which means that as long 482 as the source is active, it is included in a PFM message originated 483 every 60 seconds. The holdtime for the source MUST be either zero, 484 or larger than the announcement period. It is RECOMMENDED to be 3.5 485 times the announcement period. The default holdtime is 210 seconds, 486 other values MAY be configured. A source MAY be announced with a 487 holdtime of zero to indicate that the source is no longer active. 489 If an implementation supports originating GSH TLVs with different 490 holdtimes for different sources, it can if needed send multiple TLVs 491 with the same group address. Due to the format, all the sources in 492 the same TLV have the same holdtime. 494 When a new source is detected, an implementation MAY send a PFM 495 message containing just that particular source. However, it MAY also 496 include information about other sources that were just detected, so 497 sources that are scheduled for periodic announcement later, or other 498 types of information. See Section 3.3 for details. 500 When a new PIM neighbor is detected, or an existing neighbor changes 501 Generation Identifier, an implementation MAY send a triggered PFM 502 message containing GSH TLVs for any Source Group mappings it has 503 learned by receiving PFM GSH TLVs as well as any active directly 504 connected sources. See Section 3.3 for further details. 506 4.3. Processing GSH TLVs 508 A router that receives a PFM message containing GSH TLVs MUST parse 509 the GSH TLVs and store each of the GSH TLVs as SG mappings with a 510 holdtimer started with the advertised holdtime, unless the 511 implementation specifically does not support GSH TLVs, the router is 512 configured to ignore GSH TLVs in general, or to ignore GSH TLVs for 513 certain sources or groups. In particular, an administrator might 514 configure a router to not process GSH TLVs if the router is known to 515 never have any directly connected receivers. 517 For each group that has directly connected receivers, this router 518 SHOULD send PIM (S,G) joins for all the SG mappings advertised in the 519 message for the group. Generally joins are sent, but there could for 520 instance be administrative policy limiting which sources and groups 521 to join. The SG mappings are kept alive for as long as the holdtimer 522 for the source is running. Once the holdtimer expires a PIM router 523 MAY send a PIM (S,G) prune to remove itself from the tree. However, 524 when this happens, there should be no more packets sent by the 525 source, so it may be desirable to allow the state to time out rather 526 than sending a prune. 528 Note that a holdtime of zero has a special meaning. It is to be 529 treated as if the source just expired, and state to be removed. 530 Source information MUST NOT be removed due to the source being 531 omitted in a message. For instance, if there is a large number of 532 sources for a group, there may be multiple PFM messages, each message 533 containing a different list of sources for the group. 535 4.4. The First Packets and Bursty Sources 537 The PIM register procedure is designed to deliver Multicast packets 538 to the RP in the absence of a Shortest Path Tree (SPT) from the RP to 539 the source. The register packets received on the RP are decapsulated 540 and forwarded down the shared tree to the LHRs. As soon as an SPT is 541 built, multicast packets would flow natively over the SPT to the RP 542 or LHR and the register process would stop. The PIM register process 543 ensures packet delivery until an SPT is in place reaching the FHR. 544 If the packets were not unicast encapsulated to the RP they would be 545 dropped by the FHR until the SPT is setup. This functionality is 546 important for applications where the initial packet(s) must be 547 received for the application to work correctly. Another reason would 548 be for bursty sources. If the application sends out a multicast 549 packet every 4 minutes (or longer), the SPT is torn down (typically 550 after 3:30 minutes of inactivity) before the next packet is forwarded 551 down the tree. This will cause no multicast packet to ever be 552 forwarded. A well behaved application should be able to deal with 553 packet loss since IP is a best effort based packet delivery system. 554 But in reality this is not always the case. 556 With the procedures defined in this document the packet(s) received 557 by the FHR will be dropped until the LHR has learned about the source 558 and the SPT is built. That means for bursty sources or applications 559 sensitive for the delivery of the first packet this solution would 560 not be very applicable. This solution is mostly useful for 561 applications that don't have strong dependency on the initial 562 packet(s) and have a fairly constant data rate, like video 563 distribution for example. For applications with strong dependency on 564 the initial packet(s) using PIM Bidir [RFC5015] or SSM [RFC4607] is 565 recommended. The protocol operations are much simpler compared to 566 PIM SM, it will cause less churn in the network and both guarantee 567 best effort delivery for the initial packet(s). 569 4.5. Resiliency to Network Partitioning 571 In a PIM SM deployment where the network becomes partitioned, due to 572 link or node failure, it is possible that the RP becomes unreachable 573 to a certain part of the network. New sources that become active in 574 that partition will not be able to register to the RP and receivers 575 within that partition are not able to receive the traffic. Ideally 576 you would want to have a candidate RP in each partition, but you 577 never know in advance which routers will form a partitioned network. 578 In order to be fully resilient, each router in the network may end up 579 being a candidate RP. This would increase the operational complexity 580 of the network. 582 The solution described in this document does not suffer from that 583 problem. If a network becomes partitioned and new sources become 584 active, the receivers in that partitioned will receive the SG 585 Mappings and join the source tree. Each partition works 586 independently of the other partition(s) and will continue to have 587 access to sources within that partition. Once the network has 588 healed, the periodic flooding of SG Mappings ensures that they are 589 re-flooded into the other partition(s) and other receivers can join 590 to the newly learned sources. 592 5. Security Considerations 594 When it comes to general PIM message security, see [RFC7761]. PFM 595 messages MUST only be accepted from a PIM neighbor, but as discussed 596 in [RFC7761], any router can become a PIM neighbor by sending a Hello 597 message. To control from where to accept PFM packets, one can limit 598 which interfaces PIM is enabled, and also one can configure 599 interfaces as administrative boundaries for PFM messages, see 600 Section 3.2. The implications of forged PFM messages depend on which 601 TLVs they contain. Documents defining new TLVs will need to discuss 602 the security considerations for the specific TLVs. In general 603 though, the PFM messages are flooded within the network, and by 604 forging a large number of PFM messages one might stress all the 605 routers in the network. 607 If an attacker can forge PFM messages, then such messages may contain 608 arbitrary GSH TLVs. An issue here is that an attacker might send 609 such TLVs for a huge amount of sources, potentially causing every 610 router in the network to store huge amounts of source state. Also, 611 if there is receiver interest for the groups specified in the GSH 612 TLVs, routers with directly connected receivers will build Shortest 613 Path Trees for the announced sources, even if the sources are not 614 actually active. Building such trees will consume additional 615 resources on routers that the trees pass through. 617 PIM-SM link-local messages can be authenticated using IPsec, see 618 [RFC7761] section 6.3 and [RFC5796]. Since PFM messages are link- 619 local messages sent hop by hop, a link-local PFM message can be 620 authenticated using IPsec such that a router can verify that a 621 message was sent by a trusted neighbor and has not been modified. 622 However, to verify that a received message contains correct 623 information announced by the originator specified in the message, one 624 will have to trust every router on the path from the originator and 625 that each router has authenticated the received message. 627 6. IANA Considerations 629 This document requires the assignment of a new PIM message type for 630 the PIM Flooding Mechanism (PFM) with the name "PIM Flooding 631 Mechanism". IANA is also requested to create a registry for PFM TLVs 632 called "PIM Flooding Mechanism Message Types". Assignments for the 633 registry are to be made according to the policy "IETF Review" as 634 defined in [RFC8126]. The initial content of the registry should be: 636 Type Name Reference 637 -------------------------------------------------- 638 0 Reserved [this document] 639 1 Source Group Holdtime [this document] 640 2-32767 Unassigned 642 7. Acknowledgments 644 The authors would like to thank Arjen Boers for contributing to the 645 initial idea, and Stewart Bryant, Yiqun Cai, Toerless Eckert, Dino 646 Farinacci, Alvaro Retana and Liang Xia for their very helpful 647 comments on the draft. 649 8. References 651 8.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 659 "Bootstrap Router (BSR) Mechanism for Protocol Independent 660 Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 661 2008, . 663 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 664 Confidentiality in Protocol Independent Multicast Sparse 665 Mode (PIM-SM) Link-Local Messages", RFC 5796, 666 DOI 10.17487/RFC5796, March 2010, 667 . 669 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 670 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 671 Multicast - Sparse Mode (PIM-SM): Protocol Specification 672 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 673 2016, . 675 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 676 Writing an IANA Considerations Section in RFCs", BCP 26, 677 RFC 8126, DOI 10.17487/RFC8126, June 2017, 678 . 680 8.2. Informative References 682 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 683 Independent Multicast - Dense Mode (PIM-DM): Protocol 684 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 685 January 2005, . 687 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 688 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 689 . 691 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 692 "Bidirectional Protocol Independent Multicast (BIDIR- 693 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 694 . 696 Authors' Addresses 698 IJsbrand Wijnands 699 Cisco Systems, Inc. 700 De kleetlaan 6a 701 Diegem 1831 702 Belgium 704 Email: ice@cisco.com 706 Stig Venaas 707 Cisco Systems, Inc. 708 Tasman Drive 709 San Jose CA 95134 710 USA 712 Email: stig@cisco.com 714 Michael Brig 715 Aegis BMD Program Office 716 17211 Avenue D, Suite 160 717 Dahlgren VA 22448-5148 718 USA 720 Email: michael.brig@mda.mil 721 Anders Jonasson 722 Swedish Defence Material Administration (FMV) 723 Loennvaegen 4 724 Vaexjoe 35243 725 Sweden 727 Email: anders@jomac.se