PIM Working Group L. Contreras Internet-Draft Telefonica Intended status: Standards Track H. Asaeda Expires: 11 January 2024 NICT 10 July 2023 Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies draft-contreras-pim-multiif-config-00 Abstract The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. 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 11 January 2024. Copyright Notice Copyright (c) 2023 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 Contreras & Asaeda Expires 11 January 2024 [Page 1] Internet-Draft Multiple upstream interfaces config July 2023 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IGMP/MLD proxy with multiple upstream interfaces . . . . . . 3 4. Policies applicable for selecting upstream interfaces . . . . 3 5. Signaling situations . . . . . . . . . . . . . . . . . . . . 4 6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Report message extensions . . . . . . . . . . . . . . . . 5 6.1.1. Multicast channel/source discovery per upstream interface . . . . . . . . . . . . . . . . . . . . . . 5 6.1.2. Request of channel/source from one or more upstream interfaces . . . . . . . . . . . . . . . . . . . . . 5 6.2. Query message extensions . . . . . . . . . . . . . . . . 7 6.2.1. Response for discovery of upstream interface(s) and associated sources for a session/channel . . . . . . 7 6.2.2. Maintenance of multicast membership on the downstream interfaces including information of the upstream interface used . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction An IGMP/MLD proxy with multiple upstream interfaces, as described in [I-D.asaeda-pim-multiif-igmpmldproxy] permits a device to receive multicast sessions/channels through the different upstream interfaces. The selection of a specific upstream interface can be based on multiple criteria, such as the subscriber address prefixes, channel/session IDs, and interface priority values. [I-D.asaeda-pim-multiif-igmpmldproxy] considers two options for the automatic configuration of the upstream interfaces. On one hand, the configuration could be performed by a centralized controller, requiring from the proxy to have some control and management interface to receive configuration instructions from the controller. On the other hand, the configuration could be based in some signaling-based mechasnism by means of IGMP/MLD messages. This document describes the latter, by using the extensions defined in [RFC9279]. Contreras & Asaeda Expires 11 January 2024 [Page 2] Internet-Draft Multiple upstream interfaces config July 2023 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, the terms defined in [I-D.asaeda-pim-multiif-igmpmldproxy] are also used in this document. 3. IGMP/MLD proxy with multiple upstream interfaces [I-D.asaeda-pim-multiif-igmpmldproxy] describes the capabilities of an IGMP/MLD proxy device for receiving multicast sessions/channels through the different upstream interfaces. The proxy could work with either "channel-based upstream selection" or "subscriber-based upstream selection", or even both of them. By channel-based upstream selection, an IGMP/MLD proxy device selects one or multiple upstream interface(s) from the candidate upstream interfaces "per channel/ session". By subscriber-based upstream selection, an IGMP/MLD proxy device selects one or multiple upstream interface(s) from the candidate upstream interfaces "per subscriber/receiver". With the ability of susbcribing to content through different multiple upstream interfaces, the proxy can either balance the load per session/channel, or simulatanously receive the content from more than one multiple upstream interface, providing a robust mechanism of content reception. Then, this situaiton of subscribing to a channel and simultaneously receiving it through more than one upstream interface, should be also supported. 4. Policies applicable for selecting upstream interfaces The support of multiple upstream interfaces allows for defining different policies in the IGMP/MLD proxy at the time of configuring those interfaces. For instance, it can be taken into account the following criteria: * Associate the requests from a specific user to a specific upstream interface * Associate the request of specific content delivered from a specific source, i.e. (S,G), to a specific upstream interface * Associate the request of specific content delivered from any source, i.e. (*,G), to a specific upstream interface * Associate the request of any content delivered from a specific source, i.e. (S,*), to a specific upstream interface Contreras & Asaeda Expires 11 January 2024 [Page 3] Internet-Draft Multiple upstream interfaces config July 2023 These policies are expected to be configured in the proxy to be applied once the signaling messages are exchanged between the proxy and the devices connected to the proxy. 5. Signaling situations There are different situations that require the definition of signaling messages. The situations identified so far are: * Multicast channel/source discovery per upstream interface: in order to allow the request from the host of channel and/or source for specific multiple upstream interfaces, it is necessary to retrieve such information from the proxy in advance. * Multicast channel/source request from one or more upstream interfaces: this is a request from the host indicating candidate upstream interfaces for a content. * Maintenance of multicast membership on the downstream interfaces including information of the upstream interface used per channel and source: this is sent by the proxy to the hosts as a means of informing the upstream interfaces used for the subscribed channels from the indicated sources. [RFC9279] presents extensions for both Report and Query messages. Then the signaling situations above should be encoded as part of Report and Query messages. For the discovery, the initial discovery request from the host to the proxy will be enconded as a Report message, while the answer from the proxy to the host will be done as a Query message. The request of a channel from one or more upstream interfaces will be encoded in a report message. Finally, the information of the multicast upstream used for a channel and a number of sources will be provided using a Query message. 6. Extensions The following are the extensions proposed for supporting the signaling situations described above, using specific TLVs in aacordance with [RFC9279]. Note: in this version the extensions are referred to MLD. Extensions for IGMP will be provided in next versions of this document. Contreras & Asaeda Expires 11 January 2024 [Page 4] Internet-Draft Multiple upstream interfaces config July 2023 6.1. Report message extensions 6.1.1. Multicast channel/source discovery per upstream interface By means of an extended Report message, a host will request to the proxy information about the upstream interface(s) and source(s) providing the multicast addresses indicated in the message. When received by the proxy, this message will trigger a response with the requested information. The multicast content will not be delivered to the host until another Report message not intended for discovery is received. The proposed extension format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Request Type | Discovery Request Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Discovery Request Type: 2 octets. The type of the Discovery Request TLV extension is TBD-1. * Discovery Request Length: 2 octets. This field specifies the total length in octets of the TLV. Since no Value field is considered for this TLV, the length is set to 0. 6.1.2. Request of channel/source from one or more upstream interfaces Using an extended Report message, a host will request to the proxy the subscription to one multicast group indicating the sources and upstream interfaces of interest. When received by the proxy, the host will start receiving the content from one of the indicated sources and from one of the indicated upstream intrfaces. Note: the behavior for the incude / exclude modes will be described in future versions of the document. The proposed extension format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request from Upstream If Type |Request from Upstream If Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request from Upstream Interface Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Contreras & Asaeda Expires 11 January 2024 [Page 5] Internet-Draft Multiple upstream interfaces config July 2023 where * Request from Upstream Interface Type: 2 octets. The type of the Request from Upstream Interface TLV extension is TBD-2. * Request from Upstream Interface Length: 2 octets. This field specifies the total length in octets of the TLV. * Request from Upstream Interface Value: the value of this extension is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Address Record index =1 |M|R| Simult If |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Address Record index =J |M|R| Simult If |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [K] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where * Multicast Address Record index enumerates the Multicast Address Record stated in the conventional MLD Report message. * Mode (M) bit indicates if the multicast content is requested from more than one upstream interface for robust reception. The bit M is set to 0 if the content is requested from one single upstream interface, and 1 if the reception is expected from multiple upstream interfaces simultaneously. * Reserved (R) bit is reserved for future use. Contreras & Asaeda Expires 11 January 2024 [Page 6] Internet-Draft Multiple upstream interfaces config July 2023 * Number of Simultaneaous Upstream Interfaces (Simult If) indicates the number of simultaneous interfaces from where to obtain the multicast flows in case the bit M is set to 1. Otherwise, it will be ignored. * List of Upstream Interfaces indicates the number of candidate upstream interfaces for the multicast address record. This number should be higher or equal to the value in Simult If. Otherwise, the robust reception will be ignored. (Note: to be revisited after further analysis) * Upstream Interface index provides the identifier of the candidate upstream interface. This identifier follows the encoding in [RFC8343]. 6.2. Query message extensions 6.2.1. Response for discovery of upstream interface(s) and associated sources for a session/channel The extended Query message including response for discovery extension will provide information to the host about the upstream interfaces and associated sources for multicast address groups included in the request of discovery message. The proposed extension format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Response Type | Discovery Response Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Response Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Discovery Response Type: 2 octets. The type of the Discovery Request TLV extension is TBD-3. * Discovery Request Length: 2 octets. This field specifies the total length in octets of the TLV. * Discovery Response Value: the value of this extension is encoded as follows: Contreras & Asaeda Expires 11 January 2024 [Page 7] Internet-Draft Multiple upstream interfaces config July 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address index = 1 | Reserved |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address index = 1 | Reserved |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [K] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where * Source Address index enumerates the Source Address Record stated in the conventional MLD Query message for the Multicast Address Group stated there. * Reserved field is reserved for future use. * List of Upstream Interfaces indicates the number of candidate upstream interfaces for the multicast address record. This number should be higher or equal to the value in Simult If. Otherwise, the robust reception will be ignored. (Note: to be revisited after further analysis) * Upstream Interface index provides the identifier of the candidate upstream interface. This identifier follows the encoding in [RFC8343]. 6.2.2. Maintenance of multicast membership on the downstream interfaces including information of the upstream interface used An extended Query message will provide information to the host about the upstream interfaces and associated sources for multicast address groups included in the conventional Query message. The proposed extension format is as follows. Contreras & Asaeda Expires 11 January 2024 [Page 8] Internet-Draft Multiple upstream interfaces config July 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query with Ups Info Type | Query with Ups Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query with Ups Info Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Query with Upstream Interface Information Type: 2 octets. The type of the Discovery Request TLV extension is TBD-4. * Query with Upstream Interface Information Length: 2 octets. This field specifies the total length in octets of the TLV. * Query with Upstream Interface Information Value: the value of this extension is the same as in the Discovery Response case. 7. Security Considerations To be provided. 8. IANA Considerations [RFC9279] describes the IANA registry for "IGMP/MLD Extension Types". The extensions in this document are stated in the following table. +===========+==========+============================+===========+ | Ext. Type | Length | Name | Reference | +===========+==========+============================+===========+ | TBD-1 | 32-bit | Discovery Request | RFC XXXX | +-----------+----------+----------------------------+-----------+ | TBD-2 | variable | Request from Upstream If | RFC XXXX | +-----------+----------+----------------------------+-----------+ | TBD-3 | variable | Discovery Response | RFC XXXX | +-----------+----------+----------------------------+-----------+ | TBD-4 | variable | Query with Ups Info | RFC XXXX | +-----------+----------+----------------------------+-----------+ In case this document progress to become an RFC, RFC XXXX should be substituted by the number assigned to this document. 9. Informative References Contreras & Asaeda Expires 11 January 2024 [Page 9] Internet-Draft Multiple upstream interfaces config July 2023 [I-D.asaeda-pim-multiif-igmpmldproxy] Asaeda, H. and L. M. Contreras, "Multiple Upstream Interface Support for IGMP/MLD Proxy", Work in Progress, Internet-Draft, draft-asaeda-pim-multiif-igmpmldproxy-05, 13 March 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC9279] 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", RFC 9279, DOI 10.17487/RFC9279, August 2022, . Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Hitoshi Asaeda NICT Email: asaeda@nict.go.jp Contreras & Asaeda Expires 11 January 2024 [Page 10]