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