idnits 2.17.00 (12 Aug 2021) /tmp/idnits52333/draft-li-pim-igmp-mld-extension-source-management-02.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 (7 November 2021) is 188 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) == Unused Reference: 'RFC4601' is defined on line 491, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pim-igmp-mld-extension-05 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Li 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: 11 May 2022 S. Venaas 6 Cisco Systems 7 7 November 2021 9 IGMP/MLD Extension for Multicast Source Management 10 draft-li-pim-igmp-mld-extension-source-management-02 12 Abstract 14 This document describes extensions to Internet Group Management 15 Protocol (IGMP) and Multicast Listener Discover (MLD) protocols for 16 supporting interaction between multicast sources and routers, 17 accomplishing multicast source management. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 11 May 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Overview of Multicast Source Management . . . . . . . . . . . 3 56 4.1. Multicast Source Registration and Authorization . . . . . 4 57 4.2. Multicast Data Transmission and Termination . . . . . . . 4 58 4.3. Receiver Information Statistics . . . . . . . . . . . . . 5 59 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Multicast Source Registration Message . . . . . . . . . . 5 61 5.2. Multicast Data Notification Message . . . . . . . . . . . 7 62 5.3. Multicast Receiver Statistics Message . . . . . . . . . . 7 63 6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Multicast Source Management for PCE based BIER . . . . . 8 65 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . 10 69 9.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . . 10 70 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 72 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Among protocols for Internet Protocol (IP) multicast, there is no 78 protocol specification for the source registration so far. The 79 current protocol focuses more on data control. This document 80 specifies some new messages to extend IGMPv3 [RFC3376] and MLDv2 81 [RFC3810] for exchanging source registration information and data 82 transmission control information between sources and routers. 84 In addition, combined with the multicast management process based on 85 SDN architecture described in [I-D.li-pce-based-bier], the 86 transmission of multicast source data can be effectively controlled, 87 enhancing the security and controllability of the multicast service. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. Terminology 99 The following terms are used in this document: 101 * BIER: Bit Index Explicit Replication 103 * ICMPv6: Internet Control Message Protocol version 6 105 * IGMP: Internet Group Management Protocol 107 * IP: Internet Protocol 109 * MDN: Multicast Data Notification 111 * MLD: Multicast Listener Discover 113 * MRS: Multicast Receiver Statistics 115 * MSR: Multicast Source Registration 117 * PCE: Path Computation Element 119 * RP: Rendezvous Point 121 * SDN: Software Defined Network 123 4. Overview of Multicast Source Management 125 Multicast source management includes multicast source registration 126 and authorization, multicast data transmission and termination, and 127 receiver information statistics. Currently, multicast source 128 management is mainly used in Source Specific Multicast (SSM) 129 scenario. If multicast source management is to be applied to Any- 130 Source Multicast (ASM) scenarios, other mechanisms are needed. ASM 131 scenario is not discussed in this document. 133 This document specifies IGMP and MLD protocol extensions for 134 multicast source management, including Multicast Source Registration 135 (MSR) described in Section 5.1, Multicast Data Notification (MDN) 136 described in Section 5.2 and Multicast Receiver Statistics (MRS) 137 described in Section 5.3. 139 4.1. Multicast Source Registration and Authorization 141 Source systems send Multicast Source Registration messages to routers 142 informing them that there are multicast sources available to provide 143 services. The Multicast Source Registration message must contain the 144 multicast source address, service start time and validity period of 145 the request. In some scenarios, The Multicast Source Registration 146 message also needs to contain credential for controlling multicast 147 source access. 149 After receiving the registration message from the source system and 150 authenticating, the routers send Multicast Source Registration 151 messages with valid registration status response to the source 152 systems and inform the source systems that the requests are approved. 153 The routers will trigger a timer and maintain the registration status 154 for the source systems until the timer expires. 156 In contrast, the source systems can also send Multicast Source 157 Registration messages to routers to withdraw the registration 158 requests. Then the routers will revoke the registration status and 159 reply to the source systems. 161 The source systems need periodically send registration messages to 162 the routers to inform the router that the multicast source is alive. 163 Then routers will refresh the timer of the registration status. If 164 routers receive multicast data from multicast sources, they will 165 refresh the timer. During data delivery, the source systems does not 166 have to send registration messages periodically. 168 When the timer expires or the registration validity period expires, 169 the router will release the registration status and send a Multicast 170 Source Registration message with invalid registration status to the 171 source system to inform it. 173 4.2. Multicast Data Transmission and Termination 175 Within the service validity of registration, when the first receiver 176 joins a multicast group with SSM address and requests to receive data 177 from a specific multicast source, the first hop router will send 178 Multicast Data Notification message carrying multicast group address 179 to inform the source system that the source can send data to this 180 multicast group. 182 For a specific (S, G) tuple, when the last receiver leaves the 183 multicast group, the first hop router will send Multicast Data 184 Notification message carrying multicast group address to inform the 185 source system that the source should stop sending data to this 186 multicast group. 188 4.3. Receiver Information Statistics 190 For certain scenarios, a first hop router can learn receiver 191 statistics for a specific (S, G) tuple. For example, in SDN 192 scenario, the receiver statistics of each egress router can be 193 centrally managed by the controller. The controller then aggregates 194 these statistics and informs the first-hop router. 196 In this case, if the first hop router has sent Multicast Data 197 Notification message to the source system to inform the source system 198 sending data, the first-hop router should periodically send Multicast 199 Receiver Statistics messages to the source system synchronizing the 200 receiver statistics. In this way, the source system can perform 201 analysis based on the receiver statistics, facilitating further 202 optimization and scaling. 204 5. Message Formats 206 There are three types of IGMP and MLD messages associated with 207 multicast source advertisement described in this document. 209 5.1. Multicast Source Registration Message 211 MSR message is sent by multicast source to request multicast data 212 transmission service activation or by router responding to the 213 request from the multicast source. 215 MSR message has the following format: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type = TBD1,2 | |E|I|R|A| Checksum | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Credential Len | Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 ~ Multicast Source Address ~ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Start Timestamp (64 bits) | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Duration (32 bits) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 ~ Credential ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Extension ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1: MSR Message Format 237 Type (8 bits): IGMP and MLD messages types, they need to be 238 registered by the IANA. 240 E(E-bit): E-bit set to 1 to indicate that extension is present in the 241 message. E-bit set to 0 to indicate that extension is not present in 242 the message. The E-bit MUST be set to 1 to indicate that the 243 extension is present. Otherwise, it MUST be 0. 245 I (Identity flag, 1 bit): The I flag set to 1 indicates that the 246 message is sent by multicast source. The I flag set to 0 indicates 247 that the message is sent by router. 249 R (Request flag, 1 bit): The R flag set to 1 indicates the request to 250 activate transmission service. The R flag set to 0 indicates 251 revocation of the request. 253 A (Authentication flag, 1 bit): The A flag set to 1 indicates success 254 of request. The A flag set to 0 indicates failure of request or 255 revocation of the request. 257 Checksum (16 bits): The Checksum is the 16-bit one's complement of 258 the one's complement sum of the whole IGMP or MLD message (the entire 259 IP payload). For computing the checksum, the Checksum field is set 260 to zero. When receiving packets, the checksum MUST be verified 261 before processing a message. 263 Multicast Source Address (Variable length): contains IPv4 or IPv6 264 address of the multicast source requested. If the MSR Message is 265 used in IGMP, the length of the address is 32 bits. If the MSR 266 Message is used in MLD, the length of the address is 128 bits. 268 Start Timestamp (8 bytes): indicates the start time when the 269 multicast source can provide data services. Before this time, the 270 multicast source cannot send data to multicast groups. 272 Duration (1 byte): indicates the maximum duration that the multicast 273 source can provide data services in a valid registration request. 275 Credential (Variable length): is used for authorization of multicast 276 sources. 278 Extension: It is defined and described in 279 [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of 280 TLVs for flexible extension. 282 5.2. Multicast Data Notification Message 284 MDN message is sent by router to notify multicast source to start or 285 stop sending multicast packets. For different (S, G) tuples, the 286 router needs to send multiple MDN messages. 288 MDN message has the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type = TBD3,4 | Reserved |C| Checksum | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ~ Multicast Group Address ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 2: MDN Message Format 299 Type (8 bits): IGMP and MLD messages types, they need to be 300 registered by the IANA. 302 C (Control flag, 1 bit): The C flag set to 1 indicates starting 303 sending multicast packets. The C flag set to 0 indicates stopping 304 sending multicast packets. 306 Checksum (16 bits): The Checksum is the 16-bit one's complement of 307 the one's complement sum of the whole IGMP/MLD message (the entire IP 308 payload). For computing the checksum, the Checksum field is set to 309 zero. When receiving packets, the checksum MUST be verified before 310 processing a message. 312 Multicast Group Address (Variable length): contains IPv4 or IPv6 313 address of the multicast group requested. If the MDN message is used 314 in IGMP, the length of the address is 32 bits. If the MDN message is 315 used in MLD, the length of the address is 128 bits. 317 5.3. Multicast Receiver Statistics Message 319 MRS message is sent by router to multicast source to synchronize 320 receiver statistics of a group. For different (S, G) tuples, the 321 router needs to send multiple MRS messages. 323 MRS message has the following format: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type = TBD5,6 | Reserved | Checksum | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 ~ Multicast Group Address ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Number of Receivers | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 3: MRS Message Format 336 Type (8 bits): IGMP and MLD messages types, they need to be 337 registered by the IANA. 339 Checksum (16 bits): The Checksum is the 16-bit one's complement of 340 the one's complement sum of the whole IGMP/MLD message (the entire IP 341 payload). For computing the checksum, the Checksum field is set to 342 zero. When receiving packets, the checksum MUST be verified before 343 processing a message. 345 Multicast Group Address (Variable length): contains IPv4 or IPv6 346 address of the multicast group requested. If the MRS message is used 347 in IGMP, the length of the address is 32 bits. If the MRS message is 348 used in MLD, the length of the address is 128 bits. 350 Number of Receivers (32 bits): indicates the number of receivers for 351 a particular (S,G) tuple. 353 6. Use Case 355 6.1. Multicast Source Management for PCE based BIER 357 This section briefly describes procedures of multicast source 358 management through a simple example of Path Computation Element(PCE) 359 based Bit Index Explicit Replication(BIER) described in extended in 360 [I-D.li-pce-based-bier]. 362 The specific implementation process is as follows: 364 +------------------+ 365 +-------+ Controller +-------+ 366 | +--------^---------+ | 367 | | 368 | | 369 S2 | S3/7 +--------+ | S6 370 | --------+ R3 +-------- | 371 | / +--------+ \ | 372 | / \ | 373 +------+ S1/9 +--+ S11 +--+ +--+ +--+ S5 +--------+ 374 |Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver| 375 +------+ S4/8/10+--+ +--+ +--+ +--+ +--------+ 376 | | 377 | +--+ +--+ | 378 +---------+R2+----------+R4+-------+ 379 +--+ +--+ 380 Figure 4: Topology of multicast source management for PCE based BIER 382 For PCE based BIER, the transmission of multicast source registration 383 and authorization and receiver information statistics depends on the 384 PCRpt message and PCUpd message, defined in [RFC8231] and extended in 385 [I-D.li-pce-based-bier], between the router and the controller. 387 S1, S4, S8 and S10 in the figure are multicast source advertisement 388 related processes. S1 is the process by which multicast sources send 389 messages and data to router. S4, S8 and S10 are the process by which 390 router send messages to multicast sources. The other steps are 391 beyond the scope of this document. 393 Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to 394 activate the multicast data transmission service. 396 Step 2(S2): R1 sends multicast information registration to controller 397 via PCRpt message. 399 Step 3(S3): The controller sends PCUpd message to the R1, carrying 400 authentication result. 402 Step 4(S4): R1 sends authentication result to the source via IGMP or 403 MLD MSR message. Source will conduct subsequent processing based on 404 the authentication result, such as reapplying after the failure of 405 authentication. 407 Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to 408 join or leave a multicast group. 410 Step 6(S6): R7 converts the IGMP or MLD messages of receivers into 411 PCRpt message and send it to the controller. 413 Step 7(S7): The controller sends PCUpd message to R1 to start or stop 414 forwarding, carrying BitString. 416 Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify 417 the source sending multicast packets to the specific multicast group. 419 Step 9(S9): Source sends multicast data to R1. 421 Step 10(S10): R1 sends IGMP or MLD MSR messages with multicast 422 receivers' statistics to the source periodically. 424 7. Deployment Considerations 426 8. Security Considerations 428 9. IANA Considerations 430 9.1. IGMP Type Numbers 432 IANA is requested to allocate a new code point within registry "IGMP 433 Type Numbers" under "Internet Group Management Protocol (IGMP) Type 434 Numbers" as follows: 436 Type Number Message Name 437 ------------- ----------------------------- 438 TBD1 Multicast Source Activation 439 TBD3 Multicast Data Notification 440 TBD5 Multicast Receiver Statistics 442 9.2. ICMPv6 Parameters 444 IANA is requested to allocate a new code point within registry 445 "ICMPv6 "type" Numbers" under "Internet Control Message Protocol 446 version 6 (ICMPv6) Parameters" as follows: 448 Type Number Message Name 449 ------------- ----------------------------- 450 TBD2 Multicast Source Activation 451 TBD4 Multicast Data Notification 452 TBD6 Multicast Receiver Statistics 454 10. Contributor 456 11. Acknowledgement 458 12. Normative References 460 [I-D.ietf-pim-igmp-mld-extension] 461 Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda, 462 "Internet Group Management Protocol version 3 (IGMPv3) and 463 Multicast Listener Discovery version 2 (MLDv2) Message 464 Extension", Work in Progress, Internet-Draft, draft-ietf- 465 pim-igmp-mld-extension-05, 7 November 2021, 466 . 469 [I-D.li-pce-based-bier] 470 Li, H., Wang, A., Chen, H., and R. Chen, "PCE based BIER 471 Procedures and Protocol Extensions", Work in Progress, 472 Internet-Draft, draft-li-pce-based-bier-02, 18 October 473 2021, . 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 482 Thyagarajan, "Internet Group Management Protocol, Version 483 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 484 . 486 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 487 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 488 DOI 10.17487/RFC3810, June 2004, 489 . 491 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 492 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 493 Protocol Specification (Revised)", RFC 4601, 494 DOI 10.17487/RFC4601, August 2006, 495 . 497 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 498 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 499 May 2017, . 501 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 502 Computation Element Communication Protocol (PCEP) 503 Extensions for Stateful PCE", RFC 8231, 504 DOI 10.17487/RFC8231, September 2017, 505 . 507 Authors' Addresses 509 Huanan Li 510 China Telecom 511 Beiqijia Town, Changping District 512 Beijing 513 Beijing, 102209 514 China 516 Email: lihn6@foxmail.com 518 Aijun Wang 519 China Telecom 520 Beiqijia Town, Changping District 521 Beijing 522 Beijing, 102209 523 China 525 Email: wangaj3@chinatelecom.cn 527 Stig Venaas 528 Cisco Systems 529 Tasman Drive 530 San Jose, CA 95134 531 United States of America 533 Email: stig@cisco.com