Internet-Draft IGMP/MLD Extension for Multicast Source May 2022
Li, et al. Expires 17 November 2022 [Page]
Workgroup:
PIM Working Group
Internet-Draft:
draft-li-pim-igmp-mld-extension-source-management-03
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Li
China Telecom
A. Wang
China Telecom
S. Venaas
Cisco Systems

IGMP/MLD Extension for Multicast Source Management

Abstract

This document describes extensions to Internet Group Management Protocol (IGMP) and Multicast Listener Discover (MLD) protocol for supporting interaction between multi cast sources and routers, accomplishing multi cast source management.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 17 November 2022.

▲

Table of Contents

1. Introduction

Among protocols for Internet Protocol (IP) multicast, there is no protocol specification for the source registration so far. The current protocol focuses more on data control. This document specifies some new messages to extend IGMPv3 [RFC3376] and MLDv2 [RFC3810] for exchanging source registration information and data transmission control information between sources and routers.

In addition, combined with the multi cast management process based on Soft Dedfined Network (SDN) architecture, such as that described in [I-D.li-pce-multicast], the transmission of multi cast source data can be effectively managed, enhancing the security and controllability of the multi cast service.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

The following terms are used in this document:

4. Overview of Multicast Source Management

Multicast source management includes multi cast source registration and authorization, multi cast data transmission and termination, and receiver information statistics. Currently, multi cast source management is mainly used in Source Specific Multicast (SSM) scenario. If multi cast source management is to be applied to Any-Source Multicast (ASM) scenarios, other mechanisms are needed. ASM scenario is not discussed in this document.

This document specifies IGMP and MLD protocol extensions for multi cast source management, including Multicast Source Registration (MSR) described in Section 5.1, Multicast Data Notification (MDN) described in Section 5.2 and Multicast Receiver Statistics (MRS) described in Section 5.3.

4.1. Multicast Source Registration and Authorization

Source systems send Multicast Source Registration messages to routers informing them that there are multi cast sources available to provide services. The Multicast Source Registration message must contain the multi cast source address, service start time and validity period of the request. In some scenarios, The Multicast Source Registration message also needs to contain credential for controlling multi cast source access. Credential authentication can be performed on the first-hop router or on other systems. The specific implementation can be adjusted according to the deployment.

After receiving the registration message from the source system and authenticating, the routers send Multicast Source Registration messages with valid registration status response to the source systems and inform the source systems that the requests are approved. The routers will trigger a timer and maintain the registration status for the source systems until the timer expires.

In contrast, the source systems can also send Multicast Source Registration messages to routers to withdraw the registration requests. Then the routers will revoke the registration status and reply to the source systems.

The source systems need periodically send registration messages to the routers to inform the router that the multi cast source is alive. Then routers will refresh the timer of the registration status. If routers receive multi cast data from multi cast sources, they will refresh the timer. During data delivery, the source systems does not have to send registration messages periodically.

When the timer expires or the registration validity period expires, the router will release the registration status and send a Multicast Source Registration message with invalid registration status to the source system to inform it.

4.2. Multicast Data Transmission and Termination

Within the service validity of registration, when the first receiver joins a multi cast group with SSM address, the corresponding first hop router will send Multicast Data Notification message carrying multi cast group address to inform the source system that the source can send data to this multi cast group.

For a specific (S, G) tuple, when the last receiver leaves the multi cast group, the first hop router will send Multicast Data Notification message carrying multi cast group address to inform the source system that the source should stop sending data to this multi cast group.

4.3. Receiver Information Statistics

For certain scenarios, a first hop router can learn receiver statistics for a specific (S, G) tuple. For example, in SDN scenario, the receiver statistics of each egress router can be centrally managed by the controller. The controller then aggregates these statistics and informs the first-hop router.

In this case, if the first hop router has sent Multicast Data Notification message to the source system to inform the source system sending data, the first-hop router should periodically send Multicast Receiver Statistics messages to the source system synchronizing the receiver statistics. In this way, the source system can perform analysis based on the receiver statistics, facilitating further optimization and scaling.

