idnits 2.17.00 (12 Aug 2021) /tmp/idnits42514/draft-ietf-pim-source-discovery-bsr-12.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 31, 2018) is 1564 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: August 4, 2018 M. Brig 6 Aegis BMD Program Office 7 A. Jonasson 8 Swedish Defence Material Administration (FMV) 9 January 31, 2018 11 PIM Flooding Mechanism and Source Discovery 12 draft-ietf-pim-source-discovery-bsr-12 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 August 4, 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 . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Testing and Deployment Experiences . . . . . . . . . . . . . 4 64 3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 9 69 3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9 70 3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 13 75 4.4. The First Packets and Bursty Sources . . . . . . . . . . 13 76 4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14 77 5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 14 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 9.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 PIM Sparse-Mode (PIM-SM) [RFC7761] uses a Rendezvous Point (RP) and 89 shared trees to forward multicast packets to Last Hop Routers (LHR). 90 After the first packet is received by a LHR, the source of the 91 multicast stream is learned and the Shortest Path Tree (SPT) can be 92 joined. This draft defines a new mechanism that provides a way to 93 support PIM-SM without the need for PIM registers, RPs or shared 94 trees. Multicast source information is flooded throughout the 95 multicast domain using a new generic PIM flooding mechanism. By 96 removing the need for RPs and shared trees, the PIM-SM procedures are 97 simplified, improving router operations, management and making the 98 protocol more robust. Also the data packets are only sent on the 99 SPTs, providing optimal forwarding. 101 This mechanism has some similarities to PIM Dense Mode (PIM-DM) with 102 its State-Refresh signaling [RFC3973], except that there is no 103 initial flooding of data packets for new sources. It provides the 104 traffic efficiency of PIM-SM, while being as easy to deploy as PIM- 105 DM. The downside is that it cannot provide forwarding of initial 106 packets from a new source, see Section 4.4. PIM-DM is very different 107 from PIM-SM and not as mature, Experimental vs Internet Standard, and 108 there are only a few implementations. The solution in this document 109 consists of a lightweight source discovery mechanism on top of the 110 Source-Specific Multicast (SSM) [RFC4607] parts of PIM-SM. It is 111 feasable to implement only a subset of PIM-SM to provide SSM support, 112 and in addition implement the mechanism in this draft to offer a 113 source discovery mechanism for applications that do not provide their 114 own source discovery. 116 This document defines a generic flooding mechanism for distributing 117 information throughout a PIM domain. While the forwarding rules are 118 largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any 119 router can originate information, and it allows for flooding of any 120 kind of information. Each message contains one or more pieces of 121 information encoded as TLVs (type, length and value). This document 122 defines one TLV used for distributing information about active 123 multicast sources. Other documents may define additional TLVs. 125 Note that this document is experimental. While the flooding 126 mechanism is largely similar to BSR, there are some concerns about 127 scale as there can be multiple routers distributing information, and 128 potentially larger amount of data that needs to be processed and 129 stored. Distributing knowledge of active sources in this way is new, 130 and there are some concerns, mainly regarding potentially large 131 amounts of source states that need to be distributed. While there 132 has been some testing in the field, we need to learn more about the 133 forwarding efficiency, both the amount of processing per router, and 134 propagation delay, and the amount of state that can be distributed. 135 In particular, how many active sources one can support without 136 consuming too many resources. There are also parameters, see 137 Section 5, that can be tuned regarding how frequently information is 138 distributed, and it is not clear what parameters are useful for 139 different types of networks. 141 1.1. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 1.2. Terminology 149 RP: Rendezvous Point 151 BSR: Bootstrap Router 153 RPF: Reverse Path Forwarding 155 SPT: Shortest Path Tree 157 FHR: First Hop Router, directly connected to the source 159 LHR: Last Hop Router, directly connected to the receiver 161 PFM: PIM Flooding Mechanism 163 PFM-SD: PFM Source Discovery 165 SG Mapping: Multicast source group mapping 167 2. Testing and Deployment Experiences 169 A prototype of this specification has been implemented and there has 170 been some limited testing in the field. The prototype was tested in 171 a network with low bandwidth radio links. The network has frequent 172 topology changes, including frequent link or router failures. 173 Previously existing mechanisms like PIM-SM and PIM-DM were tested. 175 With PIM-SM the existing RP election mechanisms were found to be too 176 slow. With PIM-DM, issues were observed with new multicast sources 177 starving low bandwidth links even when there are no receivers, in 178 some cases such that there was no bandwidth left for prune messages. 180 For the PFM-SD prototype tests, all routers were configured to send 181 PFM-SD for directly connected source and to cache received 182 announcements. Applications such as SIP with multicast subscriber 183 discovery, multicast voice conferencing, position tracking and NTP 184 were successfully tested. The tests went quite well. Packets were 185 rerouted as needed and there were no unnecessary forwarding of 186 packets. Ease of configuration was seen as a plus. 188 3. A Generic PIM Flooding Mechanism 190 The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used 191 mechanism for distributing dynamic Group to RP mappings in PIM. It 192 is responsible for flooding information about such mappings 193 throughout a PIM domain, so that all routers in the domain can have 194 the same information. BSR as defined, is only able to distribute 195 Group to RP mappings. This document defines a more generic mechanism 196 that can flood any kind of information. Administrative boundaries, 197 see Section 3.2, may be configured to limit to which parts of a 198 network the information is flooded. 200 The forwarding rules are identical to BSR, except that one can 201 control whether routers should forward unsupported data types. For 202 some types of information it is quite useful that it can be 203 distributed without all routers having to support the particular 204 type, while there may also be types where it is necessary for every 205 single router to support it. The mechanism includes an originator 206 address which is used for RPF checking to restrict the flooding, and 207 prevent loops, just like BSR. Like BSR, messages are forwarded hop 208 by hop; the messages are link-local and each router will process and 209 resend the messages. Note that there is no equivalent to the BSR 210 election mechanism; there can be multiple originators. This 211 mechanism is named the PIM Flooding Mechanism (PFM). 213 3.1. PFM Message Format 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |PIM Ver| Type |N| Reserved | Checksum | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Originator Address (Encoded-Unicast format) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |T| Type 1 | Length 1 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Value 1 | 225 | . | 226 | . | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | . | 229 | . | 230 |T| Type n | Length n | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Value n | 233 | . | 234 | . | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 PIM Version, Reserved and Checksum: As specified in [RFC7761]. 239 Type: PIM Message Type. Value (pending IANA) for a PFM message. 241 [N]o-Forward bit: When set, this bit means that the PFM message is 242 not to be forwarded. This bit is defined to prevent Bootstrap 243 message forwarding in [RFC5059]. 245 Originator Address: The address of the router that originated the 246 message. This can be any address assigned to the originating 247 router, but MUST be routable in the domain to allow successful 248 forwarding. The format for this address is given in the Encoded- 249 Unicast address in [RFC7761]. 251 [T]ransitive bit: Each TLV in the message includes a bit called the 252 Transitive bit that controls whether the TLV is forwarded by 253 routers that do not support the given type. See Section 3.4.2. 255 Type 1..n: A message contains one or more TLVs, in this case n 256 TLVs. The Type specifies what kind of information is in the 257 Value. The type range is from 0 to 32767 (15 bits). 259 Length 1..n: The length of the the value field in octets. 261 Value 1..n: The value associated with the type and of the specified 262 length. 264 3.2. Administrative Boundaries 266 PFM messages are generally forwarded hop by hop to all PIM routers. 267 However, similar to BSR, one may configure administrative boundaries 268 to limit the information to certain domains or parts of the network. 269 Implementations MUST have a way of defining a set of interfaces on a 270 router as administrative boundaries for all PFM messages, or 271 optionally for certain TLVs, allowing for different boundaries for 272 different TLVs. Usually one wants boundaries to be bidirectional, 273 but an implementation MAY also provide unidirectional boundaries. 274 When forwarding a message, a router MUST NOT send it out an interface 275 that is an outgoing boundary, including bidirectional boundary, for 276 all PFM messages. If an interface is an outgoing boundary for 277 certain TLVs, the message MUST NOT be sent out the interface if it is 278 a boundary for all the TLVs in the message. Otherwise the router 279 MUST remove all the boundary TLVs from the message and send the 280 message with the remaining TLVs. Also, when receiving a PFM message 281 on an interface, the message MUST be discarded if the interface is an 282 incoming boundary, including bidirectional boundary, for all PFM 283 messages. If the interface is an incoming boundary for certain TLVs, 284 the router MUST ignore all boundary TLVs. If all the TLVs in the 285 message are boundary TLVs, then the message is effectively ignored. 286 Note that when forwarding an incoming message, the boundary is 287 applied before forwarding. If the message was discarded or all the 288 TLVs were ignored, then no message is forwarded. When a message is 289 forwarded, it MUST NOT contain any TLVs for which the incoming 290 interface is an incoming, or bidirectional, boundary. 292 3.3. Originating PFM Messages 294 A router originates a PFM message when it needs to distribute 295 information using a PFM message to other routers in the network. 296 When a message is originated depends on what information is 297 distributed. For instance this document defines a TLV to distribute 298 information about active sources. When a router has a new active 299 source, a PFM message should be sent as soon as possible. Hence a 300 PFM message should be sent every time there is a new active source. 301 However, the TLV also contains a holdtime and PFM messages need to be 302 sent periodically. Generally speaking, a PFM message would typically 303 be sent when there is a local state change, causing information to be 304 distributed with PFM to change. Also, some information may need to 305 be sent periodically. These messages are called triggered and 306 periodic messages, respectively. Each TLV definition will need to 307 define when a triggered PFM message needs to be originated, and also 308 whether to send periodic messages, and how frequent. 310 A router MUST NOT originate more than Max_PFM_Message_Rate messages 311 per minute. This document does not mandate how this should be 312 implemented, but some possible ways could be having a minimal time 313 between each message, counting the number of messages originated and 314 resetting the count every minute, or using a leaky bucket algorithm. 315 One benefit of using a leaky bucket algorithm is that it can handle 316 bursts better. The default value of Max_PFM_Message_Rate is 6. The 317 value MUST be configurable. Depending on the network, one may want 318 to use a larger value of Max_PFM_Message_Rate to favor propagation of 319 new information, but with a large number of routers and many updates, 320 the total number of messages might become too large and require too 321 much processing. 323 There MUST be a minimum of Min_PFM_Message_Gap milliseconds between 324 each originated message. The default value of Min_PFM_Message_Gap is 325 1000 (1 second). The value MUST be configurable. 327 Unless otherwise specified by the TLV definitions, there is no 328 relationship between different TLVs, and an implementation can choose 329 whether to combine TLVs in one message or across separate messages. 330 It is RECOMMENDED to combine multiple TLVs in one message, to reduce 331 the number of messages, but it is also RECOMMENDED that the message 332 is small enough to avoid fragmentation at the IP layer. When a 333 triggered PFM message needs to be sent due to a state change, a 334 router MAY send a message containing only the information that 335 changed. If there are many changes occuring at about the same time, 336 it might be possible to combine multiple changes in one message. In 337 the case where periodic messages are also needed, an implementation 338 MAY include periodic PFM information in a triggered PFM. E.g., if 339 some information needs to be sent every 60 seconds and a triggered 340 PFM is about to be sent 20 seconds before the next periodic PFM was 341 scheduled, the triggered PFM might include the periodic information 342 and the next periodic PFM can then be scheduled 60 seconds after 343 that, rather than 20 seconds later. 345 When a router originates a PFM message, it puts one of its own 346 addresses in the originator field. An implementation MUST allow an 347 administrator to configure which address is used. For a message to 348 be received by all routers in a domain, all the routers need to have 349 a route for this address due to the RPF based forwarding. Hence an 350 administrator needs to be careful which address to choose. When this 351 is not configured, an implementation MUST NOT use a link-local 352 address. It is RECOMMENDED to use an address of a virtual interface 353 such that the originator can remain unchanged and routable 354 independent of which physical interfaces or links may go down. 356 The No-Forward bit MUST NOT be set, except for the case when a router 357 receives a PIM Hello from a new neighbor, or a PIM Hello with a new 358 Generation Identifier, defined in [RFC7761], is received from an 359 existing neighbor. In that case an implementation MAY send PFM 360 messages containing relevant information so that the neighbor can 361 quickly get the correct state. The definition of the different PFM 362 message TLVs need to specify what, if anything, needs to be sent in 363 this case. If such a PFM message is sent, the No-Forward bit MUST be 364 set, and the message must be sent within 60 seconds after the 365 neighbor state change. The processing rules for PFM messages will 366 ensure that any other neighbors on the same link ignores the message. 367 This behavior and the choice of 60 seconds is similar to what is 368 defined for the No-Forward bit in [RFC5059]. 370 3.4. Processing PFM Messages 372 A router that receives a PFM message MUST perform the initial checks 373 specified here. If the checks fail, the message MUST be dropped. An 374 error MAY be logged, but otherwise the message MUST be dropped 375 silently. If the checks pass, the contents is processed according to 376 the processing rules of the included TLVs. 378 3.4.1. Initial Checks 380 In order to do further processing, a message MUST meet the following 381 requirements. The message MUST be from a directly connected PIM 382 neighbor, the destination address MUST be ALL-PIM-ROUTERS. Also, the 383 interface MUST NOT be an incoming, nor bidirectional, administrative 384 boundary for PFM messages, see Section 3.2. If No-Forward is not 385 set, the message MUST be from the RPF neighbor of the originator 386 address. If No-Forward is set, this system, the router doing these 387 checks, MUST have enabled the PIM protocol within the last 60 388 seconds. See Section 3.3 for details. In pseudo-code the algorithm 389 is as follows: 391 if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR 392 (PFM.src_ip_address is not a PIM neighbor) OR 393 (PFM.dst_ip_address != ALL-PIM-ROUTERS) OR 394 (Incoming interface is admin boundary for PFM)) { 395 drop the message silently, optionally log error. 396 } 397 if (PFM.no_forward_bit == 0) { 398 if (PFM.src_ip_address != 399 RPF_neighbor(PFM.originator_ip_address)) { 400 drop the message silently, optionally log error. 401 } 402 } else if (more than 60 seconds elapsed since PIM enabled)) { 403 drop the message silently, optionally log error. 404 } 406 Note that src_ip_address is the source address in the IP header of 407 the PFM message. Originator is the originator field inside the PFM 408 message, and is the router that originated the message. When the 409 message is forwarded hop by hop, the originator address never 410 changes, while the source address will be an address belonging to the 411 router that last forwarded the message. 413 3.4.2. Processing and Forwarding of PFM Messages 415 When the message is received, the initial checks above must be 416 performed. If it passes the checks, then for each included TLV, 417 perform processing according to the specification for that TLV. 419 After processing, the messsage is forwarded. Some TLVs may be 420 omitted or modified in the forwarded message. This depends on 421 administrative boundaries, see Section 3.2, the type specification 422 and the setting of the Transitive bit for the TLV. If a router 423 supports the type, then the TLV is forwarded with no changes unless 424 otherwise specified by the type specification. A router not 425 supporting the given type MUST include the TLV in the forwarded 426 message if and only if the Transitive bit is set. Whether a router 427 supports the type or not, the value of the Transitive bit MUST be 428 preserved if the TLV is included in the forwarded message. The 429 message is forwarded out of all interfaces with PIM neighbors 430 (including the interface it was received on). As specified in 431 Section 3.2, if an interface is an outgoing boundary for any TLVs, 432 the message MUST NOT be sent out the interface if it is an outgoing 433 boundary for all the TLVs in the message. Otherwise the router MUST 434 remove any outgoing boundary TLVs of the interface from the message 435 and send the message out that interface with the remaining TLVs. 437 4. Distributing Source Group Mappings 439 The generic flooding mechanism (PFM) defined in the previous section 440 can be used for distributing source group mappings about active 441 multicast sources throughout a PIM domain. A Group Source Holdtime 442 (GSH) TLV is defined for this purpose. 444 4.1. Group Source Holdtime TLV 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |1| Type = 1 | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Group Address (Encoded-Group format) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Src Count | Src Holdtime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Src Address 1 (Encoded-Unicast format) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Src Address 2 (Encoded-Unicast format) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | . | 459 | . | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Src Address m (Encoded-Unicast format) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 1: The Transitive bit is set to 1. This means that this type will 465 be forwarded even if a router does not support it. See 466 Section 3.4.2. 468 Type: This TLV has type 1. 470 Length: The length of the value in octets. 472 Group Address: The group that sources are to be announced for. The 473 format for this address is given in the Encoded-Group format in 474 [RFC7761]. 476 Src Count: The number of source addresses that are included. 478 Src Holdtime: The Holdtime (in seconds) for the included source(s). 480 Src Address: The source address for the corresponding group. The 481 format for these addresses is given in the Encoded-Unicast address 482 in [RFC7761]. 484 4.2. Originating Group Source Holdtime TLVs 486 A PFM message MAY contain one or more Group Source Holdtime (GSH) 487 TLVs. This is used to flood information about active multicast 488 sources. Each FHR that is directly connected to an active multicast 489 source originates PFM messages containing GSH TLVs. How a multicast 490 router discovers the source of the multicast packet and when it 491 considers itself the FHR follows the same procedures as the 492 registering process described in [RFC7761]. When a FHR has decided 493 that a register needs to be sent per [RFC7761], the SG is not 494 registered via the PIM-SM register procedures, but the SG mapping is 495 included in an GSH TLV in a PFM message. Note, only the SG mapping 496 is distributed in the message, not the entire packet as would have 497 been done with a PIM register. 499 The PFM messages containing the GSH TLV are sent periodically for as 500 long as the multicast source is active, similar to how PIM registers 501 are sent periodically. This means that as long as the source is 502 active, it is included in a PFM message originated every 503 Group_Source_Holdtime_Period seconds, within the general PFM timing 504 requirements in Section 3.3. The default value of 505 Group_Source_Holdtime_Period is 60. The value MUST be configurable. 506 The holdtime for the source MUST be set to either zero or 507 Group_Source_Holdtime_Holdtime. The value of the 508 Group_Source_Holdtime_Holdtime parameter MUST be larger than 509 Group_Source_Holdtime_Period. It is RECOMMENDED to be 3.5 times the 510 Group_Source_Holdtime_Period. The default value is 210 (seconds). 511 The value MUST be configurable. A source MAY be announced with a 512 holdtime of zero to indicate that the source is no longer active. 514 If an implementation supports originating GSH TLVs with different 515 holdtimes for different sources, it can if needed send multiple TLVs 516 with the same group address. Due to the format, all the sources in 517 the same TLV have the same holdtime. 519 When a new source is detected, an implementation MAY send a PFM 520 message containing just that particular source. However, it MAY also 521 include information about other sources that were just detected, 522 sources that are scheduled for periodic announcement later, or other 523 types of information. See Section 3.3 for details. Note that when a 524 new source is detected, one should trigger sending of a PFM message 525 as soon as possible, while if a source becomes inactive, there is no 526 reason to trigger a message. There is no urgency in removing state 527 for inactive sources. Note that the message timing requirements in 528 Section 3.3 apply. This means that one cannot always send a 529 triggered message immediately when a new source is detected. In 530 order to meet the timing requirements, sending of the message may 531 have to be delayed a small amount of time. 533 When a new PIM neighbor is detected, or an existing neighbor changes 534 Generation Identifier, an implementation MAY send a triggered PFM 535 message containing GSH TLVs for any Source Group mappings it has 536 learned by receiving PFM GSH TLVs as well as any active directly 537 connected sources. See Section 3.3 for further details. 539 4.3. Processing GSH TLVs 541 A router that receives a PFM message containing GSH TLVs MUST parse 542 the GSH TLVs and store each of the GSH TLVs as SG mappings with a 543 holdtimer started with the advertised holdtime, unless the 544 implementation specifically does not support GSH TLVs, the router is 545 configured to ignore GSH TLVs in general, or to ignore GSH TLVs for 546 certain sources or groups. In particular, an administrator might 547 configure a router to not process GSH TLVs if the router is known to 548 never have any directly connected receivers. 550 For each group that has directly connected receivers, this router 551 SHOULD send PIM (S,G) joins for all the SG mappings advertised in the 552 message for the group. Generally joins are sent, but there could for 553 instance be administrative policy limiting which sources and groups 554 to join. The SG mappings are kept alive for as long as the holdtimer 555 for the source is running. Once the holdtimer expires a PIM router 556 MAY send a PIM (S,G) prune to remove itself from the tree. However, 557 when this happens, there should be no more packets sent by the 558 source, so it may be desirable to allow the state to time out rather 559 than sending a prune. 561 Note that a holdtime of zero has a special meaning. It is to be 562 treated as if the source just expired, and state to be removed. 563 Source information MUST NOT be removed due to the source being 564 omitted in a message. For instance, if there is a large number of 565 sources for a group, there may be multiple PFM messages, each message 566 containing a different list of sources for the group. 568 4.4. The First Packets and Bursty Sources 570 The PIM register procedure is designed to deliver Multicast packets 571 to the RP in the absence of a Shortest Path Tree (SPT) from the RP to 572 the source. The register packets received on the RP are decapsulated 573 and forwarded down the shared tree to the LHRs. As soon as an SPT is 574 built, multicast packets would flow natively over the SPT to the RP 575 or LHR and the register process would stop. The PIM register process 576 ensures packet delivery until an SPT is in place reaching the FHR. 577 If the packets were not unicast encapsulated to the RP they would be 578 dropped by the FHR until the SPT is setup. This functionality is 579 important for applications where the initial packet(s) must be 580 received for the application to work correctly. Another reason would 581 be for bursty sources. If the application sends out a multicast 582 packet every 4 minutes (or longer), the SPT is torn down (typically 583 after 3:30 minutes of inactivity) before the next packet is forwarded 584 down the tree. This will cause no multicast packet to ever be 585 forwarded. A well behaved application should be able to deal with 586 packet loss since IP is a best effort based packet delivery system. 587 But in reality this is not always the case. 589 With the procedures defined in this document the packet(s) received 590 by the FHR will be dropped until the LHR has learned about the source 591 and the SPT is built. That means for bursty sources or applications 592 sensitive for the delivery of the first packet this solution would 593 not be very applicable. This solution is mostly useful for 594 applications that don't have strong dependency on the initial 595 packet(s) and have a fairly constant data rate, like video 596 distribution for example. For applications with strong dependency on 597 the initial packet(s) using PIM Bidir [RFC5015] or SSM [RFC4607] is 598 recommended. The protocol operations are much simpler compared to 599 PIM SM, it will cause less churn in the network and both guarantee 600 best effort delivery for the initial packet(s). 602 4.5. Resiliency to Network Partitioning 604 In a PIM SM deployment where the network becomes partitioned, due to 605 link or node failure, it is possible that the RP becomes unreachable 606 to a certain part of the network. New sources that become active in 607 that partition will not be able to register to the RP and receivers 608 within that partition are not able to receive the traffic. Ideally 609 you would want to have a candidate RP in each partition, but you 610 never know in advance which routers will form a partitioned network. 611 In order to be fully resilient, each router in the network may end up 612 being a candidate RP. This would increase the operational complexity 613 of the network. 615 The solution described in this document does not suffer from that 616 problem. If a network becomes partitioned and new sources become 617 active, the receivers in that partitioned will receive the SG 618 Mappings and join the source tree. Each partition works 619 independently of the other partition(s) and will continue to have 620 access to sources within that partition. Once the network has 621 healed, the periodic flooding of SG Mappings ensures that they are 622 re-flooded into the other partition(s) and other receivers can join 623 to the newly learned sources. 625 5. Configurable Parameters 627 This document contains a number of configurable parameters. These 628 parameters are formally defined in Section 3.3 and Section 4.2, but 629 they are repeated here for ease of reference. These parameters all 630 have default values as noted below. 632 Max_PFM_Message_Rate: The maximum number of PFM messages a router is 633 allowed to originate per minute, see Section 3.3 for details. The 634 default value is 6. 636 Min_PFM_Message_Gap: The minimum amount of time between each PFM 637 message originated by a router in milliseconds, see Section 3.3 638 for details. The default is 1000. 640 Group_Source_Holdtime_Period: The announcement period for Group 641 Source Holdtime TLVs in seconds, see Section 4.2 for details. The 642 default value is 60. 644 Group_Source_Holdtime_Holdtime: The holdtime for Group Source 645 Holdtime TLVs in seconds, see Section 4.2 for details. The 646 default value is 210. 648 6. Security Considerations 650 When it comes to general PIM message security, see [RFC7761]. PFM 651 messages MUST only be accepted from a PIM neighbor, but as discussed 652 in [RFC7761], any router can become a PIM neighbor by sending a Hello 653 message. To control from where to accept PFM packets, one can limit 654 which interfaces PIM is enabled, and also one can configure 655 interfaces as administrative boundaries for PFM messages, see 656 Section 3.2. The implications of forged PFM messages depend on which 657 TLVs they contain. Documents defining new TLVs will need to discuss 658 the security considerations for the specific TLVs. In general 659 though, the PFM messages are flooded within the network, and by 660 forging a large number of PFM messages one might stress all the 661 routers in the network. 663 If an attacker can forge PFM messages, then such messages may contain 664 arbitrary GSH TLVs. An issue here is that an attacker might send 665 such TLVs for a huge amount of sources, potentially causing every 666 router in the network to store huge amounts of source state. Also, 667 if there is receiver interest for the groups specified in the GSH 668 TLVs, routers with directly connected receivers will build Shortest 669 Path Trees for the announced sources, even if the sources are not 670 actually active. Building such trees will consume additional 671 resources on routers that the trees pass through. 673 PIM-SM link-local messages can be authenticated using IPsec, see 674 [RFC7761] section 6.3 and [RFC5796]. Since PFM messages are link- 675 local messages sent hop by hop, a link-local PFM message can be 676 authenticated using IPsec such that a router can verify that a 677 message was sent by a trusted neighbor and has not been modified. 678 However, to verify that a received message contains correct 679 information announced by the originator specified in the message, one 680 will have to trust every router on the path from the originator and 681 that each router has authenticated the received message. 683 7. IANA Considerations 685 This document requires the assignment of a new PIM message type for 686 the PIM Flooding Mechanism (PFM) with the name "PIM Flooding 687 Mechanism". IANA is also requested to create a registry for PFM TLVs 688 called "PIM Flooding Mechanism Message Types". Assignments for the 689 registry are to be made according to the policy "IETF Review" as 690 defined in [RFC8126]. The initial content of the registry should be: 692 Type Name Reference 693 -------------------------------------------------- 694 0 Reserved [this document] 695 1 Source Group Holdtime [this document] 696 2-32767 Unassigned 698 8. Acknowledgments 700 The authors would like to thank Arjen Boers for contributing to the 701 initial idea, and David Black, Stewart Bryant, Yiqun Cai, 702 Papadimitriou Dimitri, Toerless Eckert, Dino Farinacci, Alvaro Retana 703 and Liang Xia for their very helpful comments on the draft. 705 9. References 707 9.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 715 "Bootstrap Router (BSR) Mechanism for Protocol Independent 716 Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 717 2008, . 719 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 720 Confidentiality in Protocol Independent Multicast Sparse 721 Mode (PIM-SM) Link-Local Messages", RFC 5796, 722 DOI 10.17487/RFC5796, March 2010, 723 . 725 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 726 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 727 Multicast - Sparse Mode (PIM-SM): Protocol Specification 728 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 729 2016, . 731 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 732 Writing an IANA Considerations Section in RFCs", BCP 26, 733 RFC 8126, DOI 10.17487/RFC8126, June 2017, 734 . 736 9.2. Informative References 738 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 739 Independent Multicast - Dense Mode (PIM-DM): Protocol 740 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 741 January 2005, . 743 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 744 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 745 . 747 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 748 "Bidirectional Protocol Independent Multicast (BIDIR- 749 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 750 . 752 Authors' Addresses 754 IJsbrand Wijnands 755 Cisco Systems, Inc. 756 De kleetlaan 6a 757 Diegem 1831 758 Belgium 760 Email: ice@cisco.com 762 Stig Venaas 763 Cisco Systems, Inc. 764 Tasman Drive 765 San Jose CA 95134 766 USA 768 Email: stig@cisco.com 769 Michael Brig 770 Aegis BMD Program Office 771 17211 Avenue D, Suite 160 772 Dahlgren VA 22448-5148 773 USA 775 Email: michael.brig@mda.mil 777 Anders Jonasson 778 Swedish Defence Material Administration (FMV) 779 Loennvaegen 4 780 Vaexjoe 35243 781 Sweden 783 Email: anders@jomac.se