idnits 2.17.1 draft-ietf-pim-source-discovery-bsr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A router that receives an SG message should parse the message and store the SG mappings with a holdtimer started with the advertised holdtime for that group. If there are directly connected receivers for that group this router should send PIM (S,G) joins for all the SG mappings advertised in the message. The SG mappings are kept alive for as long as the holdtimer for the source is running. Once the holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to remove itself from the tree. Note that a holdtime of 0 has a special meaning. It is to be treated as if the source just expired, causing a prune to be sent and state to be removed. Source information MUST not be removed due to it being omitted in a message. For instance, if there are a large number of sources for a group, there may be multiple SG messages for the same group, each message containing a different list of sources. -- The document date (July 1, 2015) is 3212 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: January 2, 2016 M. Brig 6 Aegis BMD Program Office 7 A. Jonasson 8 Swedish Defence Material Administration (FMV) 9 July 1, 2015 11 PIM flooding mechanism and source discovery 12 draft-ietf-pim-source-discovery-bsr-02 14 Abstract 16 PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to 17 forward multicast packets to Last Hop Routers (LHR). After the first 18 packet is received by the LHR, the source of the multicast stream is 19 learned and the Shortest Path Tree (SPT) can be joined. This draft 20 proposes a solution to support PIM Sparse Mode (SM) without the need 21 for PIM registers, RPs or shared trees. Multicast source information 22 is flooded throughout the multicast domain using a new generic PIM 23 flooding mechanism. This mechanism is defined in this document, and 24 is modeled after the PIM Bootstrap Router protocol. By removing the 25 need for RPs and shared trees, the PIM-SM procedures are simplified, 26 improving router operations, management and making the protocol more 27 robust. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 2, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Conventions used in this document . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. A generic PIM flooding mechanism . . . . . . . . . . . . . . 3 67 2.1. PFP message format . . . . . . . . . . . . . . . . . . . 4 68 2.2. Processing PFP messages . . . . . . . . . . . . . . . . . 5 69 2.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 5 70 2.2.2. Processing messages with known PFP type . . . . . . . 5 71 2.2.3. Processing messages with unknown PFP type . . . . . . 6 72 3. Distributing Source to Group Mappings . . . . . . . . . . . . 6 73 3.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 6 74 3.2. Originating SG messages . . . . . . . . . . . . . . . . . 7 75 3.3. Processing SG messages . . . . . . . . . . . . . . . . . 7 76 3.4. The first packets and bursty sources . . . . . . . . . . 8 77 3.5. Resiliency to network partitioning . . . . . . . . . . . 9 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 7.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to 89 forward multicast packets to Last Hop Routers (LHR). After the first 90 packet is received by the LHR, the source of the multicast stream is 91 learned and the Shortest Path Tree (SPT) can be joined. This draft 92 proposes a solution to support PIM Sparse Mode (SM) without the need 93 for PIM registers, RPs or shared trees. Multicast source information 94 is flooded throughout the multicast domain using a new generic PIM 95 flooding mechanism. This mechanism is defined in this document, and 96 is modeled after the Bootstrap Router protocol [RFC5059]. By 97 removing the need for RPs and shared trees, the PIM-SM procedures are 98 simplified, improving router operations, management and making the 99 protocol more robust. 101 1.1. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 1.2. Terminology 109 RP: Rendezvous Point. 111 BSR: Bootstrap Router. 113 RPF: Reverse Path Forwarding. 115 SPT: Shortest Path Tree. 117 FHR: First Hop Router, directly connected to the source. 119 LHR: Last Hop Router, directly connected to the receiver. 121 SG Mapping: Multicast source to group mapping. 123 SG Message: A PIM message containing SG Mappings. 125 2. A generic PIM flooding mechanism 127 The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used 128 protocol for distributing dynamic Group to RP mappings in PIM. It is 129 responsible for flooding information about such mappings throughout a 130 PIM domain, so that all routers in the domain can have the same 131 information. BSR as defined, is only able to distribute Group to RP 132 mappings. We are defining a more generic mechanism that can flood 133 any kind of information throughout a PIM domain. It is not 134 necessarily a domain though, it depends on the administrative 135 boundaries being configured. The forwarding rules are identical to 136 BSR, except that there is no BSR election and that one can control 137 whether routers should forward messages of unsupported types. For 138 some types of information it is quite useful that it can be 139 distributed without all routers having to support the particular 140 type, while there may also be types where it is necessary for every 141 single router to support it. The protocol includes an originator 142 address which is used for RPF checking to restrict the flooding, just 143 like BSR. Just like BSR it is also sent hop by hop. Note that there 144 is no built in election mechanism as in BSR, so there can be multiple 145 originators. It is still possible to add such an election mechanism 146 on a type by type bases if this protocol is used in scenarios where 147 this is desirable. We include a type field, which can allow 148 boundaries to be defined, and election to take place, independently 149 per type. We call this protocol the PIM Flooding Protocol (PFP). 151 2.1. PFP message format 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |PIM Ver| Type |N| Reserved | Checksum | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Originator Address (Encoded-Unicast format) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | PFP Type | Reserved |U| 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type 1 | Length 1 | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Value 1 | 165 | . | 166 | . | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | . | 169 | . | 170 | Type n | Length n | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Value n | 173 | . | 174 | . | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 PIM Version: Reserved, Checksum Described in [RFC4601]. 179 Type: PIM Message Type. Value (pending IANA) for a PFP message. 181 [N]o-Forward bit: When set, this bit means that the PFP message is 182 not to be forwarded. 184 Originator Address: The address of the router that originated the 185 message. This can be any address assigned to this router, but 186 MUST be routable in the domain to allow successful forwarding 187 (just like BSR address). The format for this address is given in 188 the Encoded-Unicast address in [RFC4601]. 190 PFP Type: There may be different sub protocols or different uses 191 for this generic protocol. The PFP Type specifies which sub 192 protocol it is used for. 194 [U]nknown-No-Forwarding bit: Some sub protocols may require that 195 each router do some processing of the contents and not simply 196 forwarding. This bit controls how a router should treat an 197 unknown PFP Type. When set, a router MUST NOT forward the message 198 when the PFP Type is unknown. When clear, a router MUST forward 199 the message when possible. If the PFP Type is known, then the 200 specification of that type will specify how to handle the message, 201 including whether it should be forwarded. 203 Type 1..n: A message contains one or more TLVs, in this case n 204 TLVs. The Type specifies what kind of information is in the 205 Value. Note that the Type space is shared between all PFP types. 206 Not all types make sense for all PFP types though. 208 Length 1..n: The length of the the value field. 210 Value 1..n: The value associated with the type and of the specified 211 length. 213 2.2. Processing PFP messages 215 A router that receives an PFP message must perform the initial checks 216 specified here. If it passes, the contents is processed according to 217 the PFP type if known. If the type is unknown it may still be 218 forwarded. 220 2.2.1. Initial checks 222 The initial checks performed are largely similar to what is done for 223 BSR messages. The message MUST be from a directly connected neighbor 224 for which we have active Hello state. It MUST have been sent to the 225 ALL-PIM-ROUTERS group, and unless No-Forward is set, it MUST have 226 been sent by the RPF neighbor towards the router that originated the 227 message; or, if it is a No-Forward BSM, we must have restarted within 228 60 seconds. 230 2.2.2. Processing messages with known PFP type 232 If the PFP type is known, as in supported by the implementation, the 233 processing and potential forwarding is done according to the 234 specification for that PFP type. If the PFP type specification does 235 not specify any particular forwarding rules, the message is forwarded 236 out of all interfaces with PIM neighbors (including the interface it 237 is received on). 239 2.2.3. Processing messages with unknown PFP type 241 If the PFP type is unknown, the message MUST be dropped if the 242 Unknown-No-Forwarding bit is set. If the bit is not set, the message 243 is forwarded out of all interfaces with PIM neighbors (including the 244 interface it is received on). 246 3. Distributing Source to Group Mappings 248 We want to provide information about active multicast sources 249 throughout a PIM domain by making use of the generic flooding 250 mechanism defined in the previous section. We request PFP Type 0 to 251 be assigned for this purpose. We call a message with PFP Type 0 an 252 SG Message. We also define a PFP TLV which we request to be type 0. 253 How this TLV is used with PFP Type 0 is defined in the next section. 254 Other PFP Types may specify the use of this TLV for other purposes. 255 For PFP Type 0 the U-bit MUST NOT be set. This means that routers 256 not supporting PFP Type 0 would still forward the message. 258 3.1. Group Source Holdtime TLV 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type = 0 | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Group Address (Encoded-Group format) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Src Count | Src Holdtime | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Src Address 1 (Encoded-Unicast format) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Src Address 2 (Encoded-Unicast format) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | . | 274 | . | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Src Address m (Encoded-Unicast format) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: This TLV has type 0. 281 Length: The length of the value. 283 Group Address: The group we are announcing sources for. The format 284 for this address is given in the Encoded-Group format in 285 [RFC4601]. 287 Src Count: How many unicast encoded sources address encodings 288 follow. 290 Src Holdtime: The Holdtime (in seconds) for the corresponding 291 source(s). 293 Src Address: The source address for the corresponding group. The 294 format for these addresses is given in the Encoded-Unicast address 295 in [RFC4601]. 297 3.2. Originating SG messages 299 An SG Mesage, that is a PFP message of Type 0, may contain one or 300 more Group Source Holdtime TLVs. This is used to flood information 301 about active multicast sources. Each FHR that is directly connected 302 to an active multicast source originates SG BSR messages. How a 303 multicast router discovers the source of the multicast packet and 304 when it considers itself the FHR follows the same procedures as the 305 registering process described in [RFC4601]. After it is decided that 306 a register needs to be sent, the SG is not registered via the PIM SM 307 register procedures, but the SG mapping is included in an SG message. 308 Note, only the SG mapping is distributed in the message, not the 309 entire packet as would have been done with a PIM register. The 310 router originating the SG messages includes one of its own addresses 311 in the originator field. Note that this address must be routeable 312 due to RPF checking. The SG messages are periodically sent for as 313 long as the multicast source is active, similar to how PIM registers 314 are periodically sent. The default announcement period is 60 315 seconds, which means that as long as the source is active, it is 316 included in an SG message originated every 60 seconds. The holdtime 317 for the source is by default 210 seconds. Other values can be 318 configured, but the holdtime must be larger than the announcement 319 period. It is RECOMMENDED to be 3.5 times the announcement period. 320 Note that as a special case a source MAY be announced with a holdtime 321 of 0 to indicate that the source is no longer active. 323 3.3. Processing SG messages 325 A router that receives an SG message should parse the message and 326 store the SG mappings with a holdtimer started with the advertised 327 holdtime for that group. If there are directly connected receivers 328 for that group this router should send PIM (S,G) joins for all the SG 329 mappings advertised in the message. The SG mappings are kept alive 330 for as long as the holdtimer for the source is running. Once the 331 holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to 332 remove itself from the tree. Note that a holdtime of 0 has a special 333 meaning. It is to be treated as if the source just expired, causing 334 a prune to be sent and state to be removed. Source information MUST 335 not be removed due to it being omitted in a message. For instance, 336 if there are a large number of sources for a group, there may be 337 multiple SG messages for the same group, each message containing a 338 different list of sources. 340 3.4. The first packets and bursty sources 342 The PIM register procedure is designed to deliver Multicast packets 343 to the RP in the absence of a native SPT tree from the RP to the 344 source. The register packets received on the RP are decapsulated and 345 forwarded down the shared tree to the LHRs. As soon as an SPT tree 346 is built, multicast packets would flow natively over the SPT to the 347 RP or LHR and the register process would stop. The PIM register 348 process ensures packet delivery until an SPT tree is in place 349 reaching the FHR. If the packets were not unicast encapsulated to 350 the RP they would be dropped by the FHR until the SPT is setup. This 351 functionality is important for applications where the initial 352 packet(s) must be received for the application to work correctly. 353 Another reason would be for bursty sources. If the application sends 354 out a multicast packet every 4 minutes (or longer), the SPT is torn 355 down (typically after 3:30 minutes of inactivity) before the next 356 packet is forwarded down the tree. This will cause no multicast 357 packet to ever be forwarded. A well behaved application should 358 really be able to deal with packet loss since IP is a best effort 359 based packet delivery system. But in reality this is not always the 360 case. 362 With the procedures proposed in this draft the packet(s) received by 363 the FHR will be dropped until the LHR has learned about the source 364 and the SPT tree is built. That means for bursty sources or 365 applications sensitive for the delivery of the first packet this 366 proposal would not be very applicable. This proposal is mostly 367 useful for applications that don't have strong dependency on the 368 initial packet(s) and have a fairly constant data rate, like video 369 distribution for example. For applications with strong dependency on 370 the initial packet(s) we recommend using PIM Bidir [RFC5015] or SSM 371 [RFC4607]. The protocol operations are much simpler compared to PIM 372 SM, it will cause less churn in the network and both guarantee best 373 effort delivery for the initial packet(s). 375 Another solution to address the problems described above is 376 documented in [I-D.ietf-magma-msnip]. This proposal allows for a 377 host to tell the FHR its willingness to act as Source for a certain 378 Group before sending the data packets. LHRs have time to join the 379 SPT tree before the host starts sending which would avoid packet 380 loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be 381 advertised directly in SG messages, allowing a very nice integration 382 of both proposals. The life time of the SPT is not driven by the 383 liveliness of Multicast data packets (which is the case with PIM SM), 384 but by the announcements driven via [I-D.ietf-magma-msnip]. This 385 will also prevent packet loss due to bursty sources. 387 3.5. Resiliency to network partitioning 389 In a PIM SM deployment where the network becomes partitioned, due to 390 link or node failure, it is possible that the RP becomes unreachable 391 to a certain part of the network. New sources that become active in 392 that partition will not be able to register to the RP and receivers 393 within that partition are not able to receive the traffic. Ideally 394 you would want to have a candidate RP in each partition, but you 395 never know in advance which routers will form a partitioned network. 396 In order to be fully resilient, each router in the network may end up 397 being a candidate RP. This would increase the operational complexity 398 of the network. 400 The solution described in this document does not suffer from that 401 problem. If a network becomes partitioned and new sources become 402 active, the receivers in that partitioned will receive the SG 403 Mappings and join the source tree. Each partition works 404 independently of the other partition(s) and will continue to have 405 access to sources within that partition. As soon as the network 406 heals, the SG Mappings are re-flooded into the other partition(s) and 407 other receivers can join to the newly learned sources. 409 4. Security Considerations 411 The security considerations are mainly similar to what is documented 412 in [RFC5059]. It may be a concern that rogue devices can inject 413 packets that are flooded throughout a domain. PFP packets SHOULD 414 only be accepted from a PIM neighbor. Deployments may use mechanisms 415 for authenticating PIM neighbors. 417 5. IANA considerations 419 This document requires the assignment of a new PIM Protocol type for 420 the PIM Flooding Protocol (PFP). IANA is also requested to create a 421 registry for PFP Types with type 0 allocated to "Source-Group 422 Message". IANA is also requested to create a registry for PFP TLVs, 423 with type 0 allocated to the "Source Group Holdtime" TLV. The 424 allocation procedures are yet to be determined. 426 6. Acknowledgments 428 The authors would like to thank Arjen Boers for contributing to the 429 initial idea and Yiqun Cai for his comments on the draft. 431 7. References 433 7.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 439 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 440 Protocol Specification (Revised)", RFC 4601, August 2006. 442 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 443 "Bootstrap Router (BSR) Mechanism for Protocol Independent 444 Multicast (PIM)", RFC 5059, January 2008. 446 7.2. Informative References 448 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 449 IP", RFC 4607, August 2006. 451 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 452 "Bidirectional Protocol Independent Multicast (BIDIR- 453 PIM)", RFC 5015, October 2007. 455 [I-D.ietf-magma-msnip] 456 Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and 457 S. Venaas, "Multicast Source Notification of Interest 458 Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in 459 progress), March 2011. 461 Authors' Addresses 463 IJsbrand Wijnands 464 Cisco Systems, Inc. 465 De kleetlaan 6a 466 Diegem 1831 467 Belgium 469 Email: ice@cisco.com 470 Stig Venaas 471 Cisco Systems, Inc. 472 Tasman Drive 473 San Jose CA 95134 474 USA 476 Email: stig@cisco.com 478 Michael Brig 479 Aegis BMD Program Office 480 17211 Avenue D, Suite 160 481 Dahlgren VA 22448-5148 482 USA 484 Email: michael.brig@mda.mil 486 Anders Jonasson 487 Swedish Defence Material Administration (FMV) 488 Loennvaegen 4 489 Vaexjoe 35243 490 Sweden 492 Email: anders@jomac.se