idnits 2.17.1 draft-li-pim-igmp-mld-extension-source-management-03.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 (16 May 2022) is 711 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 508, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-pim-igmp-mld-extension-07 == Outdated reference: A later version (-02) exists of draft-li-pce-multicast-01 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 4 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: 17 November 2022 S. Venaas 6 Cisco Systems 7 16 May 2022 9 IGMP/MLD Extension for Multicast Source Management 10 draft-li-pim-igmp-mld-extension-source-management-03 12 Abstract 14 This document describes extensions to Internet Group Management 15 Protocol (IGMP) and Multicast Listener Discover (MLD) protocol for 16 supporting interaction between multi cast sources and routers, 17 accomplishing multi cast 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 17 November 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised 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 . . . . . . . . . . 8 63 6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. Multicast Management for PCE as multicast controller . . 9 65 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9.1. IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . 11 69 9.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . . 11 70 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 72 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 multi cast management process based on 85 Soft Dedfined Network (SDN) architecture, such as that described in 86 [I-D.li-pce-multicast], the transmission of multi cast source data 87 can be effectively managed, enhancing the security and 88 controllability of the multi cast service. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. Terminology 100 The following terms are used in this document: 102 * BIER: Bit Index Explicit Replication 104 * ICMPv6: Internet Control Message Protocol version 6 106 * IGMP: Internet Group Management Protocol 108 * IP: Internet Protocol 110 * MDN: Multicast Data Notification 112 * MLD: Multicast Listener Discover 114 * MRS: Multicast Receiver Statistics 116 * MSR: Multicast Source Registration 118 * PCE: Path Computation Element 120 * RP: Rendezvous Point 122 * SDN: Software Defined Network 124 4. Overview of Multicast Source Management 126 Multicast source management includes multi cast source registration 127 and authorization, multi cast data transmission and termination, and 128 receiver information statistics. Currently, multi cast source 129 management is mainly used in Source Specific Multicast (SSM) 130 scenario. If multi cast source management is to be applied to Any- 131 Source Multicast (ASM) scenarios, other mechanisms are needed. ASM 132 scenario is not discussed in this document. 134 This document specifies IGMP and MLD protocol extensions for multi 135 cast source management, including Multicast Source Registration (MSR) 136 described in Section 5.1, Multicast Data Notification (MDN) described 137 in Section 5.2 and Multicast Receiver Statistics (MRS) described in 138 Section 5.3. 140 4.1. Multicast Source Registration and Authorization 142 Source systems send Multicast Source Registration messages to routers 143 informing them that there are multi cast sources available to provide 144 services. The Multicast Source Registration message must contain the 145 multi cast source address, service start time and validity period of 146 the request. In some scenarios, The Multicast Source Registration 147 message also needs to contain credential for controlling multi cast 148 source access. Credential authentication can be performed on the 149 first-hop router or on other systems. The specific implementation 150 can be adjusted according to the deployment. 152 After receiving the registration message from the source system and 153 authenticating, the routers send Multicast Source Registration 154 messages with valid registration status response to the source 155 systems and inform the source systems that the requests are approved. 156 The routers will trigger a timer and maintain the registration status 157 for the source systems until the timer expires. 159 In contrast, the source systems can also send Multicast Source 160 Registration messages to routers to withdraw the registration 161 requests. Then the routers will revoke the registration status and 162 reply to the source systems. 164 The source systems need periodically send registration messages to 165 the routers to inform the router that the multi cast source is alive. 166 Then routers will refresh the timer of the registration status. If 167 routers receive multi cast data from multi cast sources, they will 168 refresh the timer. During data delivery, the source systems does not 169 have to send registration messages periodically. 171 When the timer expires or the registration validity period expires, 172 the router will release the registration status and send a Multicast 173 Source Registration message with invalid registration status to the 174 source system to inform it. 176 4.2. Multicast Data Transmission and Termination 178 Within the service validity of registration, when the first receiver 179 joins a multi cast group with SSM address, the corresponding first 180 hop router will send Multicast Data Notification message carrying 181 multi cast group address to inform the source system that the source 182 can send data to this multi cast group. 184 For a specific (S, G) tuple, when the last receiver leaves the multi 185 cast group, the first hop router will send Multicast Data 186 Notification message carrying multi cast group address to inform the 187 source system that the source should stop sending data to this multi 188 cast group. 190 4.3. Receiver Information Statistics 192 For certain scenarios, a first hop router can learn receiver 193 statistics for a specific (S, G) tuple. For example, in SDN 194 scenario, the receiver statistics of each egress router can be 195 centrally managed by the controller. The controller then aggregates 196 these statistics and informs the first-hop router. 198 In this case, if the first hop router has sent Multicast Data 199 Notification message to the source system to inform the source system 200 sending data, the first-hop router should periodically send Multicast 201 Receiver Statistics messages to the source system synchronizing the 202 receiver statistics. In this way, the source system can perform 203 analysis based on the receiver statistics, facilitating further 204 optimization and scaling. 206 5. Message Formats 208 There are three types of IGMP and MLD messages associated with multi 209 cast source advertisement described in this document. 211 5.1. Multicast Source Registration Message 213 MSR message is sent by multi cast source to request multi cast data 214 transmission service activation or by router responding to the 215 request from the multi cast source. 217 MSR message has the following format: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type = TBD1,2 | |E|I|R|A| Checksum | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Credential Len | Reserved | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 ~ Multicast Source Address ~ 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Start Timestamp (64 bits) | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Duration (32 bits) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Credential ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 ~ Extension ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: MSR Message Format 239 Type (8 bits): IGMP and MLD messages types, they need to be 240 registered by the IANA. 242 E(E-bit): E-bit set to 1 to indicate that extension is present in the 243 message. E-bit set to 0 to indicate that extension is not present in 244 the message. The E-bit MUST be set to 1 to indicate that the 245 extension is present. Otherwise, it MUST be 0. 247 I (Identity flag, 1 bit): The I flag set to 1 indicates that the 248 message is sent by multi cast source. The I flag set to 0 indicates 249 that the message is sent by router. 251 R (Request flag, 1 bit): The R flag set to 1 indicates the request to 252 activate transmission service. The R flag set to 0 indicates 253 revocation of the request. 255 A (Authentication flag, 1 bit): The A flag set to 1 indicates success 256 of request. The A flag set to 0 indicates failure of request or 257 revocation of the request. 259 Checksum (16 bits): The Checksum is the 16-bit one's complement of 260 the one's complement sum of the whole IGMP or MLD message (the entire 261 IP payload). For computing the checksum, the Checksum field is set 262 to zero. When receiving packets, the checksum MUST be verified 263 before processing a message. 265 Multicast Source Address (Variable length): contains IPv4 or IPv6 266 address of the multi cast source requested. If the MSR Message is 267 used in IGMP, the length of the address is 32 bits. If the MSR 268 Message is used in MLD, the length of the address is 128 bits. 270 Start Timestamp (8 bytes): indicates the start time when the multi 271 cast source can provide data services. Before this time, the multi 272 cast source cannot send data to multi cast groups. 274 Duration (1 byte): indicates the maximum duration that the multi cast 275 source can provide data services in a valid registration request. 277 Credential (Variable length): is used for authorization of multi cast 278 sources. 280 Extension: It is defined and described in 281 [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of 282 TLVs for flexible extension. 284 5.2. Multicast Data Notification Message 286 MDN message is sent by router to notify multi cast source to start or 287 stop sending multi cast packets. For different (S, G) tuples, the 288 router needs to send multiple MDN messages. 290 MDN message has the following format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type = TBD3,4 | Reserved |E|C| Checksum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ Multicast Group Address ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ Extension ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: MDN Message Format 303 Type (8 bits): IGMP and MLD messages types, they need to be 304 registered by the IANA. 306 E(E-bit): E-bit set to 1 to indicate that extension is present in the 307 message. E-bit set to 0 to indicate that extension is not present in 308 the message. The E-bit MUST be set to 1 to indicate that the 309 extension is present. Otherwise, it MUST be 0. 311 C (Control flag, 1 bit): The C flag set to 1 indicates starting 312 sending multi cast packets. The C flag set to 0 indicates stopping 313 sending multi cast packets. 315 Checksum (16 bits): The Checksum is the 16-bit one's complement of 316 the one's complement sum of the whole IGMP/MLD message (the entire IP 317 payload). For computing the checksum, the Checksum field is set to 318 zero. When receiving packets, the checksum MUST be verified before 319 processing a message. 321 Multicast Group Address (Variable length): contains IPv4 or IPv6 322 address of the multi cast group requested. If the MDN message is 323 used in IGMP, the length of the address is 32 bits. If the MDN 324 message is used in MLD, the length of the address is 128 bits. 326 5.3. Multicast Receiver Statistics Message 328 MRS message is sent by router to multi cast source to synchronize 329 receiver statistics of a group. For different (S, G) tuples, the 330 router needs to send multiple MRS messages. 332 MRS message has the following format: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type = TBD5,6 | Reserved |E| Checksum | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ Multicast Group Address ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Number of Receivers | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 ~ Extension ~ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 3: MRS Message Format 347 Type (8 bits): IGMP and MLD messages types, they need to be 348 registered by the IANA. 350 E(E-bit): E-bit set to 1 to indicate that extension is present in the 351 message. E-bit set to 0 to indicate that extension is not present in 352 the message. The E-bit MUST be set to 1 to indicate that the 353 extension is present. Otherwise, it MUST be 0. 355 Checksum (16 bits): The Checksum is the 16-bit one's complement of 356 the one's complement sum of the whole IGMP/MLD message (the entire IP 357 payload). For computing the checksum, the Checksum field is set to 358 zero. When receiving packets, the checksum MUST be verified before 359 processing a message. 361 Multicast Group Address (Variable length): contains IPv4 or IPv6 362 address of the multi cast group requested. If the MRS message is 363 used in IGMP, the length of the address is 32 bits. If the MRS 364 message is used in MLD, the length of the address is 128 bits. 366 Number of Receivers (32 bits): indicates the number of receivers for 367 a particular (S,G) tuple 369 6. Use Case 371 6.1. Multicast Management for PCE as multicast controller 373 This section briefly describes procedures of multi cast source 374 management through a simple example of Path Computation Element(PCE) 375 based Bit Index Explicit Replication(BIER). 377 The specific implementation process is as follows: 379 +------------------+ 380 +-------+ Controller +-------+ 381 | +--------^---------+ | 382 | | 383 | | 384 S2 | S3/7 +--------+ | S6 385 | --------+ R3 +-------- | 386 | / +--------+ \ | 387 | / \ | 388 +------+ S1/9 +--+ S11 +--+ +--+ +--+ S5 +--------+ 389 |Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver| 390 +------+ S4/8/10+--+ +--+ +--+ +--+ +--------+ 391 | | 392 | +--+ +--+ | 393 +---------+R2+----------+R4+-------+ 394 +--+ +--+ 395 Figure 4: Topology of multi cast source management for PCE based BIER 397 For the solution of PCE based BIER, the transmission of multi cast 398 source registration and authorization and receiver information 399 statistics depends on the PCRpt message and PCUpd message, defined in 400 [RFC8231] and extended in [I-D.li-pce-multicast], between the router 401 and the controller. 403 S1, S4, S8 and S10 in the figure are multi cast source advertisement 404 related processes. S1 is the process by which multi cast sources 405 send messages and data to router. S4, S8 and S10 are the process by 406 which router send messages to multi cast sources. The other steps 407 are beyond the scope of this document. 409 Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to 410 activate the multi cast data transmission service. 412 Step 2(S2): R1 sends multi cast information registration to 413 controller via PCRpt message. 415 Step 3(S3): The controller sends PCUpd message to the R1, carrying 416 authentication result. 418 Step 4(S4): R1 sends authentication result to the source via IGMP or 419 MLD MSR message. Source will conduct subsequent processing based on 420 the authentication result, such as reapplying after the failure of 421 authentication. 423 Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to 424 join or leave a multi cast group. 426 Step 6(S6): R7 converts the IGMP or MLD messages of receivers into 427 PCRpt message and send it to the controller. 429 Step 7(S7): The controller sends PCUpd message to R1 to start or stop 430 forwarding, carrying BitString. 432 Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify 433 the source sending multi cast packets to the specific multi cast 434 group. 436 Step 9(S9): Source sends multicast data to R1. 438 Step 10(S10): R1 sends IGMP or MLD MSR messages with multi cast 439 receivers' statistics to the source periodically. 441 7. Deployment Considerations 443 8. Security Considerations 445 9. IANA Considerations 447 9.1. IGMP Type Numbers 449 IANA is requested to allocate a new code point within registry "IGMP 450 Type Numbers" under "Internet Group Management Protocol (IGMP) Type 451 Numbers" as follows: 453 Type Number Message Name 454 ------------- ----------------------------- 455 TBD1 Multicast Source Activation 456 TBD3 Multicast Data Notification 457 TBD5 Multicast Receiver Statistics 459 9.2. ICMPv6 Parameters 461 IANA is requested to allocate a new code point within registry 462 "ICMPv6 "type" Numbers" under "Internet Control Message Protocol 463 version 6 (ICMPv6) Parameters" as follows: 465 Type Number Message Name 466 ------------- ----------------------------- 467 TBD2 Multicast Source Activation 468 TBD4 Multicast Data Notification 469 TBD6 Multicast Receiver Statistics 471 10. Contributor 473 11. Acknowledgement 475 12. Normative References 477 [I-D.ietf-pim-igmp-mld-extension] 478 Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda, 479 "Internet Group Management Protocol version 3 (IGMPv3) and 480 Multicast Listener Discovery version 2 (MLDv2) Message 481 Extension", Work in Progress, Internet-Draft, draft-ietf- 482 pim-igmp-mld-extension-07, 9 May 2022, 483 . 486 [I-D.li-pce-multicast] 487 Li, H., Wang, A., Zhang, Z., Chen, H., and R. Chen, 488 "Multicast Tree Setup via PCEP", Work in Progress, 489 Internet-Draft, draft-li-pce-multicast-01, 20 March 2022, 490 . 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 499 Thyagarajan, "Internet Group Management Protocol, Version 500 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 501 . 503 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 504 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 505 DOI 10.17487/RFC3810, June 2004, 506 . 508 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 509 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 510 Protocol Specification (Revised)", RFC 4601, 511 DOI 10.17487/RFC4601, August 2006, 512 . 514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 516 May 2017, . 518 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 519 Computation Element Communication Protocol (PCEP) 520 Extensions for Stateful PCE", RFC 8231, 521 DOI 10.17487/RFC8231, September 2017, 522 . 524 Authors' Addresses 526 Huanan Li 527 China Telecom 528 Beiqijia Town, Changping District 529 Beijing 530 Beijing, 102209 531 China 532 Email: lihn6@foxmail.com 534 Aijun Wang 535 China Telecom 536 Beiqijia Town, Changping District 537 Beijing 538 Beijing, 102209 539 China 540 Email: wangaj3@chinatelecom.cn 542 Stig Venaas 543 Cisco Systems 544 Tasman Drive 545 San Jose, CA 95134 546 United States of America 547 Email: stig@cisco.com