idnits 2.17.1 draft-ietf-pim-assert-packing-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 (Mar 17, 2020) is 1494 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 405 -- Looks like a reference, but probably isn't: '2' on line 412 == Missing Reference: 'M' is mentioned on line 309, but not defined == Missing Reference: 'O' is mentioned on line 422, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group Yisong Liu 2 Internet Draft China Mobile 3 Intended status: Standards Track M. McBride 4 Expires: September 17, 2020 T. Eckert 5 Futurewei 6 Mar 17, 2020 8 PIM Assert Message Packing 9 draft-ietf-pim-assert-packing-00 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 17, 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 In PIM-SM shared LAN networks, there is typically more than one 52 upstream router. When duplicate data packets appear on the LAN from 53 different routers, assert packets are sent from these routers to 54 elect a single forwarder. The PIM assert packets are sent 55 periodically to keep the assert state. The PIM assert packet carries 56 information about a single multicast source and group, along with 57 the metric-preference and metric of the route towards the source or 58 RP. This document defines a standard to send and receive multiple 59 multicast source and group information in a single PIM assert packet 60 in a shared network. This can be particularly helpful when there is 61 traffic for a large number of multicast groups. 63 Table of Contents 65 1. Introduction ................................................ 3 66 1.1. Requirements Language .................................. 3 67 1.2. Terminology ............................................ 3 68 2. Use Cases ................................................... 3 69 2.1. Enterprise network ..................................... 4 70 2.2. Video surveillance ..................................... 4 71 2.3. Financial Services ..................................... 4 72 2.4. IPTV broadcast Video ................................... 4 73 2.5. Summary ................................................ 4 74 3. Solution .................................................... 5 75 3.1. PIM Assert Packing Hello Option ........................ 5 76 3.2. PIM Assert Packing Simple Type ......................... 5 77 3.3. PIM Assert Packing Aggregation Type .................... 6 78 4. Packet Format ............................................... 6 79 4.1. PIM Assert Packing Hello Option ........................ 6 80 4.2. PIM Assert Simple Packing Format ....................... 7 81 4.3. PIM Assert Aggregation Packing Format .................. 8 82 5. IANA Considerations ........................................ 11 83 6. Security Considerations .................................... 11 84 7. References ................................................. 11 85 7.1. Normative References .................................. 11 86 7.2. Informative References ................................ 12 87 8. Acknowledgments ............................................ 12 88 Authors' Addresses ............................................ 13 90 1. Introduction 92 In PIM-SM shared LAN networks, there is typically more than one 93 upstream router. When duplicate data packets appear on the LAN, from 94 different upstream routers, assert packets are sent from these 95 routers to elect a single forwarder according to [RFC7761]. The PIM 96 assert packets are sent periodically to keep the assert state. The 97 PIM assert packet carries information about a single multicast 98 source and group, along with the corresponding metric-preference and 99 metric of the route towards the source or RP. 101 This document defines a standard to send and receive multiple 102 multicast source and group information in a single PIM assert packet 103 in a shared LAN network. It can efficiently pack multiple PIM assert 104 packets into a single message and reduce the processing pressure of 105 the PIM routers. This can be particularly helpful when there is 106 traffic for a large number of multicast groups. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 1.2. Terminology 118 RPF: Reverse Path Forwarding 120 RP: Rendezvous Point 122 SPT: Shortest Path Tree 124 RPT: RP Tree 126 DR: Designated Router 128 BDR: Backup Designated Router 130 2. Use Cases 132 PIM Assert will happen in many services where multicast is used and 133 not limited to the examples described below. 135 2.1. Enterprise network 137 When an Enterprise network is connected through a layer-2 network, 138 the intra-enterprise runs layer-3 PIM multicast. The different sites 139 of the enterprise are equivalent to the PIM connection through the 140 shared LAN network. Depending upon the locations and amount of 141 groups there could be many asserts on the first hop routers. 143 2.2. Video surveillance 145 Video surveillance deployments have migrated from analog based 146 systems to IP-based systems oftentimes using multicast. In the 147 shared LAN network deployments, when there are many cameras 148 streaming to many groups there may be issues with many asserts on 149 first hop routers. 151 2.3. Financial Services 153 Financial services extensively rely on IP Multicast to deliver stock 154 market data and its derivatives, and current multicast solution PIM 155 is usually deployed. As the number of multicast flows grows, there 156 are many stock data with many groups may result in many PIM asserts 157 on a shared LAN network from publisher to the subscribers. 159 2.4. IPTV broadcast Video 161 PIM DR and BDR deployments are often used in host-side network for 162 IPTV broadcast video services. Host-side access network failure 163 scenario may be benefitted by assert packing when many groups are 164 being used. According to [RFC7761] the DR will be elected to forward 165 multicast traffic in the shared access network. When the DR recovers 166 from a failure, the original DR starts to send traffic, and the 167 current DR is still forwarding traffic. In the situation multicast 168 traffic duplication maybe happen in the shared access network and 169 can trigger the assert progress. 171 2.5. Summary 173 In the above scenarios, the existence of PIM assert process depends 174 mainly on the network topology. As long as there is a layer 2 175 network between PIM neighbors, there may be multiple upstream 176 routers, which can cause duplicate multicast traffic to be forwarded 177 and assert process to occur. 179 Moreover as the multicast services become widely deployed, the 180 number of multicast entries increases, and a large number of assert 181 messages may be sent in a very short period when multicast data 182 packets trigger PIM assert process in the shared LAN networks. The 183 PIM routers need to process a large number of PIM assert small 184 packets in a very short time. As a result, the device load is very 185 large. The assert packet may not be processed in time or even is 186 discarded, thus extending the time of traffic duplication in the 187 network. 189 Additionally, future backhaul, or fronthaul, networks may want to 190 connect L3 across an L2 underlay supporting Time Sensitive Networks 191 (TSN). The infrastructure may run DetNet over TSN. These transit L2 192 LANs would have multiple upstreams and downstreams. This document is 193 taking a proactive approach to prevention of possible future assert 194 issues in these types of environments. 196 3. Solution 198 The change to the PIM assert includes two elements: the PIM assert 199 packing hello option and the PIM assert packing method. 201 There is no change required to the PIM assert state machine. 202 Basically a PIM router can now be the assert winner or loser for 203 multiple packed (S, G)'s in a single assert packet instead of one 204 (S, G) assert at a time. An assert winner is now responsible for 205 forwarding traffic from multiple (S, G)'s out of a particular 206 interface based upon the multiple (S, G)'s packed in a single 207 assert. 209 3.1. PIM Assert Packing Hello Option 211 The newly defined Hello Option is used by a router to negotiate the 212 assert packet packing capability. It can only be used when all PIM 213 routers, in the same shared LAN network, support this capability. 214 This document defines two packing methods. One method is a simple 215 merge of the original messages and the other is to extract the 216 common message fields for aggregation. 218 3.2. PIM Assert Packing Simple Type 220 In this type of packing, the original assert message body is used as 221 a record. The newly defined assert message can carry multiple assert 222 records and identify the number of records. 224 This packing method is simply extended from the original assert 225 packet, but, because the multicast service deployment often uses a 226 small number of sources and RPs, there may be a large number of 227 assert records with the same metric preference or route metric 228 field, which would waste the payload of the transmitted message. 230 3.3. PIM Assert Packing Aggregation Type 232 When the source or RP addresses, in the actual deployment of the 233 multicast service, are very few, this type of packing will combine 234 the records related to the source address or RP address in the 235 assert message. 237 * A (S, G) assert only can contain one SPT (S, G) entry, so it can 238 be aggregated according to the same source address, and then all SPT 239 (S, G) entries corresponding to the same source address are merged 240 into one assert record. 242 * A (*, G) assert may contain a (*, G) entry or a RPT (S, G) entry, 243 and both entry types actually depend on the route to the RP. So it 244 can be aggregated further according to the same RP address, and then 245 all (*, G) and RPT (S, G) entries corresponding to the same RP 246 address are merged into one assert record. 248 This method can optimize the payload of the transmitted message by 249 merging the same field content, but will add the complexity of the 250 packet encapsulation and parsing. 252 4. Packet Format 254 This section describes the format of new PIM messages introduced by 255 this document. The messages follow the same transmission order as 256 the messages defined in [RFC7761]. 258 4.1. PIM Assert Packing Hello Option 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 | OptionType = TBD | OptionLength = 1 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Packing_Type | 266 +-+-+-+-+-+-+-+-+ 268 - OptionType: TBD 270 - OptionLength: 1 272 - Packing_Type: The specific packing mode is determined by the value 274 of this field: 276 1: indicates simple packing type as described in section 2.2 278 2: indicates aggregating packing type as described in section 2.3 280 3-255: reserved for future 282 4.2. PIM Assert Simple Packing Format 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |PIM Ver| Type |SubType| Rsvd | Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Reserved | Number of Assert Records (M) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 . . 293 . Assert Record [1] . 294 . . 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 . . 299 . Assert Record [2] . 300 . . 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | . | 304 . . . 305 | . | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 . . 309 . Assert Record [M] . 310 . . 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 PIM Version, Reserved, Checksum 316 Same as [RFC7761] Section 4.9.6 318 Type 319 The new Assert Type and SubType values TBD 321 Number of Assert Records 323 The number of packed assert records. A record consists of a 324 single assert message body. 326 The format of each record is the same as the PIM assert message body 327 of section 4.9.6 in [RFC7761]. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Group Address (Encoded-Group format) | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Source Address (Encoded-Unicast format) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |R| Metric Preference | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Metric | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 4.3. PIM Assert Aggregation Packing Format 343 This method also extends PIM assert packets to carry multiple 344 records. The specific assert packet format is the same as section 345 4.2, but the records are divided into two types. 347 The (S, G) assert records are organized by the same source address, 348 and the specific message format is: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Source Address (Encoded-Unicast format) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |0| Metric Preference | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Metric | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Number of Groups (N) | Reserved | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Group Address 1 (Encoded-Group format) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Group Address 2 (Encoded-Group format) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | . | 366 | . | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Group Address N (Encoded-Group format) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Source Address, Metric Preference, Metric and Reserved 373 Same as [RFC7761] Section 4.9.6, but the source address MUST NOT 374 be set to zero. 376 Number of Groups 378 The number of group addresses corresponding to the source address 379 field in the (S, G) assert record. 381 Group Address 383 Same as [RFC7761] Section 4.9.6, but there are multiple group 384 addresses in the (S, G) assert record 386 The (*, G) assert records are organized in the same RP address and 387 are divided into two levels of TLVs. The first level is the group 388 record of the same RP address, and the second level is the source 389 record of the same multicast group address, including (*, G) and RPT 390 (S, G), and the specific message format is: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | RP Address (Encoded-Unicast format) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |1| Metric Preference | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Metric | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Number of Group Records(O) | Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | | 404 . . 405 . Group Record [1] . 407 . . 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 . . 412 . Group Record [2] . 413 . . 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | . | 417 . . . 418 | . | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 . . 422 . Group Record [O] . 423 . . 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 RP Address 428 The address of RP corresponding to all of the contained group 429 records. The format for this address is given in the encoded 430 unicast address in [RFC7761] Section 4.9.1 432 Metric Preference, Metric and Reserved 434 Same as [RFC7761] Section 4.9.6 436 Number of Group Records 438 The number of packed group records. A record consists of a group 439 address and a source address list. 441 The format of each group record is: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Group Address (Encoded-Group format) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Number of Sources (P) | Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Source Address 1 (Encoded-Unicast format) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Source Address 2 (Encoded-Unicast format) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | . | 455 | . | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Source Address P (Encoded-Unicast format) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Group Address and Reserved 462 Same as [RFC7761] Section 4.9.6 464 Number of Sources 466 The number of source addresses corresponding to the group 467 address field in the group record. 469 Source Address 471 Same as [RFC7761] Section 4.9.6, but there are multiple source 472 addresses in the group record. 474 5. IANA Considerations 476 This document requests IANA to assign a registry for PIM assert 477 packing Hello Option in the PIM-Hello Options and new PIM assert 478 packet type and subtype. The assignment is requested permanent for 479 IANA when this document is published as an RFC. The string TBD 480 should be replaced by the assigned values accordingly. 482 6. Security Considerations 484 For general PIM-SM protocol Security Considerations, see [RFC7761]. 486 TBD 488 7. References 490 7.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 496 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 497 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 498 Specification(Revised)", RFC 7761, March 2016 500 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 501 2119 Key Words", BCP 14, RFC 8174, May 2017 503 7.2. Informative References 505 TBD 507 8. Acknowledgments 509 The authors would like to thank the following for their valuable 510 contributions of this document: 512 TBD 514 Authors' Addresses 516 Yisong Liu 517 China Mobile 519 Email: liuyisong@chinamobile.com 521 Mike McBride 522 Futurewei 524 Email: michael.mcbride@futurewei.com 526 Toerless Eckert 527 Futurewei 529 Email: tte+ietf@cs.fau.de