idnits 2.17.1 draft-ietf-pim-source-discovery-bsr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2013) is 3805 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 (~~), 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: May 22, 2014 M. Brig 6 Aegis BMD Program Office 7 November 18, 2013 9 PIM flooding mechanism and source discovery 10 draft-ietf-pim-source-discovery-bsr-00 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 May 22, 2014. 44 Copyright Notice 46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . 8 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 administrative boundaries 129 being configured. The forwarding rules are identical to BSR, except 130 that there is no BSR election. The protocol includes an originator 131 address which is used for RPF checking to restrict the flooding, just 132 like BSR. Just like BSR it is also sent hop by hop. Note that there 133 is no built in election mechanism as in BSR, so there can be multiple 134 originators. It is still possible to add such an election mechanism 135 if this protocol is used in scenarios where this is desirable. We 136 include a type field, which can allow boundaries to be defined, and 137 election to take place, independently per type. We call this 138 protocol the PIM Flooding Protocol (PFP). 140 2.1. PFP message format 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |PIM Ver| Type |N| Reserved | Checksum | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Originator Address (Encoded-Unicast format) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | PFP Type | Reserved |U| 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type 1 | Length 1 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Value 1 | 154 | . | 155 | . | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | . | 158 | . | 159 | Type n | Length n | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Value n | 162 | . | 163 | . | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 PIM Version: Reserved, Checksum Described in [RFC4601]. 168 Type: PIM Message Type. Value (pending IANA) for a PFP message. 170 [N]o-Forward bit: When set, this bit means that the PFP message is 171 not to be forwarded. 173 Originator Address: The address of the router that originated the 174 message. This can be any address assigned to this router, but 175 MUST be routable in the domain to allow successful forwarding 176 (just like BSR address). The format for this address is given in 177 the Encoded-Unicast address in [RFC4601]. 179 PFP Type: There may be different sub protocols or different uses 180 for this generic protocol. The PFP Type specifies which sub 181 protocol it is used for. 183 [U]nknown-No-Forwarding bit: Some sub protocols may require each 184 router to do some processing of the contents and not simply 185 forwarding. This bit controls how a router should treat an 186 unknown PFP Type. When set, a router MUST NOT forward the message 187 when the PFP Type is unknown. When clear, a router MUST forward 188 the message when possible. If the PFP Type is known, then the 189 specification of that type will specify how to handle the message, 190 including whether it should be forwarded. 192 Type 1..n: A message contains one or more TLVs, in this case n 193 TLVs. The Type specifies what kind of information is in the 194 Value. Note that the Type space is shared between all PFP. Not 195 all types make sense for all protocol types though. 197 Length 1..n: The length of the the value field. 199 Value 1..n: The value associated with the type and of the specified 200 length. 202 3. Distributing Source to Group Mappings 204 We want to provide information about active multicast sources 205 throughout a PIM domain by making use of the generic flooding 206 mechanism defined in the previous section. We request PFP Type 0 to 207 be assigned for this purpose. We call a message with PFP Type 0 an 208 SG Message. We also define a PFP TLV which we request to be type 0. 209 How this TLV is used with PFP Type 0 is defined in the next section. 210 Other PFP Types may specify the use of this TLV for other purposes. 211 For PFP Type 0 the U-bit MUST NOT be set. This means that routers 212 not supporting PFP Type 0 would still forward the message. 214 3.1. Group Source Holdtime TLV 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 | Type = 0 | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Group Address (Encoded-Group format) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Src Count | Src Holdtime | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Src Address 1 (Encoded-Unicast format) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Src Address 2 (Encoded-Unicast format) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | . | 229 | . | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Src Address m (Encoded-Unicast format) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Type: This TLV has type 0. 236 Length: The length of the value. 238 Group Address: The group we are announcing sources for. The format 239 for this address is given in the Encoded-Group format in 240 [RFC4601]. 242 Src Count: How many unicast encoded sources address encodings 243 follow. 245 Src Holdtime: The Holdtime (in seconds) for the corresponding 246 source(s). 248 Src Address: The source address for the corresponding group. The 249 format for these addresses is given in the Encoded-Unicast address 250 in [RFC4601]. 252 4. Originating SG messages 254 An SG Mesage, that is a PFP message of Type 0, may contain one or 255 more Group Source Holdtime TLVs. This is used to flood information 256 about active multicast sources. Each FHR that is directly connected 257 to an active multicast source originates SG BSR messages. How a 258 multicast router discovers the source of the multicast packet and 259 when it considers itself the FHR follows the same procedures as the 260 registering process described in [RFC4601]. After it is decided that 261 a register needs to be sent, the SG is not registered via the PIM SM 262 register procedures, but the SG mapping is included in an SG message. 264 Note, only the SG mapping is distributed in the message, not the 265 entire packet as would have been done with a PIM register. The 266 router originating the SG messages includes one of its own addresses 267 in the originator field. Note that this address must be routeable 268 due to RPF checking. The SG messages are periodically sent for as 269 long as the multicast source is active, similar to how PIM registers 270 are periodically sent. The default announcement period is 60 271 seconds, which means that as long as the source is active, it is 272 included in an SG message originated every 60 seconds. The holdtime 273 for the source is by default 210 seconds. Other values can be 274 configured, but the holdtime must be larger than the announcement 275 period. 277 5. Processing SG messages 279 A router that receives an SG message should parse the message and 280 store the SG mappings with a holdtimer started with the advertised 281 holdtime for that group. If there are directly connected receivers 282 for that group this router should send PIM (S,G) joins for all the SG 283 mappings advertised in the message. The SG mappings are kept alive 284 for as long as the holdtimer for the source is running. Once the 285 holdtimer expires a PIM (S,G) prune must be sent to remove itself 286 from the tree. 288 6. The first packets and bursty sources 290 The PIM register procedure is designed to deliver Multicast packets 291 to the RP in the absence of a native SPT tree from the RP to the 292 source. The register packets received on the RP are decapsulated and 293 forwarded down the shared tree to the LHRs. As soon as an SPT tree 294 is built, multicast packets would flow natively over the SPT to the 295 RP or LHR and the register process would stop. The PIM register 296 process bridges the gap between how long it takes to build the SPT 297 tree to the FHR. If the packets would not be unicast encapsulated to 298 the RP they would be dropped by the FHR until the SPT is setup. This 299 functionality is important for applications where the initial 300 packet(s) must be received for the application to work correctly. 301 Another reason would be for bursty sources. If the application sends 302 out a multicast packet every 4 minutes (or longer), the SPT is torn 303 down (typically after 3:30 minutes of inactivity) before the next 304 packet is forwarded down the tree. This will cause no multicast 305 packet to ever be forwarded. A well behaved application should 306 really be able to deal with packet loss since IP is a best effort 307 based packet delivery system. But in reality this is not always the 308 case. 310 With the procedures proposed in this draft the packet(s) received by 311 the FHR will be dropped until the LHR has learned about the source 312 and the SPT tree is built. That means for bursty sources or 313 applications sensitive for the delivery of the first packet this 314 proposal would not be very applicable. This proposal is mostly 315 useful for applications that don't have strong dependency on the 316 initial packet(s) and have a fairly constant data rate, like video 317 distribution for example. For applications with strong dependency on 318 the initial packet(s) we recommend using PIM Bidir [RFC5015] or SSM 319 [RFC4607]. The protocol operations are much simpler compared to PIM 320 SM, it will cause less churn in the network and both guarantee best 321 effort delivery for the initial packet(s). 323 Another solution to address the problems described above is 324 documented in [I-D.ietf-magma-msnip]. This proposal allows for a 325 host to tell the FHR its willingness to act as Source for a certain 326 Group before sending the data packets. LHRs have time to join the 327 SPT tree before the host starts sending which would avoid packet 328 loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be 329 advertised directly in SG messages, allowing a very nice integration 330 of both proposals. The life time of the SPT is not driven by the 331 liveliness of Multicast data packets (which is the case with PIM SM), 332 but by the announcements driven via [I-D.ietf-magma-msnip]. This 333 will also prevent packet loss due to bursty sources. 335 7. Resiliency to network partitioning 337 In a PIM SM deployment where the network becomes partitioned, due to 338 link or node failure, it is possible that the RP becomes unreachable 339 to a certain part of the network. New sources that become active in 340 that partition will not be able to register to the RP and receivers 341 within that partition are not able to receive the traffic. Ideally 342 you would want to have a candidate RP in each partition, but you 343 never know in advance which routers will form a partitioned network. 344 In order to be fully resilient, each router in the network may end up 345 being a candidate RP. This would increase the operational complexity 346 of the network. 348 The solution described in this document does not suffer from that 349 problem. If a network becomes partitioned and new sources become 350 active, the receivers in that partitioned will receive the SG 351 Mappings and join the source tree. Each partition works 352 independently of the other partition(s) and will continue to have 353 access to sources within that partition. As soon as the network 354 heals, the SG Mappings are re-flooded into the other partition(s) and 355 other receives can join to the newly learned sources. 357 8. Security Considerations 358 The security considerations are no different from what is documented 359 in [RFC5059]. 361 9. IANA considerations 363 This document requires the assignment of a new PIM Protocol type for 364 the PIM Flooding Protocol (PFP). IANA also needs to create a 365 registry for PFP Types with type 0 allocated to "Source-Group 366 Message". IANA also needs to create a registry for PFP TLVs, with 367 type 0 allocated to the "Source Group Holdtime" TLV. The allocation 368 procedures are yet to be determined. 370 10. Acknowledgments 372 The authors would like to thank Arjen Boers for contributing to the 373 initial idea and Yiqun Cai for his comments on the draft. 375 11. References 377 11.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 383 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 384 Protocol Specification (Revised)", RFC 4601, August 2006. 386 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 387 "Bootstrap Router (BSR) Mechanism for Protocol Independent 388 Multicast (PIM)", RFC 5059, January 2008. 390 11.2. Informative References 392 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 393 IP", RFC 4607, August 2006. 395 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 396 "Bidirectional Protocol Independent Multicast (BIDIR- 397 PIM)", RFC 5015, October 2007. 399 [I-D.ietf-magma-msnip] 400 Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and 401 S. Venaas, "Multicast Source Notification of Interest 402 Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in 403 progress), March 2011. 405 Authors' Addresses 407 IJsbrand Wijnands 408 Cisco Systems, Inc. 409 De kleetlaan 6a 410 Diegem 1831 411 Belgium 413 Email: ice@cisco.com 415 Stig Venaas 416 Cisco Systems, Inc. 417 Tasman Drive 418 San Jose CA 95134 419 USA 421 Email: stig@cisco.com 423 Michael Brig 424 Aegis BMD Program Office 425 17211 Avenue D, Suite 160 426 Dahlgren VA 22448-5148 427 USA 429 Email: michael.brig@mda.mil