5. Message Formats

There are three types of IGMP and MLD messages associated with multi cast source advertisement described in this document.

5.1. Multicast Source Registration Message

MSR message is sent by multi cast source to request multi cast data transmission service activation or by router responding to the request from the multi cast source.

MSR message has the following format:

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD1,2 |       |E|I|R|A|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Credential Len        |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Multicast Source Address                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Start Timestamp (64 bits)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Duration (32 bits)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           Credential                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           Extension                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 1: MSR Message Format

Type (8 bits): IGMP and MLD messages types, they need to be registered by the IANA.

E(E-bit): E-bit set to 1 to indicate that extension is present in the message. E-bit set to 0 to indicate that extension is not present in the message. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.

I (Identity flag, 1 bit): The I flag set to 1 indicates that the message is sent by multi cast source. The I flag set to 0 indicates that the message is sent by router.

R (Request flag, 1 bit): The R flag set to 1 indicates the request to activate transmission service. The R flag set to 0 indicates revocation of the request.

A (Authentication flag, 1 bit): The A flag set to 1 indicates success of request. The A flag set to 0 indicates failure of request or revocation of the request.

Checksum (16 bits): The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP or MLD message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.

Multicast Source Address (Variable length): contains IPv4 or IPv6 address of the multi cast source requested. If the MSR Message is used in IGMP, the length of the address is 32 bits. If the MSR Message is used in MLD, the length of the address is 128 bits.

Start Timestamp (8 bytes): indicates the start time when the multi cast source can provide data services. Before this time, the multi cast source cannot send data to multi cast groups.

Duration (1 byte): indicates the maximum duration that the multi cast source can provide data services in a valid registration request.

Credential (Variable length): is used for authorization of multi cast sources.

