idnits 2.17.1 draft-liu-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2019) is 1878 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 357 -- Looks like a reference, but probably isn't: '2' on line 363 == Missing Reference: 'M' is mentioned on line 288, but not defined == Missing Reference: 'O' is mentioned on line 373, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 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 M. McBride 3 Intended status: Standards Track T. Eckert 4 Expires: September 6, 2019 Huawei Technologies 5 March 6, 2019 7 PIM Assert Message Packing 8 draft-liu-pim-assert-packing-00 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 6, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 49 In PIM-SM shared networks, there is typically more than one upstream 50 router. When duplicate data packets appear on the LAN from different 51 routers, assert packets are sent from these routers to elect a single 52 forwarder. The PIM assert packets are sent periodically to keep the 53 assert state. The PIM assert packet carries information about a 54 single multicast source and group, along with the metric-preference 55 and metric of the route towards the source or RP. This document 56 defines a standard to send and receive multiple multicast source and 57 group information in a single PIM assert packet in a shared network. 58 This can be particularly helpful when there is traffic for a large 59 number of multicast groups. 61 Table of Contents 63 1. Introduction ................................................ 2 64 1.1. Requirements Language .................................. 3 65 1.2. Terminology ............................................ 3 66 2. Use Cases ................................................... 3 67 2.1. Enterprise network ..................................... 3 68 2.2. Video surveillance ..................................... 3 69 2.3. Financial Services ..................................... 4 70 2.4. IPTV broadcast video ................................... 4 71 3. Solution .................................................... 4 72 3.1. PIM Assert Packing Hello Option ........................ 5 73 3.2. PIM Assert Packing Simple Type ......................... 5 74 3.3. PIM Assert Packing Aggregation Type .................... 5 75 4. Packet Format ............................................... 5 76 4.1. PIM Assert Packing Hello Option ........................ 6 77 4.2. PIM Assert Simple Packing Format ....................... 6 78 4.3. PIM Assert Aggregation Packing Format .................. 7 79 5. IANA Considerations ......................................... 9 80 6. Security Considerations ..................................... 9 81 7. References .................................................. 9 82 7.1. Normative References ................................... 9 83 7.2. Informative References ................................ 10 84 8. Acknowledgments ............................................ 10 86 1. Introduction 88 In PIM-SM shared networks, there is typically more than one upstream 89 router. When duplicate data packets appear on the LAN, from 90 different upstream routers, assert packets are sent from these 91 routers to elect a single forwarder according to [RFC7761]. The PIM 92 assert packets are sent periodically to keep the assert state. The 93 PIM assert packet carries information about a single multicast 94 source and group, along with the corresponding metric-preference and 95 metric of the route towards the source or RP. 97 This document defines a standard to send and receive multiple 98 multicast source and group information in a single PIM assert packet 99 in a shared network. It can efficiently pack multiple PIM assert 100 packets into a single message and reduce the processing pressure of 101 the PIM routers. This can be particularly helpful when there is 102 traffic for a large number of multicast groups. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 1.2. Terminology 114 RPF: Reverse Path Forwarding 116 RP: Rendezvous Point 118 SPT: Shortest Path Tree 120 RPT: RP Tree 122 2. Use Cases 124 PIM Asserts will happen in many services where multicast is used and 125 not limited to the examples described below: 127 2.1. Enterprise network 129 When an Enterprise network is connected through a layer-2 network, 130 the intra-enterprise runs layer-3 PIM multicast. The different sites 131 of the enterprise are equivalent to the PIM connection through the 132 shared network. Depending upon the locations and amount of groups 133 there could be many asserts on the first hop routers. 135 2.2. Video surveillance 137 Video surveillance deployments have migrated from analog based 138 systems to IP-based systems oftentimes using multicast. In certain 139 deployments, when there are many cameras streaming to many groups, 140 there may be issues with many asserts on first hop routers. 142 2.3. Financial Services 144 Financial services extensively rely on IP Multicast to deliver stock 145 market data and its derivatives, and current multicast solution PIM 146 is usually deployed. As the number of multicast flows grows, there 147 are many stock data with many groups may result in many PIM asserts 148 on a shared network from publisher to the subscribers. 150 2.4. IPTV broadcast video 152 PIM DR and BDR deployments are often used in host-side network for 153 IPTV broadcast video services. Host-side access network failure 154 scenario may be benefitted by assert packing when many groups are 155 being used. According to [RFC7761] the DR will be elected to forward 156 multicast traffic in the shared access network. When the DR recovers 157 from a failure, the original DR starts to send traffic, and the 158 current DR is still forwarding traffic. In the situation multicast 159 traffic duplication maybe happen in the shared access network and 160 can trigger the assert progress. 162 In the above scenarios, as the multicast service becomes widely 163 deployed, the number of multicast entries increases, and a large 164 number of assert messages may be sent in a very short period when 165 multicast data packets trigger PIM assert process in the shared 166 networks. The PIM routers need to process a large number of PIM 167 assert small packets in a very short time. As a result, the device 168 load is very large. The assert packet may not be processed in time 169 or even is discarded, thus extending the time of traffic duplication 170 in the network. 172 Additionally, future backhaul, or fronthaul, networks may want to 173 connect L3 across an L2 underlay supporting Time Sensitive Networks 174 (TSN). The infrastructure may run DetNet over TSN. These transit L2 175 LANs would have multiple upstreams and downstreams. This draft is 176 taking a proactive approach to prevention of possible future assert 177 issues in these types of environments. 179 3. Solution 181 The change to the PIM assert includes two elements: the PIM assert 182 packing hello option and the PIM assert packing method. 184 There is no change required to the PIM assert state machine. 185 Basically a PIM router can now be the assert winner/loser for 186 multiple packed (S, G)'s in a single assert packet instead of one 187 (S, G) assert at a time. An assert winner is now responsible for 188 forwarding traffic from multiple (S, G)'s out of a particular 189 interface based upon the multiple (S, G)'s packed in a single 190 assert. 192 3.1. PIM Assert Packing Hello Option 194 The newly defined Hello Option is used by a router to negotiate the 195 assert packet packing capability. It can only be used when all PIM 196 routers, in the same shared network, support this capability. 198 This document defines two packing methods. One method is a simple 199 merge of the original messages and the other is to extract the 200 common message fields for aggregation. 202 3.2. PIM Assert Packing Simple Type 204 In this type of packing, the original assert message body is used as 205 a record. The newly defined assert message can carry multiple assert 206 records and identify the number of records. 208 This packing method is simply extended from the original assert 209 packet, but, because the multicast service deployment often uses a 210 small number of sources and RPs, there may be a large number of 211 assert records with the same metric preference or route metric 212 field, which wastes the payload of the transmitted message 214 3.3. PIM Assert Packing Aggregation Type 216 When the source or RP addresses, in the actual deployment of the 217 multicast service, are very few, this type of packing will combine 218 the records related to the source address or RP address in the 219 assert message. 221 * (S, G) assert is aggregated according to the same source address, 222 and all SPT (S, G) entries corresponding to the source address are 223 merged into one assert record. 225 * (*, G) assert is aggregated according to the same RP address, and 226 all (*, G) and RPT (S, G) entries corresponding to the RP address 227 are merged into one assert record. 229 This method can optimize the payload of the transmitted message by 230 merging the same field content, but will add the complexity of the 231 packet encapsulation and parsing. 233 4. Packet Format 235 This section describes the format of new PIM messages introduced by 236 this document. The messages follow the same transmission order as 237 the messages defined in [RFC7761] 238 4.1. PIM Assert Packing Hello Option 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OptionType = TBD | OptionLength = 1 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Packing_Type | 246 +-+-+-+-+-+-+-+-+ 248 - OptionType: TBD 250 - OptionLength: 1 252 - Packing_Type: The specific packing mode is determined by the value 253 of this field: 255 1: indicates simple packing type as described in section 2.2 257 2: indicates aggregating packing type as described in section 2.3 259 3-255: reserved for future 261 4.2. PIM Assert Simple Packing Format 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |PIM Ver| Type | Reserved | Checksum | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Reserved | Number of Assert Records (M) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 . . 272 . Assert Record [1] . 273 . . 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 . . 278 . Assert Record [2] . 279 . . 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | . | 283 . . . 284 | . | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 . . 288 . Assert Record [M] . 289 . . 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The format of each record is the same as the PIM assert message body 294 of section 4.9.6 in [RFC7761]. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Group Address (Encoded-Group format) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Source Address (Encoded-Unicast format) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |R| Metric Preference | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Metric | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 4.3. PIM Assert Aggregation Packing Format 310 This method also extends PIM assert packets to carry multiple 311 records. The specific assert packet format is the same as section 312 3.2, but the records are divided into two types. 314 The (S, G) assert records are organized by the same source address, 315 and the specific message format is: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Source Address (Encoded-Unicast format) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |0| Metric Preference | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Metric | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Number of Groups (N) | Reserved | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Group Address 1 (Encoded-Group format) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Group Address 2 (Encoded-Group format) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | . | 333 | . | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Group Address N (Encoded-Group format) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 The (*, G) assert records are organized in the same RP address and 339 are divided into two levels of TLVs. The first level is the group 340 record of the same RP address, and the second level is the source 341 record of the same multicast group address, including (*, G) and RPT 342 (S, G), and the specific message format is: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | RP Address (Encoded-Unicast format) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |1| Metric Preference | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Metric | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Number of Group Records(O) | Reserved | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 . . 357 . Group Record [1] . 358 . . 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 . . 363 . Group Record [2] . 364 . . 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | . | 368 . . . 369 | . | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 . . 373 . Group Record [O] . 374 . . 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The format of each group record is: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Group Address (Encoded-Group format) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Number of Sources (P) | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Source Address 1 (Encoded-Unicast format) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Source Address 2 (Encoded-Unicast format) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | . | 393 | . | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Source Address P (Encoded-Unicast format) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 5. IANA Considerations 400 This document requests IANA to assign a registry for PIM assert 401 packing Hello Option in the PIM-Hello Options. The assignment is 402 requested permanent for IANA when this document is published as an 403 RFC. The string TBD should be replaced by the assigned values 404 accordingly. 406 6. Security Considerations 408 For general PIM-SM protocol Security Considerations, see [RFC7761]. 410 TBD 412 7. References 414 7.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 420 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 421 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 422 Specification(Revised)", RFC 7761, March 2016 424 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 425 2119 Key Words", BCP 14, RFC 8174, May 2017 427 7.2. Informative References 429 TBD 431 8. Acknowledgments 433 The authors would like to thank the following for their valuable 434 contributions of this document: 436 TBD 437 Authors' Addresses 439 Yisong Liu 440 Huawei Technologies 441 Huawei Bld., No.156 Beiqing Rd. 442 Beijing 100095 443 China 445 Email: liuyisong@huawei.com 447 Mike McBride 448 Huawei Technologies 449 2330 Central Expressway 450 Santa Clara, CA 95055 451 USA 453 Email: Michael.mcbride@huawei.com 455 Toerless Eckert 456 Huawei Technologies 457 2330 Central Expy 458 Santa Clara 95050 459 USA 461 Email: tte+ietf@cs.fau.de