< draft-li-pim-igmp-mld-extension-source-management-02.txt   draft-li-pim-igmp-mld-extension-source-management-03.txt >
PIM Working Group H. Li PIM Working Group H. Li
Internet-Draft A. Wang Internet-Draft A. Wang
Intended status: Standards Track China Telecom Intended status: Standards Track China Telecom
Expires: 11 May 2022 S. Venaas Expires: 17 November 2022 S. Venaas
Cisco Systems Cisco Systems
7 November 2021 16 May 2022
IGMP/MLD Extension for Multicast Source Management IGMP/MLD Extension for Multicast Source Management
draft-li-pim-igmp-mld-extension-source-management-02 draft-li-pim-igmp-mld-extension-source-management-03
Abstract Abstract
This document describes extensions to Internet Group Management This document describes extensions to Internet Group Management
Protocol (IGMP) and Multicast Listener Discover (MLD) protocols for Protocol (IGMP) and Multicast Listener Discover (MLD) protocol for
supporting interaction between multicast sources and routers, supporting interaction between multi cast sources and routers,
accomplishing multicast source management. accomplishing multi cast source management.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 May 2022. This Internet-Draft will expire on 17 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Multicast Source Management . . . . . . . . . . . 3 4. Overview of Multicast Source Management . . . . . . . . . . . 3
4.1. Multicast Source Registration and Authorization . . . . . 4 4.1. Multicast Source Registration and Authorization . . . . . 4
4.2. Multicast Data Transmission and Termination . . . . . . . 4 4.2. Multicast Data Transmission and Termination . . . . . . . 4
4.3. Receiver Information Statistics . . . . . . . . . . . . . 5 4.3. Receiver Information Statistics . . . . . . . . . . . . . 5
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Multicast Source Registration Message . . . . . . . . . . 5 5.1. Multicast Source Registration Message . . . . . . . . . . 5
5.2. Multicast Data Notification Message . . . . . . . . . . . 7 5.2. Multicast Data Notification Message . . . . . . . . . . . 7
5.3. Multicast Receiver Statistics Message . . . . . . . . . . 7 5.3. Multicast Receiver Statistics Message . . . . . . . . . . 8
6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Multicast Source Management for PCE based BIER . . . . . 8 6.1. Multicast Management for PCE as multicast controller . . 9
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . 10 9.1. IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . 11
9.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . . 10 9.2. ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . . 11
10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
12. Normative References . . . . . . . . . . . . . . . . . . . . 11 12. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Among protocols for Internet Protocol (IP) multicast, there is no Among protocols for Internet Protocol (IP) multicast, there is no
protocol specification for the source registration so far. The protocol specification for the source registration so far. The
current protocol focuses more on data control. This document current protocol focuses more on data control. This document
specifies some new messages to extend IGMPv3 [RFC3376] and MLDv2 specifies some new messages to extend IGMPv3 [RFC3376] and MLDv2
[RFC3810] for exchanging source registration information and data [RFC3810] for exchanging source registration information and data
transmission control information between sources and routers. transmission control information between sources and routers.
In addition, combined with the multicast management process based on In addition, combined with the multi cast management process based on
SDN architecture described in [I-D.li-pce-based-bier], the Soft Dedfined Network (SDN) architecture, such as that described in
transmission of multicast source data can be effectively controlled, [I-D.li-pce-multicast], the transmission of multi cast source data
enhancing the security and controllability of the multicast service. can be effectively managed, enhancing the security and
controllability of the multi cast service.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 3, line 33 skipping to change at page 3, line 33
* MSR: Multicast Source Registration * MSR: Multicast Source Registration
* PCE: Path Computation Element * PCE: Path Computation Element
* RP: Rendezvous Point * RP: Rendezvous Point
* SDN: Software Defined Network * SDN: Software Defined Network
4. Overview of Multicast Source Management 4. Overview of Multicast Source Management
Multicast source management includes multicast source registration Multicast source management includes multi cast source registration
and authorization, multicast data transmission and termination, and and authorization, multi cast data transmission and termination, and
receiver information statistics. Currently, multicast source receiver information statistics. Currently, multi cast source
management is mainly used in Source Specific Multicast (SSM) management is mainly used in Source Specific Multicast (SSM)
scenario. If multicast source management is to be applied to Any- scenario. If multi cast source management is to be applied to Any-
Source Multicast (ASM) scenarios, other mechanisms are needed. ASM Source Multicast (ASM) scenarios, other mechanisms are needed. ASM
scenario is not discussed in this document. scenario is not discussed in this document.
This document specifies IGMP and MLD protocol extensions for This document specifies IGMP and MLD protocol extensions for multi
multicast source management, including Multicast Source Registration cast source management, including Multicast Source Registration (MSR)
(MSR) described in Section 5.1, Multicast Data Notification (MDN) described in Section 5.1, Multicast Data Notification (MDN) described
described in Section 5.2 and Multicast Receiver Statistics (MRS) in Section 5.2 and Multicast Receiver Statistics (MRS) described in
described in Section 5.3. Section 5.3.
4.1. Multicast Source Registration and Authorization 4.1. Multicast Source Registration and Authorization
Source systems send Multicast Source Registration messages to routers Source systems send Multicast Source Registration messages to routers
informing them that there are multicast sources available to provide informing them that there are multi cast sources available to provide
services. The Multicast Source Registration message must contain the services. The Multicast Source Registration message must contain the
multicast source address, service start time and validity period of multi cast source address, service start time and validity period of
the request. In some scenarios, The Multicast Source Registration the request. In some scenarios, The Multicast Source Registration
message also needs to contain credential for controlling multicast message also needs to contain credential for controlling multi cast
source access. 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 After receiving the registration message from the source system and
authenticating, the routers send Multicast Source Registration authenticating, the routers send Multicast Source Registration
messages with valid registration status response to the source messages with valid registration status response to the source
systems and inform the source systems that the requests are approved. systems and inform the source systems that the requests are approved.
The routers will trigger a timer and maintain the registration status The routers will trigger a timer and maintain the registration status
for the source systems until the timer expires. for the source systems until the timer expires.
In contrast, the source systems can also send Multicast Source In contrast, the source systems can also send Multicast Source
Registration messages to routers to withdraw the registration Registration messages to routers to withdraw the registration
requests. Then the routers will revoke the registration status and requests. Then the routers will revoke the registration status and
reply to the source systems. reply to the source systems.
The source systems need periodically send registration messages to The source systems need periodically send registration messages to
the routers to inform the router that the multicast source is alive. the routers to inform the router that the multi cast source is alive.
Then routers will refresh the timer of the registration status. If Then routers will refresh the timer of the registration status. If
routers receive multicast data from multicast sources, they will routers receive multi cast data from multi cast sources, they will
refresh the timer. During data delivery, the source systems does not refresh the timer. During data delivery, the source systems does not
have to send registration messages periodically. have to send registration messages periodically.
When the timer expires or the registration validity period expires, When the timer expires or the registration validity period expires,
the router will release the registration status and send a Multicast the router will release the registration status and send a Multicast
Source Registration message with invalid registration status to the Source Registration message with invalid registration status to the
source system to inform it. source system to inform it.
4.2. Multicast Data Transmission and Termination 4.2. Multicast Data Transmission and Termination
Within the service validity of registration, when the first receiver Within the service validity of registration, when the first receiver
joins a multicast group with SSM address and requests to receive data joins a multi cast group with SSM address, the corresponding first
from a specific multicast source, the first hop router will send hop router will send Multicast Data Notification message carrying
Multicast Data Notification message carrying multicast group address multi cast group address to inform the source system that the source
to inform the source system that the source can send data to this can send data to this multi cast group.
multicast group.
For a specific (S, G) tuple, when the last receiver leaves the For a specific (S, G) tuple, when the last receiver leaves the multi
multicast group, the first hop router will send Multicast Data cast group, the first hop router will send Multicast Data
Notification message carrying multicast group address to inform the Notification message carrying multi cast group address to inform the
source system that the source should stop sending data to this source system that the source should stop sending data to this multi
multicast group. cast group.
4.3. Receiver Information Statistics 4.3. Receiver Information Statistics
For certain scenarios, a first hop router can learn receiver For certain scenarios, a first hop router can learn receiver
statistics for a specific (S, G) tuple. For example, in SDN statistics for a specific (S, G) tuple. For example, in SDN
scenario, the receiver statistics of each egress router can be scenario, the receiver statistics of each egress router can be
centrally managed by the controller. The controller then aggregates centrally managed by the controller. The controller then aggregates
these statistics and informs the first-hop router. these statistics and informs the first-hop router.
In this case, if the first hop router has sent Multicast Data In this case, if the first hop router has sent Multicast Data
Notification message to the source system to inform the source system Notification message to the source system to inform the source system
sending data, the first-hop router should periodically send Multicast sending data, the first-hop router should periodically send Multicast
Receiver Statistics messages to the source system synchronizing the Receiver Statistics messages to the source system synchronizing the
receiver statistics. In this way, the source system can perform receiver statistics. In this way, the source system can perform
analysis based on the receiver statistics, facilitating further analysis based on the receiver statistics, facilitating further
optimization and scaling. optimization and scaling.
5. Message Formats 5. Message Formats
There are three types of IGMP and MLD messages associated with There are three types of IGMP and MLD messages associated with multi
multicast source advertisement described in this document. cast source advertisement described in this document.
5.1. Multicast Source Registration Message 5.1. Multicast Source Registration Message
MSR message is sent by multicast source to request multicast data MSR message is sent by multi cast source to request multi cast data
transmission service activation or by router responding to the transmission service activation or by router responding to the
request from the multicast source. request from the multi cast source.
MSR message has the following format: MSR message has the following format:
0 1 2 3 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 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 | | Type = TBD1,2 | |E|I|R|A| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential Len | Reserved | | Credential Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 14 skipping to change at page 6, line 34
Type (8 bits): IGMP and MLD messages types, they need to be Type (8 bits): IGMP and MLD messages types, they need to be
registered by the IANA. registered by the IANA.
E(E-bit): E-bit set to 1 to indicate that extension is present in the 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 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 the message. The E-bit MUST be set to 1 to indicate that the
extension is present. Otherwise, it MUST be 0. extension is present. Otherwise, it MUST be 0.
I (Identity flag, 1 bit): The I flag set to 1 indicates that the I (Identity flag, 1 bit): The I flag set to 1 indicates that the
message is sent by multicast source. The I flag set to 0 indicates message is sent by multi cast source. The I flag set to 0 indicates
that the message is sent by router. that the message is sent by router.
R (Request flag, 1 bit): The R flag set to 1 indicates the request to 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 activate transmission service. The R flag set to 0 indicates
revocation of the request. revocation of the request.
A (Authentication flag, 1 bit): The A flag set to 1 indicates success 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 of request. The A flag set to 0 indicates failure of request or
revocation of the request. revocation of the request.
Checksum (16 bits): The Checksum is the 16-bit one's complement of 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 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 IP payload). For computing the checksum, the Checksum field is set
to zero. When receiving packets, the checksum MUST be verified to zero. When receiving packets, the checksum MUST be verified
before processing a message. before processing a message.
Multicast Source Address (Variable length): contains IPv4 or IPv6 Multicast Source Address (Variable length): contains IPv4 or IPv6
address of the multicast source requested. If the MSR Message is 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 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. Message is used in MLD, the length of the address is 128 bits.
Start Timestamp (8 bytes): indicates the start time when the Start Timestamp (8 bytes): indicates the start time when the multi
multicast source can provide data services. Before this time, the cast source can provide data services. Before this time, the multi
multicast source cannot send data to multicast groups. cast source cannot send data to multi cast groups.
Duration (1 byte): indicates the maximum duration that the multicast Duration (1 byte): indicates the maximum duration that the multi cast
source can provide data services in a valid registration request. source can provide data services in a valid registration request.
Credential (Variable length): is used for authorization of multicast Credential (Variable length): is used for authorization of multi cast
sources. sources.
Extension: It is defined and described in Extension: It is defined and described in
[I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of [I-D.ietf-pim-igmp-mld-extension].It may contain a variable number of
TLVs for flexible extension. TLVs for flexible extension.
5.2. Multicast Data Notification Message 5.2. Multicast Data Notification Message
MDN message is sent by router to notify multicast source to start or MDN message is sent by router to notify multi cast source to start or
stop sending multicast packets. For different (S, G) tuples, the stop sending multi cast packets. For different (S, G) tuples, the
router needs to send multiple MDN messages. router needs to send multiple MDN messages.
MDN message has the following format: MDN message has the following format:
0 1 2 3 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 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 |C| Checksum | | Type = TBD3,4 | Reserved |E|C| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast Group Address ~ ~ Multicast Group Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extension ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MDN Message Format Figure 2: MDN Message Format
Type (8 bits): IGMP and MLD messages types, they need to be Type (8 bits): IGMP and MLD messages types, they need to be
registered by the IANA. 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 C (Control flag, 1 bit): The C flag set to 1 indicates starting
sending multicast packets. The C flag set to 0 indicates stopping sending multi cast packets. The C flag set to 0 indicates stopping
sending multicast packets. sending multi cast packets.
Checksum (16 bits): The Checksum is the 16-bit one's complement of 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 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 payload). For computing the checksum, the Checksum field is set to
zero. When receiving packets, the checksum MUST be verified before zero. When receiving packets, the checksum MUST be verified before
processing a message. processing a message.
Multicast Group Address (Variable length): contains IPv4 or IPv6 Multicast Group Address (Variable length): contains IPv4 or IPv6
address of the multicast group requested. If the MDN message is used address of the multi cast group requested. If the MDN message is
in IGMP, the length of the address is 32 bits. If the MDN message is used in IGMP, the length of the address is 32 bits. If the MDN
used in MLD, the length of the address is 128 bits. message is used in MLD, the length of the address is 128 bits.
5.3. Multicast Receiver Statistics Message 5.3. Multicast Receiver Statistics Message
MRS message is sent by router to multicast source to synchronize MRS message is sent by router to multi cast source to synchronize
receiver statistics of a group. For different (S, G) tuples, the receiver statistics of a group. For different (S, G) tuples, the
router needs to send multiple MRS messages. router needs to send multiple MRS messages.
MRS message has the following format: MRS message has the following format:
0 1 2 3 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 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 | Checksum | | Type = TBD5,6 | Reserved |E| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast Group Address ~ ~ Multicast Group Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Receivers | | Number of Receivers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extension ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MRS Message Format Figure 3: MRS Message Format
Type (8 bits): IGMP and MLD messages types, they need to be Type (8 bits): IGMP and MLD messages types, they need to be
registered by the IANA. 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 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 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 payload). For computing the checksum, the Checksum field is set to
zero. When receiving packets, the checksum MUST be verified before zero. When receiving packets, the checksum MUST be verified before
processing a message. processing a message.
Multicast Group Address (Variable length): contains IPv4 or IPv6 Multicast Group Address (Variable length): contains IPv4 or IPv6
address of the multicast group requested. If the MRS message is used address of the multi cast group requested. If the MRS message is
in IGMP, the length of the address is 32 bits. If the MRS message is used in IGMP, the length of the address is 32 bits. If the MRS
used in MLD, the length of the address is 128 bits. message is used in MLD, the length of the address is 128 bits.
Number of Receivers (32 bits): indicates the number of receivers for Number of Receivers (32 bits): indicates the number of receivers for
a particular (S,G) tuple. a particular (S,G) tuple
6. Use Case 6. Use Case
6.1. Multicast Source Management for PCE based BIER 6.1. Multicast Management for PCE as multicast controller
This section briefly describes procedures of multicast source This section briefly describes procedures of multi cast source
management through a simple example of Path Computation Element(PCE) management through a simple example of Path Computation Element(PCE)
based Bit Index Explicit Replication(BIER) described in extended in based Bit Index Explicit Replication(BIER).
[I-D.li-pce-based-bier].
The specific implementation process is as follows: The specific implementation process is as follows:
+------------------+ +------------------+
+-------+ Controller +-------+ +-------+ Controller +-------+
| +--------^---------+ | | +--------^---------+ |
| | | |
| | | |
S2 | S3/7 +--------+ | S6 S2 | S3/7 +--------+ | S6
| --------+ R3 +-------- | | --------+ R3 +-------- |
| / +--------+ \ | | / +--------+ \ |
| / \ | | / \ |
+------+ S1/9 +--+ S11 +--+ +--+ +--+ S5 +--------+ +------+ S1/9 +--+ S11 +--+ +--+ +--+ S5 +--------+
|Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver| |Source|--------|R1+-------+R5+----------+R6+-----+R7|-----|Receiver|
+------+ S4/8/10+--+ +--+ +--+ +--+ +--------+ +------+ S4/8/10+--+ +--+ +--+ +--+ +--------+
| | | |
| +--+ +--+ | | +--+ +--+ |
+---------+R2+----------+R4+-------+ +---------+R2+----------+R4+-------+
+--+ +--+ +--+ +--+
Figure 4: Topology of multicast source management for PCE based BIER Figure 4: Topology of multi cast source management for PCE based BIER
For PCE based BIER, the transmission of multicast source registration For the solution of PCE based BIER, the transmission of multi cast
and authorization and receiver information statistics depends on the source registration and authorization and receiver information
PCRpt message and PCUpd message, defined in [RFC8231] and extended in statistics depends on the PCRpt message and PCUpd message, defined in
[I-D.li-pce-based-bier], between the router and the controller. [RFC8231] and extended in [I-D.li-pce-multicast], between the router
and the controller.
S1, S4, S8 and S10 in the figure are multicast source advertisement S1, S4, S8 and S10 in the figure are multi cast source advertisement
related processes. S1 is the process by which multicast sources send related processes. S1 is the process by which multi cast sources
messages and data to router. S4, S8 and S10 are the process by which send messages and data to router. S4, S8 and S10 are the process by
router send messages to multicast sources. The other steps are which router send messages to multi cast sources. The other steps
beyond the scope of this document. are beyond the scope of this document.
Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to Step 1(S1): Source sends IGMP or MLD MSR message to R1 requesting to
activate the multicast data transmission service. activate the multi cast data transmission service.
Step 2(S2): R1 sends multicast information registration to controller Step 2(S2): R1 sends multi cast information registration to
via PCRpt message. controller via PCRpt message.
Step 3(S3): The controller sends PCUpd message to the R1, carrying Step 3(S3): The controller sends PCUpd message to the R1, carrying
authentication result. authentication result.
Step 4(S4): R1 sends authentication result to the source via IGMP or Step 4(S4): R1 sends authentication result to the source via IGMP or
MLD MSR message. Source will conduct subsequent processing based on MLD MSR message. Source will conduct subsequent processing based on
the authentication result, such as reapplying after the failure of the authentication result, such as reapplying after the failure of
authentication. authentication.
Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to Step 5(S5): Receivers send IGMP or MLD messages to R7 requesting to
join or leave a multicast group. join or leave a multi cast group.
Step 6(S6): R7 converts the IGMP or MLD messages of receivers into Step 6(S6): R7 converts the IGMP or MLD messages of receivers into
PCRpt message and send it to the controller. PCRpt message and send it to the controller.
Step 7(S7): The controller sends PCUpd message to R1 to start or stop Step 7(S7): The controller sends PCUpd message to R1 to start or stop
forwarding, carrying BitString. forwarding, carrying BitString.
Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify Step 8(S8): R1 sends IGMP or MLD MDN message to the source to notify
the source sending multicast packets to the specific multicast group. the source sending multi cast packets to the specific multi cast
group.
Step 9(S9): Source sends multicast data to R1. Step 9(S9): Source sends multicast data to R1.
Step 10(S10): R1 sends IGMP or MLD MSR messages with multicast Step 10(S10): R1 sends IGMP or MLD MSR messages with multi cast
receivers' statistics to the source periodically. receivers' statistics to the source periodically.
7. Deployment Considerations 7. Deployment Considerations
8. Security Considerations 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
9.1. IGMP Type Numbers 9.1. IGMP Type Numbers
skipping to change at page 11, line 16 skipping to change at page 12, line 10
11. Acknowledgement 11. Acknowledgement
12. Normative References 12. Normative References
[I-D.ietf-pim-igmp-mld-extension] [I-D.ietf-pim-igmp-mld-extension]
Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda, Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
"Internet Group Management Protocol version 3 (IGMPv3) and "Internet Group Management Protocol version 3 (IGMPv3) and
Multicast Listener Discovery version 2 (MLDv2) Message Multicast Listener Discovery version 2 (MLDv2) Message
Extension", Work in Progress, Internet-Draft, draft-ietf- Extension", Work in Progress, Internet-Draft, draft-ietf-
pim-igmp-mld-extension-05, 7 November 2021, pim-igmp-mld-extension-07, 9 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-pim-igmp-mld- <https://www.ietf.org/archive/id/draft-ietf-pim-igmp-mld-
extension-05.txt>. extension-07.txt>.
[I-D.li-pce-based-bier] [I-D.li-pce-multicast]
Li, H., Wang, A., Chen, H., and R. Chen, "PCE based BIER Li, H., Wang, A., Zhang, Z., Chen, H., and R. Chen,
Procedures and Protocol Extensions", Work in Progress, "Multicast Tree Setup via PCEP", Work in Progress,
Internet-Draft, draft-li-pce-based-bier-02, 18 October Internet-Draft, draft-li-pce-multicast-01, 20 March 2022,
2021, <https://www.ietf.org/archive/id/draft-li-pce-based- <https://www.ietf.org/archive/id/draft-li-pce-multicast-
bier-02.txt>. 01.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
 End of changes. 54 change blocks. 
118 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/