idnits 2.17.1 draft-ietf-pim-assert-packing-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 -- The document date (Feb 21, 2021) is 1153 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 418 -- Looks like a reference, but probably isn't: '2' on line 424 == Missing Reference: 'M' is mentioned on line 319, but not defined == Missing Reference: 'O' is mentioned on line 434, 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: August 21, 2021 T. Eckert 5 Futurewei 6 Z. Zhang 7 ZTE 8 Feb 21, 2021 10 PIM Assert Message Packing 11 draft-ietf-pim-assert-packing-01 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 21, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 In PIM-SM shared LAN networks, there is typically more than one 54 upstream router. When duplicate data packets appear on the LAN from 55 different routers, assert packets are sent from these routers to 56 elect a single forwarder. The PIM assert packets are sent 57 periodically to keep the assert state. The PIM assert packet carries 58 information about a single multicast source and group, along with 59 the metric-preference and metric of the route towards the source or 60 RP. This document defines a standard to send and receive multiple 61 multicast source and group information in a single PIM assert packet 62 in a shared network. This can be particularly helpful when there is 63 traffic for a large number of multicast groups. 65 Table of Contents 67 1. Introduction ................................................ 3 68 1.1. Requirements Language .................................. 3 69 1.2. Terminology ............................................ 3 70 2. Use Cases ................................................... 3 71 2.1. Enterprise network ..................................... 4 72 2.2. Video surveillance ..................................... 4 73 2.3. Financial Services ..................................... 4 74 2.4. IPTV broadcast Video ................................... 4 75 2.5. Summary ................................................ 4 76 3. Solution .................................................... 5 77 3.1. PIM Assert Packing Hello Option ........................ 5 78 3.2. PIM Assert Packing Simple Type ......................... 5 79 3.3. PIM Assert Packing Aggregation Type .................... 6 80 3.4. Assert Timer ........................................... 6 81 4. Packet Format ............................................... 6 82 4.1. PIM Assert Packing Hello Option ........................ 6 83 4.2. PIM Assert Simple Packing Format ....................... 7 84 4.3. PIM Assert Aggregation Packing Format .................. 8 85 5. IANA Considerations ........................................ 11 86 6. Security Considerations .................................... 11 87 7. References ................................................. 12 88 7.1. Normative References .................................. 12 89 7.2. Informative References ................................ 12 90 8. Acknowledgments ............................................ 12 91 Authors' Addresses ............................................ 13 93 1. Introduction 95 In PIM-SM shared LAN networks, there is typically more than one 96 upstream router. When duplicate data packets appear on the LAN, from 97 different upstream routers, assert packets are sent from these 98 routers to elect a single forwarder according to [RFC7761]. The PIM 99 assert packets are sent periodically to keep the assert state. The 100 PIM assert packet carries information about a single multicast 101 source and group, along with the corresponding metric-preference and 102 metric of the route towards the source or RP. 104 This document defines a standard to send and receive multiple 105 multicast source and group information in a single PIM assert packet 106 in a shared LAN network. It can efficiently pack multiple PIM assert 107 packets into a single message and reduce the processing pressure of 108 the PIM routers. This can be particularly helpful when there is 109 traffic for a large number of multicast groups. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 1.2. Terminology 121 RPF: Reverse Path Forwarding 123 RP: Rendezvous Point 125 SPT: Shortest Path Tree 127 RPT: RP Tree 129 DR: Designated Router 131 BDR: Backup Designated Router 133 2. Use Cases 135 PIM Assert will happen in many services where multicast is used and 136 not limited to the examples described below. 138 2.1. Enterprise network 140 When an Enterprise network is connected through a layer-2 network, 141 the intra-enterprise runs layer-3 PIM multicast. The different sites 142 of the enterprise are equivalent to the PIM connection through the 143 shared LAN network. Depending upon the locations and amount of 144 groups there could be many asserts on the first hop routers. 146 2.2. Video surveillance 148 Video surveillance deployments have migrated from analog based 149 systems to IP-based systems oftentimes using multicast. In the 150 shared LAN network deployments, when there are many cameras 151 streaming to many groups there may be issues with many asserts on 152 first hop routers. 154 2.3. Financial Services 156 Financial services extensively rely on IP Multicast to deliver stock 157 market data and its derivatives, and current multicast solution PIM 158 is usually deployed. As the number of multicast flows grows, there 159 are many stock data with many groups may result in many PIM asserts 160 on a shared LAN network from publisher to the subscribers. 162 2.4. IPTV broadcast Video 164 PIM DR and BDR deployments are often used in host-side network for 165 IPTV broadcast video services. Host-side access network failure 166 scenario may be benefitted by assert packing when many groups are 167 being used. According to [RFC7761] the DR will be elected to forward 168 multicast traffic in the shared access network. When the DR recovers 169 from a failure, the original DR starts to send traffic, and the 170 current DR is still forwarding traffic. In the situation multicast 171 traffic duplication maybe happen in the shared access network and 172 can trigger the assert progress. 174 2.5. Summary 176 In the above scenarios, the existence of PIM assert process depends 177 mainly on the network topology. As long as there is a layer 2 178 network between PIM neighbors, there may be multiple upstream 179 routers, which can cause duplicate multicast traffic to be forwarded 180 and assert process to occur. 182 Moreover as the multicast services become widely deployed, the 183 number of multicast entries increases, and a large number of assert 184 messages may be sent in a very short period when multicast data 185 packets trigger PIM assert process in the shared LAN networks. The 186 PIM routers need to process a large number of PIM assert small 187 packets in a very short time. As a result, the device load is very 188 large. The assert packet may not be processed in time or even is 189 discarded, thus extending the time of traffic duplication in the 190 network. 192 Additionally, future backhaul, or fronthaul, networks may want to 193 connect L3 across an L2 underlay supporting Time Sensitive Networks 194 (TSN). The infrastructure may run DetNet over TSN. These transit L2 195 LANs would have multiple upstreams and downstreams. This document is 196 taking a proactive approach to prevention of possible future assert 197 issues in these types of environments. 199 3. Solution 201 The change to the PIM assert includes two elements: the PIM assert 202 packing hello option and the PIM assert packing method. 204 There is no change required to the PIM assert state machine. 205 Basically a PIM router can now be the assert winner or loser for 206 multiple packed (S, G)'s in a single assert packet instead of one 207 (S, G) assert at a time. An assert winner is now responsible for 208 forwarding traffic from multiple (S, G)'s out of a particular 209 interface based upon the multiple (S, G)'s packed in a single 210 assert. 212 3.1. PIM Assert Packing Hello Option 214 The newly defined Hello Option is used by a router to negotiate the 215 assert packet packing capability. It can only be used when all PIM 216 routers, in the same shared LAN network, support this capability. 217 This document defines two packing methods. One method is a simple 218 merge of the original messages and the other is to extract the 219 common message fields for aggregation. 221 3.2. PIM Assert Packing Simple Type 223 In this type of packing, the original assert message body is used as 224 a record. The newly defined assert message can carry multiple assert 225 records and identify the number of records. 227 This packing method is simply extended from the original assert 228 packet, but, because the multicast service deployment often uses a 229 small number of sources and RPs, there may be a large number of 230 assert records with the same metric preference or route metric 231 field, which would waste the payload of the transmitted message. 233 3.3. PIM Assert Packing Aggregation Type 235 When the source or RP addresses, in the actual deployment of the 236 multicast service, are very few, this type of packing will combine 237 the records related to the source address or RP address in the 238 assert message. 240 * A (S, G) assert only can contain one SPT (S, G) entry, so it can 241 be aggregated according to the same source address, and then all SPT 242 (S, G) entries corresponding to the same source address are merged 243 into one assert record. 245 * A (*, G) assert may contain a (*, G) entry or a RPT (S, G) entry, 246 and both entry types actually depend on the route to the RP. So it 247 can be aggregated further according to the same RP address, and then 248 all (*, G) and RPT (S, G) entries corresponding to the same RP 249 address are merged into one assert record. 251 This method can optimize the payload of the transmitted message by 252 merging the same field content, but will add the complexity of the 253 packet encapsulation and parsing. 255 3.4. Assert Timer 257 This packing message takes no effect on the existed Assert Timer for 258 (*,G) and (S,G). When the winner sends the assert message due to the 259 local periodic timer expiration, the (*,G) and (S,G) which are 260 expired at the same time will be sent by packing message instead of 261 individual message. 263 4. Packet Format 265 This section describes the format of new PIM messages introduced by 266 this document. The messages follow the same transmission order as 267 the messages defined in [RFC7761]. 269 4.1. PIM Assert Packing Hello Option 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | OptionType = TBD | OptionLength = 1 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Packing_Type | 277 +-+-+-+-+-+-+-+-+ 278 - OptionType: TBD 280 - OptionLength: 1 282 - Packing_Type: The specific packing mode is determined by the value 284 of this field: 286 1: indicates simple packing type as described in section 2.2 288 2: indicates aggregating packing type as described in section 2.3 290 3-255: reserved for future 292 4.2. PIM Assert Simple Packing Format 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |PIM Ver| Type |SubType| FB | Checksum | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Count | Reserved | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 . . 303 . Assert Record [1] . 304 . . 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 . . 309 . Assert Record [2] . 310 . . 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | . | 314 . . . 315 | . | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 . . 319 . Assert Record [M] . 321 . . 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 PIM Version, Reserved, Checksum 327 Same as [RFC7761] Section 4.9.6 329 Type 331 The new Assert Type and SubType values TBD 333 Count 335 The number of packed assert records. A record consists of a 336 single assert message body. 338 The format of each record is the same as the PIM assert message body 339 of section 4.9.6 in [RFC7761]. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Group Address (Encoded-Group format) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Source Address (Encoded-Unicast format) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |R| Metric Preference | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Metric | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 4.3. PIM Assert Aggregation Packing Format 355 This method also extends PIM assert packets to carry multiple 356 records. The specific assert packet format is the same as section 357 4.2, but the records are divided into two types. 359 The (S, G) assert records are organized by the same source address, 360 and the specific message format is: 362 0 1 2 3 363 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Source Address (Encoded-Unicast format) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |0| Metric Preference | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Metric | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Number of Groups (N) | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Group Address 1 (Encoded-Group format) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Group Address 2 (Encoded-Group format) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | . | 379 | . | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Group Address N (Encoded-Group format) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Source Address, Metric Preference, Metric and Reserved 386 Same as [RFC7761] Section 4.9.6, but the source address MUST NOT 387 be set to zero. 389 Number of Groups 391 The number of group addresses corresponding to the source address 392 field in the (S, G) assert record. 394 Group Address 396 Same as [RFC7761] Section 4.9.6, but there are multiple group 397 addresses in the (S, G) assert record 399 The (*, G) assert records are organized in the same RP address and 400 are divided into two levels of TLVs. The first level is the group 401 record of the same RP address, and the second level is the source 402 record of the same multicast group address, including (*, G) and RPT 403 (S, G), and the specific message format is: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | RP Address (Encoded-Unicast format) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |1| Metric Preference | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Metric | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Number of Group Records(O) | Reserved | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 . . 418 . Group Record [1] . 419 . . 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 . . 424 . Group Record [2] . 425 . . 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | . | 429 . . . 430 | . | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 . . 434 . Group Record [O] . 435 . . 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 RP Address 440 The address of RP corresponding to all of the contained group 441 records. The format for this address is given in the encoded 442 unicast address in [RFC7761] Section 4.9.1 444 Metric Preference, Metric and Reserved 446 Same as [RFC7761] Section 4.9.6 448 Number of Group Records 450 The number of packed group records. A record consists of a group 451 address and a source address list. 453 The format of each group record is: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Group Address (Encoded-Group format) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Number of Sources (P) | Reserved | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Source Address 1 (Encoded-Unicast format) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Source Address 2 (Encoded-Unicast format) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | . | 467 | . | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Source Address P (Encoded-Unicast format) | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Group Address and Reserved 474 Same as [RFC7761] Section 4.9.6 476 Number of Sources 478 The number of source addresses corresponding to the group 479 address field in the group record. 481 Source Address 483 Same as [RFC7761] Section 4.9.6, but there are multiple source 484 addresses in the group record. 486 5. IANA Considerations 488 This document requests IANA to assign a registry for PIM assert 489 packing Hello Option in the PIM-Hello Options and new PIM assert 490 packet type and subtype. The assignment is requested permanent for 491 IANA when this document is published as an RFC. The string TBD 492 should be replaced by the assigned values accordingly. 494 6. Security Considerations 496 For general PIM-SM protocol Security Considerations, see [RFC7761]. 498 TBD 500 7. References 502 7.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 508 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 509 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 510 Specification(Revised)", RFC 7761, March 2016 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, May 2017 515 7.2. Informative References 517 TBD 519 8. Acknowledgments 521 The authors would like to thank the following for their valuable 522 contributions of this document: 524 TBD 526 Authors' Addresses 528 Yisong Liu 529 China Mobile 531 Email: liuyisong@chinamobile.com 533 Mike McBride 534 Futurewei 536 Email: michael.mcbride@futurewei.com 538 Toerless Eckert 539 Futurewei 541 Email: tte+ietf@cs.fau.de 543 Zheng(Sandy) Zhang 544 ZTE Corporation 546 Email: zhang.zheng@zte.com.cn