[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
PIM Working Group                                                  H. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: January 10, 2022                                   July 9, 2021


           IGMP/MLD Extension for Multicast Source Management
          draft-li-pim-igmp-mld-extension-source-management-00

Abstract

   This document describes extensions to Internet Group Management
   Protocol(IGMP) and Multicast Listener Discover(MLD) protocols for
   supporting interaction between multicast sources and routers,
   accomplishing multicast 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 January 10, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Li & Wang               Expires January 10, 2022                [Page 1]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Overview of Multicast Source Management . . . . . . . . . . .   3
     4.1.  Topology of multicast source advertisement for PCE based
           BIER  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Multicast Source Registration Message . . . . . . . . . .   5
     5.2.  Multicast Data Notification message . . . . . . . . . . .   7
     5.3.  Multicast Receiver Status message . . . . . . . . . . . .   8
   6.  Deployment Considerations . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  IGMP Type Numbers . . . . . . . . . . . . . . . . . . . .   9
     8.2.  ICMPv6 Parameters . . . . . . . . . . . . . . . . . . . .   9
   9.  Contributor . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   9
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Among protocols for Internet Protocol(IP) multicast, there is no
   interaction protocol between multicast sources and routers so far.
   This document spceifies 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 multicast management process
   described in [I-D.li-pce-based-bier], the transmission of multicast
   source data can be effectively controlled, enhancing the security and
   controllability of the multicast 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:

   o  BIER: Bit Index Explicit Replication



Li & Wang               Expires January 10, 2022                [Page 2]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   o  ICMPv6: Internet Control Message Protocol version 6

   o  IGMP: Internet Group Management Protocol

   o  IP: Internet Protocol

   o  MDN: Multicast Data Notification

   o  MLD: Multicast Listener Discover

   o  MRS: Multicast Receiver Status

   o  MSR: Multicast Source Registration

   o  PCE: Path Computation Element

   o  RP: Rendezvous Point

4.  Overview of Multicast Source Management

   Multicast source management includes multicast source registration
   and authorization, multicast data transmission and termination, and
   receiver information statistics.

   This section briefly describes procedures of multicast source
   management through a simple example of Path Computation Element(PCE)
   based Bit Index Explicit Replication(BIER) described in extended in
   [I-D.li-pce-based-bier].

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

4.1.  Topology of multicast source advertisement for PCE based BIER

   The specific implementation process is as follows:













Li & Wang               Expires January 10, 2022                [Page 3]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


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

4.2.  Procedures

   For PCE based BIER, the transmission of multicast 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-based-bier], between the router and the controller.

   S1, S4, S8 and S10 in the figure are multicast source advertisement
   related processes.  S1 is the process by which multicast sources send
   messages and data to router.  S4, S8 and S10 are the process by which
   router send messages to multicast 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 multicast data transmission service.

   Step 2(S2) : R1 sends multicast 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 multicast group.




Li & Wang               Expires January 10, 2022                [Page 4]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   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 multicast packets to the specific multicast group.

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

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

5.  Message Formats

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

5.1.  Multicast Source Registration Message

   MSR message is sent by multicast source to request multicast data
   transmission service activation or by router responding to the
   request from the multicast source.  For a multicast source, it only
   needs to send MSR message once in the valid time.

   MSR message has the following format:
























Li & Wang               Expires January 10, 2022                [Page 5]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Type  | Credential Len|            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Source Address                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Credential                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Start Timestamp (64 bits)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     End Timestamp (64 bits)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                            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 multicast 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.




Li & Wang               Expires January 10, 2022                [Page 6]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   Address Type(8 bits): indicates the type of the source address.
   Address Type = 1: IPv4 address.  Address Type = 2: IPv6 address.

   Credential Len(8 bits): indicates the length of Credential.

   Multicast Source Address(Variable length): contains IPv4 or IPv6
   address of the multicast source requested.

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

   Start Timestamp(8 bytes): indicates the start time of the
   registration.

   End Timestamp(8 bytes): indicates the end time of the registration.

   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.

   Reserved: The Reserved fields are set to zero on transmission, and
   ignored on reception.

5.2.  Multicast Data Notification message

   MDN message is sent by router to notify multicast source to start or
   stop sending multicast 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  |C|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Type  |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Group Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 2: MDN Message Format


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






Li & Wang               Expires January 10, 2022                [Page 7]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   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 multicast 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.

   Address Type(8 bits): indicates the type of the source address.
   Address Type = 1: IPv4 address.  Address Type = 2: IPv6 address.

   Multicast Group Address(Variable length): contains IPv4 or IPv6
   address of the multicast group requested.

   Reserved: The Reserved fields are set to zero on transmission, and
   ignored on reception.

5.3.  Multicast Receiver Status message

   MRS message is sent by router to multicast 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 | Address Type  |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Multicast Group Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Number of Receivers                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 3: MRS Message Format


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

   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.




Li & Wang               Expires January 10, 2022                [Page 8]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   Address Type(8 bits): indicates the type of the source address.
   Address Type = 1: IPv4 address.  Address Type = 2: IPv6 address.

   Multicast Group Address(Variable length): contains IPv4 or IPv6
   address of the multicast group requested.

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

6.  Deployment Considerations

7.  Security Considerations

8.  IANA Considerations

8.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 Status

8.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 Status

9.  Contributor

10.  Acknowledgement

11.  Normative References







Li & Wang               Expires January 10, 2022                [Page 9]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   [I-D.ietf-pim-igmp-mld-extension]
              Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
              "IGMPv3/MLDv2 Message Extension", draft-ietf-pim-igmp-mld-
              extension-04 (work in progress), January 2021.

   [I-D.li-pce-based-bier]
              Li, H., Wang, A., Chen, H., and R. Chen, "PCE based BIER
              Procedures and Protocol Extensions", draft-li-pce-based-
              bier-00 (work in progress), June 2021.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, October 2002,
              <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, June 2004,
              <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, August 2006,
              <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,
              May 2017, <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, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

Authors' Addresses









Li & Wang               Expires January 10, 2022               [Page 10]


Internet-DraIGMP/MLD Extension for Multicast Source Managemen  July 2021


   Huanan Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing, Beijing  102209
   China

   Email: lihn6@foxmail.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing, Beijing  102209
   China

   Email: wangaj3@chinatelecom.cn



































Li & Wang               Expires January 10, 2022               [Page 11]