Extension: It is defined and described in [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of TLVs for flexible extension.

5.2. Multicast Data Notification Message

MDN message is sent by router to notify multi cast source to start or stop sending multi cast packets. For different (S, G) tuples, the router needs to send multiple MDN messages.

MDN message has the following format:

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD3,4 |  Reserved |E|C|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Multicast Group Address                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           Extension                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 2: MDN Message Format

Type (8 bits): IGMP and MLD messages types, they need to be registered by the IANA.

E(E-bit): E-bit set to 1 to indicate that extension is present in the message. E-bit set to 0 to indicate that extension is not present in the message. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.

C (Control flag, 1 bit): The C flag set to 1 indicates starting sending multi cast packets. The C flag set to 0 indicates stopping sending multi cast packets.

Checksum (16 bits): The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP/MLD message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.

Multicast Group Address (Variable length): contains IPv4 or IPv6 address of the multi cast group requested. If the MDN message is used in IGMP, the length of the address is 32 bits. If the MDN message is used in MLD, the length of the address is 128 bits.

5.3. Multicast Receiver Statistics Message

MRS message is sent by router to multi cast source to synchronize receiver statistics of a group. For different (S, G) tuples, the router needs to send multiple MRS messages.

MRS message has the following format:

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD5,6 |   Reserved  |E|           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Multicast Group Address                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Receivers                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           Extension                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 3: MRS Message Format

Type (8 bits): IGMP and MLD messages types, they need to be registered by the IANA.

E(E-bit): E-bit set to 1 to indicate that extension is present in the message. E-bit set to 0 to indicate that extension is not present in the message. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.

Checksum (16 bits): The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP/MLD message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.

Multicast Group Address (Variable length): contains IPv4 or IPv6 address of the multi cast group requested. If the MRS message is used in IGMP, the length of the address is 32 bits. If the MRS message is used in MLD, the length of the address is 128 bits.

Number of Receivers (32 bits): indicates the number of receivers for a particular (S,G) tuple

6. Use Case

6.1. Multicast Management for PCE as multicast controller

This section briefly describes procedures of multi cast source management through a simple example of Path Computation Element(PCE) based Bit Index Explicit Replication(BIER).

The specific implementation process is as follows:

                         +------------------+
                 +-------+    Controller    +-------+
                 |       +--------^---------+       |
                 |                                  |
                 |                                  |
              S2 | S3/7       +--------+            |  S6
                 |    --------+   R3   +--------    |
                 |   /        +--------+        \   |
                 |  /                            \  |
+------+  S1/9  +--+  S11  +--+          +--+     +--+  S5 +--------+
|Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver|
+------+ S4/8/10+--+       +--+          +--+     +--+     +--------+
                 |                                  |
                 |         +--+          +--+       |
                 +---------+R2+----------+R4+-------+
                           +--+          +--+
 Figure 4: Topology of multi cast source management for PCE based BIER

For the solution of PCE based BIER, the transmission of multi cast source registration and authorization and receiver information statistics depends on the PCRpt message and PCUpd message, defined in [RFC8231] and extended in [I-D.li-pce-multicast], between the router and the controller.

S1, S4, S8 and S10 in the figure are multi cast source advertisement related processes. S1 is the process by which multi cast sources send messages and data to router. S4, S8 and S10 are the process by which router send messages to multi cast sources. The other steps are beyond the scope of this document.

Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to activate the multi cast data transmission service.

Step 2(S2): R1 sends multi cast information registration to controller via PCRpt message.

Step 3(S3): The controller sends PCUpd message to the R1, carrying authentication result.

Step 4(S4): R1 sends authentication result to the source via IGMP or MLD MSR message. Source will conduct subsequent processing based on the authentication result, such as reapplying after the failure of authentication.

Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to join or leave a multi cast group.

Step 6(S6): R7 converts the IGMP or MLD messages of receivers into PCRpt message and send it to the controller.

Step 7(S7): The controller sends PCUpd message to R1 to start or stop forwarding, carrying BitString.

Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify the source sending multi cast packets to the specific multi cast group.

Step 9(S9): Source sends multicast data to R1.

Step 10(S10): R1 sends IGMP or MLD MSR messages with multi cast receivers' statistics to the source periodically.

7. Deployment Considerations

8. Security Considerations

9. IANA Considerations

9.1. IGMP Type Numbers

IANA is requested to allocate a new code point within registry "IGMP Type Numbers" under "Internet Group Management Protocol (IGMP) Type Numbers" as follows:

 Type Number               Message Name
-------------     -----------------------------
    TBD1           Multicast Source Activation
    TBD3           Multicast Data Notification
    TBD5          Multicast Receiver Statistics

9.2. ICMPv6 Parameters

IANA is requested to allocate a new code point within registry "ICMPv6 "type" Numbers" under "Internet Control Message Protocol version 6 (ICMPv6) Parameters" as follows:

 Type Number               Message Name
-------------     -----------------------------
    TBD2           Multicast Source Activation
    TBD4           Multicast Data Notification
    TBD6          Multicast Receiver Statistics

10. Contributor

11. Acknowledgement

12. Normative References

[I-D.ietf-pim-igmp-mld-extension]
Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda, "Internet Group Management Protocol version 3 (IGMPv3) and Multicast Listener Discovery version 2 (MLDv2) Message Extension", Work in Progress, Internet-Draft, draft-ietf-pim-igmp-mld-extension-07, , <https://www.ietf.org/archive/id/draft-ietf-pim-igmp-mld-extension-07.txt>.
[I-D.li-pce-multicast]
Li, H., Wang, A., Zhang, Z., Chen, H., and R. Chen, "Multicast Tree Setup via PCEP", Work in Progress, Internet-Draft, draft-li-pce-multicast-01, , <https://www.ietf.org/archive/id/draft-li-pce-multicast-01.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3376]
Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, , <https://www.rfc-editor.org/info/rfc3376>.
[RFC3810]
Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, , <https://www.rfc-editor.org/info/rfc3810>.
[RFC4601]
Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, , <https://www.rfc-editor.org/info/rfc4601>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, , <https://www.rfc-editor.org/info/rfc8231>.

Authors' Addresses

Huanan Li
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
United States of America

mirror server hosted at Truenetwork, Russian Federation.