idnits 2.17.00 (12 Aug 2021) /tmp/idnits36558/draft-ietf-pim-assert-packing-05.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 == Line 62 has weird spacing: '...here is traf...' == Line 111 has weird spacing: '...sure of the ...' == Line 112 has weird spacing: '...here is traf...' -- The document date (Nov 22, 2021) is 173 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 538 -- Looks like a reference, but probably isn't: '2' on line 544 == Missing Reference: 'M' is mentioned on line 508, but not defined == Missing Reference: 'O' is mentioned on line 554, but not defined == Unused Reference: 'RFC8736' is defined on line 643, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 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: May 22, 2022 T. Eckert 5 Futurewei 6 Z. Zhang 7 ZTE 8 Nov 22, 2021 10 PIM Assert Message Packing 11 draft-ietf-pim-assert-packing-05 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 May 22, 2022. 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 information 61 for multiple multicast sources and groups in a single PIM assert 62 message. This can be particularly helpful when there is traffic 63 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. MVPN MDT..................................................4 76 2.6. Summary...................................................5 77 3. Solution.......................................................5 78 3.1. PIM Assert Packing Hello Option...........................5 79 3.2. PIM Assert Packing Simple Type............................5 80 3.3. PIM Assert Packing Aggregation Type.......................6 81 3.4. PIM Assert Timer..........................................6 82 3.5. PIM Assert Format Selection...............................7 83 4. Packet Format..................................................7 84 4.1. PIM Assert Packing Hello Option...........................7 85 4.2. PIM Assert Simple Packing Format..........................8 86 4.3. PIM (S,G) Assert Aggregation Packing Format...............9 87 4.4. PIM (*,G) Assert Aggregation Packing Format..............11 88 5. IANA Considerations...........................................14 89 6. Security Considerations.......................................14 90 7. References....................................................15 91 7.1. Normative References.....................................15 92 7.2. Informative References...................................15 94 8. Acknowledgments...............................................15 95 Authors' Addresses...............................................16 97 1. Introduction 99 In PIM-SM shared LAN networks, there is typically more than one 100 upstream router. When duplicate data packets appear on the LAN, from 101 different upstream routers, assert packets are sent from these 102 routers to elect a single forwarder according to [RFC7761]. The PIM 103 assert packets are sent periodically to keep the assert state. The 104 PIM assert packet carries information about a single multicast 105 source and group, along with the corresponding metric-preference and 106 metric of the route towards the source or RP. 108 This document defines a standard to send and receive information for 109 multiple multicast sources and groups in a single PIM assert 110 message. It can efficiently pack multiple PIM assert messages into a 111 single message and reduce the processing pressure of the PIM 112 routers. This can be particularly helpful when there is traffic 113 for a large number of multicast groups. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 1.2. Terminology 125 RPF: Reverse Path Forwarding 127 RP: Rendezvous Point 129 SPT: Shortest Path Tree 131 RPT: RP Tree 133 DR: Designated Router 135 BDR: Backup Designated Router 137 2. Use Cases 139 PIM Assert will happen in many services where multicast is used and 140 not limited to the examples described below. 142 2.1. Enterprise network 144 When an Enterprise network is connected through a layer-2 network, 145 the intra-enterprise runs layer-3 PIM multicast. The different sites 146 of the enterprise are equivalent to the PIM connection through the 147 shared LAN network. Depending upon the locations and amount of 148 groups there could be many asserts on the first hop routers. 150 2.2. Video surveillance 152 Video surveillance deployments have migrated from analog based 153 systems to IP-based systems oftentimes using multicast. In the 154 shared LAN network deployments, when there are many cameras 155 streaming to many groups there may be issues with many asserts on 156 first hop routers. 158 2.3. Financial Services 160 Financial services extensively rely on IP Multicast to deliver stock 161 market data and its derivatives, and current multicast solution PIM 162 is usually deployed. As the number of multicast flows grows, there 163 are many stock data with many groups may result in many PIM asserts 164 on a shared LAN network from publisher to the subscribers. 166 2.4. IPTV broadcast Video 168 PIM DR and BDR deployments are often used in host-side network for 169 IPTV broadcast video services. Host-side access network failure 170 scenario may be benefitted by assert packing when many groups are 171 being used. According to [RFC7761] the DR will be elected to forward 172 multicast traffic in the shared access network. When the DR recovers 173 from a failure, the original DR starts to send traffic, and the 174 current DR is still forwarding traffic. In the situation multicast 175 traffic duplication maybe happen in the shared access network and 176 can trigger the assert progress. 178 2.5. MVPN MDT 180 As described in [RFC6037], MDT (Multicast Distribution Tree) is used 181 as tunnels for MVPN. The configuration of multicast-enabled VRF (VPN 182 routing and forwarding) or interface that is in a VRF changing may 183 cause many assert packets to be sent in a same time. 185 2.6. Summary 187 In the above scenarios, the existence of PIM assert state depends 188 mainly on the network topology. As long as there is a layer 2 189 network between PIM neighbors, there may be multiple upstream 190 routers, which can cause duplicate multicast traffic to be forwarded 191 and assert process to occur. 193 Moreover as the multicast services become widely deployed, the 194 number of multicast entries increases, and a large number of assert 195 messages may be sent in a very short period when multicast data 196 packets trigger PIM assert processing in the shared LAN networks. 197 The PIM routers need to process a large number of PIM assert small 198 packets in a very short time. As a result, the device load is very 199 large. The assert packet may not be processed in time or even is 200 discarded, thus extending the time of traffic duplication in the 201 network. 203 Additionally, future backhaul, or fronthaul, networks may want to 204 connect L3 across an L2 underlay supporting Time Sensitive Networks 205 (TSN). The infrastructure may run DetNet over TSN. These transit L2 206 LANs would have multiple upstreams and downstreams. This document is 207 taking a proactive approach to prevention of possible future assert 208 issues in these types of environments. 210 3. Solution 212 The change to the PIM assert includes two elements: the PIM assert 213 packing hello option and the PIM assert packing method. 215 There is no change required to the PIM assert state machine. 216 Basically a PIM router can now be the assert winner or loser for 217 multiple packed (S, G)'s in a single assert message instead of one 218 (S, G) assert at a time. 220 3.1. PIM Assert Packing Hello Option 222 The newly defined Hello Option is used by a router to negotiate the 223 assert message packing capability. Assert packing can only be used 224 when all PIM routers, in the same shared LAN network, support this 225 capability. This document defines two packing methods. One method is 226 a simple merge of the original messages and the other is to extract 227 the common message fields for aggregation. 229 3.2. PIM Assert Packing Simple Type 231 In this type of packing, as described in [RFC7761], the assert 232 message body is used as a record. The newly defined assert message 233 can carry multiple assert records and identify the number of 234 records. 236 This packing method is simply extended from the original assert 237 packet, but, because the multicast service deployment often uses a 238 small number of sources and RPs, there may be a large number of 239 assert records with the same metric preference or route metric 240 field, which would waste the payload of the transmitted message. 242 3.3. PIM Assert Packing Aggregation Type 244 When the source or RP addresses, in the actual deployment of the 245 multicast service, are very few, this type of packing will combine 246 the records related to the source address or RP address in the 247 assert message. 249 * A (S, G) assert only can contain one SPT (S, G) entry, so it can 250 be aggregated according to the same source address, and then all SPT 251 (S, G) entries corresponding to the same source address are merged 252 into one assert record. 254 * A (*, G) assert may contain a (*, G) entry or a RPT (S, G) entry, 255 and both entry types actually depend on the route to the RP. So it 256 can be aggregated further according to the same RP address, and then 257 all (*, G) and RPT (S, G) entries corresponding to the same RP 258 address are merged into one assert record. 260 This method can optimize the payload of the transmitted message by 261 merging the same field content, but will add the complexity of the 262 packet encapsulation and parsing. 264 3.4. PIM Assert Timer 266 As described in section 4.6 in RFC7761, the Assert Timer function of 267 each (S,G) and (*,G) is not changed. After the Assert Message 268 Packing function defined in this document is enabled, when the first 269 AT of a (S,G) or (*,G) is expired, in order to carry much more 270 assert information in this message, some of other (S,G) or (*,G) may 271 be included in the same message, even though their ATs have not been 272 expired. After the assert message packing, the ATs of all the (S,G) 273 or (*,G), that are packed in the same message, are all reset. That 274 is after the packed assert messages is sent, the ATs of the packed 275 (S,G) or (*,G) will be set with the same value. 277 3.5. PIM Assert Format Selection 279 An implementation MUST NOT send assert messages using a packing 280 type, unless all routers on the LAN have indicated support for the 281 type. If both packing types are supported, then it is left to the 282 implementation whether to use assert packing and which packing type 283 to use. It is RECOMMENDED to use the supported method that is most 284 efficient. The Aggregation Packing Format is likely to be the most 285 efficient if the assert message is to include multiple records 286 having the same source address or RP address. 288 The regular RFC7761 assert format is still allowed to be used. For 289 example the assert only needs to be sent for a single (S, G). 291 4. Packet Format 293 This section describes the format of new PIM messages introduced by 294 this document. 296 4.1. PIM Assert Packing Hello Option 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | OptionType = TBD | OptionLength = 1 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Packing_Type | 304 +-+-+-+-+-+-+-+-+ 306 - OptionType: TBD 308 - OptionLength: 1 310 - Packing_Type: The specific packing mode is determined by the value 312 of this field: 314 When the first bit from the right is set to 1: indicates simple 315 packing type as described in section 2.2 317 When the second bit from the right is set to 1: indicates 318 aggregating packing type as described in section 2.3 320 3-8 bits: reserved for future 322 The node may support multiple packing types. The node MUST set the 323 bits indicating which types they support. They MUST set both bits if 324 they support both type 1 and type 2. The format used MUST be a 325 format supported by all routers on the LAN, see section 3.5 for 326 details. 328 Once the packing format type is selected, this type of coding is 329 used for Assert message packing. 331 If not all nodes support a same packing format, then Assert 332 message format defined in [RFC7761] is used. 334 4.2. PIM Assert Simple Packing Format 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |PIM Ver| Type |SubType| FB | Checksum | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Count | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 . . 345 . Assert Record [1] . 346 . . 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 . . 351 . Assert Record [2] . 352 . . 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | . | 356 . . . 357 | . | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 . . 361 . Assert Record [M] . 362 . . 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 PIM Version, Reserved, Checksum 367 Same as [RFC7761] Section 4.9.6 369 Type 371 The new Assert Type values TBD1. 373 Type.SubType 375 The new Assert Type.SubType value TBD2. 377 FB 379 Flag Bits field. This field is not used for now, it may be used 380 in the future. 382 Count 384 The number of packed assert records. A record consists of a 385 single assert message body. 387 The format of each record is the same as the PIM assert message body 388 of section 4.9.6 in [RFC7761]. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Group Address (Encoded-Group format) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Source Address (Encoded-Unicast format) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |R| Metric Preference | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Metric | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 4.3. PIM (S,G) Assert Aggregation Packing Format 404 This method also extends PIM assert messages to carry multiple 405 records. But the records are divided for (S, G) and (*, G). 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |PIM Ver| Type |SubType| FB | Checksum | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Count | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 . . 416 . Assert Record [1] . 417 . . 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 . . 422 . Assert Record [2] . 423 . . 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | . | 427 . . . 428 | . | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 . . 432 . Assert Record [M] . 433 . . 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Most fields of the specific assert message format is the same as 438 section 4.2, except for the subType fields and records. When 439 aggregated (S, G) records is carried in the message, the subType 440 field is set to TBD3. 442 The (S, G) assert records are organized by the same source address, 443 and the specific message format is: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Source Address (Encoded-Unicast format) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |0| Metric Preference | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Metric | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Number of Groups (N) | Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Group Address 1 (Encoded-Group format) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Group Address 2 (Encoded-Group format) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | . | 461 | . | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Group Address N (Encoded-Group format) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Source Address, Metric Preference, Metric and Reserved 468 Same as [RFC7761] Section 4.9.6, but the source address MUST NOT 469 be set to zero. 471 Number of Groups 473 The number of group addresses corresponding to the source address 474 field in the (S, G) assert record. 476 Group Address 478 Same as [RFC7761] Section 4.9.6, but there are multiple group 479 addresses in the (S, G) assert record. 481 4.4. PIM (*,G) Assert Aggregation Packing Format 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |PIM Ver| Type |SubType| FB | Checksum | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Count | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 . . 492 . Assert Record [1] . 493 . . 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 . . 498 . Assert Record [2] . 499 . . 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | . | 503 . . . 504 | . | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | 507 . . 508 . Assert Record [M] . 509 . . 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Most fields of the specific assert message format is the same as 514 section 4.2, except for the subType fields and records. When 515 aggregated (*, G) records is carried in the message, the subType 516 field is set to TBD4. 518 The (*, G) assert records are organized in the same RP address and 519 are divided into two levels of TLVs. The first level is the group 520 record of the same RP address, and the second level is the source 521 record of the same multicast group address, including (*, G) and RPT 522 (S, G), and the specific message format is: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | RP Address (Encoded-Unicast format) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |1| Metric Preference | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Metric | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Number of Group Records(O) | Reserved | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 . . 538 . Group Record [1] . 539 . . 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 . . 544 . Group Record [2] . 545 . . 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | . | 549 . . . 550 | . | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 . . 554 . Group Record [O] . 555 . . 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 RP Address 560 The address of RP corresponding to all of the contained group 561 records. The format for this address is given in the encoded 562 unicast address in [RFC7761] Section 4.9.1 564 Metric Preference, Metric and Reserved 566 Same as [RFC7761] Section 4.9.6 568 Number of Group Records 570 The number of packed group records. A record consists of a group 571 address and a source address list. 573 The format of each group record is: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Group Address (Encoded-Group format) | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Number of Sources (P) | Reserved | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Source Address 1 (Encoded-Unicast format) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Source Address 2 (Encoded-Unicast format) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | . | 587 | . | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Source Address P (Encoded-Unicast format) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Group Address and Reserved 594 Same as [RFC7761] Section 4.9.6 596 Number of Sources 598 The number of source addresses corresponding to the group 599 address field in the group record. 601 Source Address 603 Same as [RFC7761] Section 4.9.6, but there are multiple source 604 addresses in the group record. 606 5. IANA Considerations 608 This document requests IANA to assign a registry for PIM assert 609 packing Hello Option in the PIM-Hello Options and new PIM assert 610 packet type and subtype. The assignment is requested permanent for 611 IANA when this document is published as an RFC. The string TBD 612 should be replaced by the assigned values accordingly. 614 6. Security Considerations 616 As described in section 6.1 in RFC7761, the forged assert message 617 may cause the legitimate designated forwarder to stop forwarding 618 traffic to the LAN. And the packed function defined in this 619 document, may make this situation worse, because it will affect 620 multiple flows with a single packed assert. That is in case one 621 forged packed assert message is accept, all the (S,G) or (*,G) 622 carried in this message may be stopped forwarding from one or more 623 legitimate designated forwarders. The general security function, 624 such as authentication function defined in RFC7761, or the necessary 625 PIM filtering method, will do good help to avoid the forged assert 626 message. 628 7. References 630 7.1. Normative References 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, March 1997. 635 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 636 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 637 Independent Multicast - Sparse Mode (PIM-SM): Protocol 638 Specification(Revised)", RFC 7761, March 2016 640 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 641 2119 Key Words", BCP 14, RFC 8174, May 2017 643 [RFC8736] Venaas, S., Retana, A., "PIM Message Type Space Extension 644 and Reserved Bits", RFC 8736, February 2020. 646 7.2. Informative References 648 [RFC6037] Rosen, E., Cai, Y., Wijnands, I., "Cisco Systems' Solution 649 for Multicast in BGP/MPLS IP VPNs", RFC6037, October 2010 651 8. Acknowledgments 653 The authors would like to thank Stig Venaas for the valuable 654 contributions of this document. 656 Authors' Addresses 658 Yisong Liu 659 China Mobile 660 China 662 Email: liuyisong@chinamobile.com 664 Mike McBride 665 Futurewei 666 USA 668 Email: michael.mcbride@futurewei.com 670 Toerless Eckert 671 Futurewei 672 USA 674 Email: tte+ietf@cs.fau.de 676 Zheng(Sandy) Zhang 677 ZTE Corporation 678 China 680 Email: zhang.zheng@zte.com.cn