idnits 2.17.1 draft-liu-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 (June 20, 2019) is 1771 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 404 -- Looks like a reference, but probably isn't: '2' on line 410 == Missing Reference: 'M' is mentioned on line 308, but not defined == Missing Reference: 'O' is mentioned on line 421, 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 Huawei Technologies 3 Intended status: Standards Track M. McBride 4 Expires: December 20, 2019 T. Eckert 5 Futurewei 6 June 20, 2019 8 PIM Assert Message Packing 9 draft-liu-pim-assert-packing-01 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 December 20, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 the 57 metric-preference and metric of the route towards the source or RP. 58 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 ................................................ 2 66 1.1. Requirements Language .................................. 3 67 1.2. Terminology ............................................ 3 68 2. Use Cases ................................................... 3 69 2.1. Enterprise network ..................................... 3 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 .................... 5 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 ................................ 11 87 8. Acknowledgments ............................................ 12 89 1. Introduction 91 In PIM-SM shared LAN networks, there is typically more than one 92 upstream router. When duplicate data packets appear on the LAN, from 93 different upstream routers, assert packets are sent from these 94 routers to elect a single forwarder according to [RFC7761]. The PIM 95 assert packets are sent periodically to keep the assert state. The 96 PIM assert packet carries information about a single multicast 97 source and group, along with the corresponding metric-preference and 98 metric of the route towards the source or RP. 100 This document defines a standard to send and receive multiple 101 multicast source and group information in a single PIM assert packet 102 in a shared LAN network. It can efficiently pack multiple PIM assert 103 packets into a single message and reduce the processing pressure of 104 the PIM routers. This can be particularly helpful when there is 105 traffic for a large number of multicast groups. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 1.2. Terminology 117 RPF: Reverse Path Forwarding 119 RP: Rendezvous Point 121 SPT: Shortest Path Tree 123 RPT: RP Tree 125 DR: Designated Router 127 BDR: Backup Designated Router 129 2. Use Cases 131 PIM Assert will happen in many services where multicast is used and 132 not limited to the examples described below. 134 2.1. Enterprise network 136 When an Enterprise network is connected through a layer-2 network, 137 the intra-enterprise runs layer-3 PIM multicast. The different sites 138 of the enterprise are equivalent to the PIM connection through the 139 shared LAN network. Depending upon the locations and amount of 140 groups there could be many asserts on the first hop routers. 142 2.2. Video surveillance 144 Video surveillance deployments have migrated from analog based 145 systems to IP-based systems oftentimes using multicast. In the 146 shared LAN network deployments, when there are many cameras 147 streaming to many groups there may be issues with many asserts on 148 first hop routers. 150 2.3. Financial Services 152 Financial services extensively rely on IP Multicast to deliver stock 153 market data and its derivatives, and current multicast solution PIM 154 is usually deployed. As the number of multicast flows grows, there 155 are many stock data with many groups may result in many PIM asserts 156 on a shared LAN network from publisher to the subscribers. 158 2.4. IPTV broadcast video 160 PIM DR and BDR deployments are often used in host-side network for 161 IPTV broadcast video services. Host-side access network failure 162 scenario may be benefitted by assert packing when many groups are 163 being used. According to [RFC7761] the DR will be elected to forward 164 multicast traffic in the shared access network. When the DR recovers 165 from a failure, the original DR starts to send traffic, and the 166 current DR is still forwarding traffic. In the situation multicast 167 traffic duplication maybe happen in the shared access network and 168 can trigger the assert progress. 170 2.5. Summary 172 In the above scenarios, the existence of PIM assert process depends 173 mainly on the network topology. As long as there is a layer 2 174 network between PIM neighbors, there may be multiple upstream 175 routers, which can cause duplicate multicast traffic to be forwarded 176 and assert process to occur. 178 Moreover as the multicast services become widely deployed, the 179 number of multicast entries increases, and a large number of assert 180 messages may be sent in a very short period when multicast data 181 packets trigger PIM assert process in the shared LAN networks. The 182 PIM routers need to process a large number of PIM assert small 183 packets in a very short time. As a result, the device load is very 184 large. The assert packet may not be processed in time or even is 185 discarded, thus extending the time of traffic duplication in the 186 network. 188 Additionally, future backhaul, or fronthaul, networks may want to 189 connect L3 across an L2 underlay supporting Time Sensitive Networks 190 (TSN). The infrastructure may run DetNet over TSN. These transit L2 191 LANs would have multiple upstreams and downstreams. This document is 192 taking a proactive approach to prevention of possible future assert 193 issues in these types of environments. 195 3. Solution 197 The change to the PIM assert includes two elements: the PIM assert 198 packing hello option and the PIM assert packing method. 200 There is no change required to the PIM assert state machine. 201 Basically a PIM router can now be the assert winner or loser for 202 multiple packed (S, G)'s in a single assert packet instead of one 203 (S, G) assert at a time. An assert winner is now responsible for 204 forwarding traffic from multiple (S, G)'s out of a particular 205 interface based upon the multiple (S, G)'s packed in a single 206 assert. 208 3.1. PIM Assert Packing Hello Option 210 The newly defined Hello Option is used by a router to negotiate the 211 assert packet packing capability. It can only be used when all PIM 212 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 273 of this field: 275 1: indicates simple packing type as described in section 2.2 277 2: indicates aggregating packing type as described in section 2.3 279 3-255: reserved for future 281 4.2. PIM Assert Simple Packing Format 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |PIM Ver| Type |SubType| Rsvd | Checksum | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Reserved | Number of Assert Records (M) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 . . 292 . Assert Record [1] . 293 . . 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 . . 298 . Assert Record [2] . 299 . . 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | . | 303 . . . 304 | . | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 . . 308 . Assert Record [M] . 309 . . 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 PIM Version, Reserved, Checksum 315 Same as [RFC7761] Section 4.9.6 317 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 372 Same as [RFC7761] Section 4.9.6, but the source address MUST NOT 373 be set to zero. 375 Number of Groups 377 The number of group addresses corresponding to the source address 378 field in the (S, G) assert record. 380 Group Address 382 Same as [RFC7761] Section 4.9.6, but there are multiple group 383 addresses in the (S, G) assert record 385 The (*, G) assert records are organized in the same RP address and 386 are divided into two levels of TLVs. The first level is the group 387 record of the same RP address, and the second level is the source 388 record of the same multicast group address, including (*, G) and RPT 389 (S, G), and the specific message format is: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | RP Address (Encoded-Unicast format) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |1| Metric Preference | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Metric | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Number of Group Records(O) | Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 . . 404 . Group Record [1] . 405 . . 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 . . 410 . Group Record [2] . 411 . . 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | . | 415 . . . 416 | . | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 . . 421 . Group Record [O] . 422 . . 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 465 The number of source addresses corresponding to the group address 466 field in the group record. 468 Source Address 470 Same as [RFC7761] Section 4.9.6, but there are multiple source 471 addresses in the group record. 473 5. IANA Considerations 475 This document requests IANA to assign a registry for PIM assert 476 packing Hello Option in the PIM-Hello Options and new PIM assert 477 packet type and subtype. The assignment is requested permanent for 478 IANA when this document is published as an RFC. The string TBD 479 should be replaced by the assigned values accordingly. 481 6. Security Considerations 483 For general PIM-SM protocol Security Considerations, see [RFC7761]. 485 TBD 487 7. References 489 7.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 495 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 496 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 497 Specification(Revised)", RFC 7761, March 2016 499 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 500 2119 Key Words", BCP 14, RFC 8174, May 2017 502 7.2. Informative References 504 TBD 506 8. Acknowledgments 508 The authors would like to thank the following for their valuable 509 contributions of this document: 511 TBD 512 Authors' Addresses 514 Yisong Liu 515 Huawei Technologies 516 Huawei Bld., No.156 Beiqing Rd. 517 Beijing 100095 518 China 520 Email: liuyisong@huawei.com 522 Mike McBride 523 Futurewei 524 2330 Central Expressway 525 Santa Clara, CA 95055 526 USA 528 Email: michael.mcbride@futurewei.com 530 Toerless Eckert 531 Futurewei 532 2330 Central Expy 533 Santa Clara 95050 534 USA 536 Email: tte+ietf@cs.fau.de