idnits 2.17.1 draft-li-pim-igmp-mld-extension-source-management-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 date (July 9, 2021) is 1022 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 421, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-pim-igmp-mld-extension-04 == Outdated reference: A later version (-02) exists of draft-li-pce-based-bier-00 ** 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: January 10, 2022 July 9, 2021 7 IGMP/MLD Extension for Multicast Source Management 8 draft-li-pim-igmp-mld-extension-source-management-00 10 Abstract 12 This document describes extensions to Internet Group Management 13 Protocol(IGMP) and Multicast Listener Discover(MLD) protocols for 14 supporting interaction between multicast sources and routers, 15 accomplishing multicast source management. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 10, 2022. 34 Copyright Notice 36 Copyright (c) 2021 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 (https://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 respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 2 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 4. Overview of Multicast Source Management . . . . . . . . . . . 3 55 4.1. Topology of multicast source advertisement for PCE based 56 BIER . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Multicast Source Registration Message . . . . . . . . . . 5 60 5.2. Multicast Data Notification message . . . . . . . . . . . 7 61 5.3. Multicast Receiver Status message . . . . . . . . . . . . 8 62 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8.1. IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . 9 66 8.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . . 9 67 9. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 69 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Among protocols for Internet Protocol(IP) multicast, there is no 75 interaction protocol between multicast sources and routers so far. 76 This document spceifies some new messages to extend IGMPv3 [RFC3376] 77 and MLDv2 [RFC3810] for exchanging source registration information 78 and data transmission control information between sources and 79 routers. In addition, combined with the multicast management process 80 described in [I-D.li-pce-based-bier], the transmission of multicast 81 source data can be effectively controlled, enhancing the security and 82 controllability of the multicast service. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 3. Terminology 94 The following terms are used in this document: 96 o BIER: Bit Index Explicit Replication 97 o ICMPv6: Internet Control Message Protocol version 6 99 o IGMP: Internet Group Management Protocol 101 o IP: Internet Protocol 103 o MDN: Multicast Data Notification 105 o MLD: Multicast Listener Discover 107 o MRS: Multicast Receiver Status 109 o MSR: Multicast Source Registration 111 o PCE: Path Computation Element 113 o RP: Rendezvous Point 115 4. Overview of Multicast Source Management 117 Multicast source management includes multicast source registration 118 and authorization, multicast data transmission and termination, and 119 receiver information statistics. 121 This section briefly describes procedures of multicast source 122 management through a simple example of Path Computation Element(PCE) 123 based Bit Index Explicit Replication(BIER) described in extended in 124 [I-D.li-pce-based-bier]. 126 This document specifies IGMP and MLD protocol extensions for 127 multicast source advertisement, including Multicast Source 128 Registration (MSR) described in Section 5.1, Multicast Data 129 Notification (MDN) described in Section 5.2 and Multicast Receiver 130 Status(MRS) described in Section 5.3. 132 4.1. Topology of multicast source advertisement for PCE based BIER 134 The specific implementation process is as follows: 136 +------------------+ 137 +-------+ Controller +-------+ 138 | +--------^---------+ | 139 | | 140 | | 141 S2 | S3/7 +--------+ | S6 142 | --------+ R3 +-------- | 143 | / +--------+ \ | 144 | / \ | 145 +------+ S1/9 +--+ S11 +--+ +--+ +--+ S5 +--------+ 146 |Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver| 147 +------+ S4/8/10+--+ +--+ +--+ +--+ +--------+ 148 | | 149 | +--+ +--+ | 150 +---------+R2+----------+R4+-------+ 151 +--+ +--+ 152 Figure 1: Topology of multicast source advertisement for PCE based BIER 154 4.2. Procedures 156 For PCE based BIER, the transmission of multicast source registration 157 and authorization and receiver information statistics depends on the 158 PCRpt message and PCUpd message, defined in [RFC8231] and extended in 159 [I-D.li-pce-based-bier], between the router and the controller. 161 S1, S4, S8 and S10 in the figure are multicast source advertisement 162 related processes. S1 is the process by which multicast sources send 163 messages and data to router. S4, S8 and S10 are the process by which 164 router send messages to multicast sources. The other steps are 165 beyond the scope of this document. 167 Step 1(S1) : Source sends IGMP or MLD MSR message to R1 requesting to 168 activate the multicast data transmission service. 170 Step 2(S2) : R1 sends multicast information registration to 171 controller via PCRpt message. 173 Step 3(S3) : The controller sends PCUpd message to the R1, carrying 174 authentication result. 176 Step 4(S4) : R1 sends authentication result to the source via IGMP or 177 MLD MSR message. Source will conduct subsequent processing based on 178 the authentication result, such as reapplying after the failure of 179 authentication. 181 Step 5(S5) : Receivers send IGMP or MLD messages to R7 requesting to 182 join or leave a multicast group. 184 Step 6(S6) : R7 converts the IGMP or MLD messages of receivers into 185 PCRpt message and send it to the controller. 187 Step 7(S7) : The controller sends PCUpd message to R1 to start or 188 stop forwarding, carrying BitString. 190 Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify 191 the source sending multicast packets to the specific multicast group. 193 Step 9(S9): Source sends multicast data to R1. 195 Step 10(S10): R1 sends IGMP or MLD MSR messages with multicast 196 receivers statistics to the source periodically. 198 5. Message Formats 200 There are three types of IGMP and MLD messages associated with 201 multicast source advertisement described in this document. 203 5.1. Multicast Source Registration Message 205 MSR message is sent by multicast source to request multicast data 206 transmission service activation or by router responding to the 207 request from the multicast source. For a multicast source, it only 208 needs to send MSR message once in the valid time. 210 MSR message has the following format: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type = TBD1,2 | |E|I|R|A| Checksum | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Address Type | Credential Len| Reserved | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 ~ Multicast Source Address ~ 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ~ Credential ~ 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Start Timestamp (64 bits) | 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | End Timestamp (64 bits) | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ Extension ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: MSR Message Format 233 Type(8 bits): IGMP and MLD messages types, they need to be registered 234 by the IANA. 236 E(E-bit): E-bit set to 1 to indicate that extension is present in the 237 message. E-bit set to 0 to indicate that extension is not present in 238 the message. The E-bit MUST be set to 1 to indicate that the 239 extension is present. Otherwise it MUST be 0. 241 I (Identity flag, 1 bit): The I flag set to 1 indicates that the 242 message is sent by multicast source. The I flag set to 0 indicates 243 that the message is sent by router. 245 R (Request flag, 1 bit): The R flag set to 1 indicates the request to 246 activate transmission service. The R flag set to 0 indicates 247 revocation of the request. 249 A (Authentication flag, 1 bit): The A flag set to 1 indicates success 250 of request. The A flag set to 0 indicates failure of request or 251 revocation of the request. 253 Checksum(16 bits): The Checksum is the 16-bit one's complement of the 254 one's complement sum of the whole IGMP or MLD message (the entire IP 255 payload). For computing the checksum, the Checksum field is set to 256 zero. When receiving packets, the checksum MUST be verified before 257 processing a message. 259 Address Type(8 bits): indicates the type of the source address. 260 Address Type = 1: IPv4 address. Address Type = 2: IPv6 address. 262 Credential Len(8 bits): indicates the length of Credential. 264 Multicast Source Address(Variable length): contains IPv4 or IPv6 265 address of the multicast source requested. 267 Credential(Variable length): is used for authorization of multicast 268 sources. 270 Start Timestamp(8 bytes): indicates the start time of the 271 registration. 273 End Timestamp(8 bytes): indicates the end time of the registration. 275 Extension: It is defined and described in 276 [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of 277 TLVs for flexible extension. 279 Reserved: The Reserved fields are set to zero on transmission, and 280 ignored on reception. 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 | Address Type | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ Multicast Group Address ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 2: MDN Message Format 301 Type(8 bits): IGMP and MLD messages types, they need to be registered 302 by the IANA. 304 C (Control flag, 1 bit): The C flag set to 1 indicates starting 305 sending multicast packets. The C flag set to 0 indicates stopping 306 sending multicast packets. 308 Checksum(16 bits): The Checksum is the 16-bit one's complement of the 309 one's complement sum of the whole IGMP/MLD message (the entire IP 310 payload). For computing the checksum, the Checksum field is set to 311 zero. When receiving packets, the checksum MUST be verified before 312 processing a message. 314 Address Type(8 bits): indicates the type of the source address. 315 Address Type = 1: IPv4 address. Address Type = 2: IPv6 address. 317 Multicast Group Address(Variable length): contains IPv4 or IPv6 318 address of the multicast group requested. 320 Reserved: The Reserved fields are set to zero on transmission, and 321 ignored on reception. 323 5.3. Multicast Receiver Status message 325 MRS message is sent by router to multicast source to synchronize 326 receiver statistics of a group. For different (S,G) tuples, the 327 router needs to send multiple MRS messages. 329 MRS message has the following format: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type = TBD5,6 | Address Type | Checksum | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ~ Multicast Group Address ~ 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Number of Receivers | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 3: MRS Message Format 342 Type(8 bits): IGMP and MLD messages types, they need to be registered 343 by the IANA. 345 Checksum(16 bits): The Checksum is the 16-bit one's complement of the 346 one's complement sum of the whole IGMP/MLD message (the entire IP 347 payload). For computing the checksum, the Checksum field is set to 348 zero. When receiving packets, the checksum MUST be verified before 349 processing a message. 351 Address Type(8 bits): indicates the type of the source address. 352 Address Type = 1: IPv4 address. Address Type = 2: IPv6 address. 354 Multicast Group Address(Variable length): contains IPv4 or IPv6 355 address of the multicast group requested. 357 Number of Receivers(32 bits): indicates the number of receivers for a 358 particular (S,G) tuple. 360 6. Deployment Considerations 362 7. Security Considerations 364 8. IANA Considerations 366 8.1. IGMP Type Numbers 368 IANA is requested to allocate a new code point within registry "IGMP 369 Type Numbers" under "Internet Group Management Protocol (IGMP) Type 370 Numbers" as follows: 372 Type Number Message Name 373 ------------- ----------------------------- 374 TBD1 Multicast Source Activation 375 TBD3 Multicast Data Notification 376 TBD5 Multicast Receiver Status 378 8.2. ICMPv6 Parameters 380 IANA is requested to allocate a new code point within registry 381 "ICMPv6 "type" Numbers" under "Internet Control Message Protocol 382 version 6 (ICMPv6) Parameters" as follows: 384 Type Number Message Name 385 ------------- ----------------------------- 386 TBD2 Multicast Source Activation 387 TBD4 Multicast Data Notification 388 TBD6 Multicast Receiver Status 390 9. Contributor 392 10. Acknowledgement 394 11. Normative References 396 [I-D.ietf-pim-igmp-mld-extension] 397 Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda, 398 "IGMPv3/MLDv2 Message Extension", draft-ietf-pim-igmp-mld- 399 extension-04 (work in progress), January 2021. 401 [I-D.li-pce-based-bier] 402 Li, H., Wang, A., Chen, H., and R. Chen, "PCE based BIER 403 Procedures and Protocol Extensions", draft-li-pce-based- 404 bier-00 (work in progress), June 2021. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 412 Thyagarajan, "Internet Group Management Protocol, Version 413 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 414 . 416 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 417 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 418 DOI 10.17487/RFC3810, June 2004, 419 . 421 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 422 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 423 Protocol Specification (Revised)", RFC 4601, 424 DOI 10.17487/RFC4601, August 2006, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 432 Computation Element Communication Protocol (PCEP) 433 Extensions for Stateful PCE", RFC 8231, 434 DOI 10.17487/RFC8231, September 2017, 435 . 437 Authors' Addresses 438 Huanan Li 439 China Telecom 440 Beiqijia Town, Changping District 441 Beijing, Beijing 102209 442 China 444 Email: lihn6@foxmail.com 446 Aijun Wang 447 China Telecom 448 Beiqijia Town, Changping District 449 Beijing, Beijing 102209 450 China 452 Email: wangaj3@chinatelecom.cn