PIM Working Group L. Contreras Internet-Draft Telefonica Intended status: Standards Track H. Asaeda Expires: 24 April 2025 NICT 21 October 2024 Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies draft-contreras-pim-multiif-config-02 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 24 April 2025. Copyright Notice Copyright (c) 2024 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 24 April 2025 [Page 1] Internet-Draft Multiple upstream interfaces config October 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Report message extensions . . . . . . . . . . . . . . . . 6 6.1.1. Multicast channel/source information retrieval per upstream interface . . . . . . . . . . . . . . . . . 6 6.1.2. Request of channel/source from one or more upstream interfaces . . . . . . . . . . . . . . . . . . . . . 6 6.2. Query message extensions . . . . . . . . . . . . . . . . 8 6.2.1. Response for information retrieval of upstream interface(s) and associated sources for a session/ channel . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2. Maintenance of multicast membership on the downstream interfaces including information of the upstream interface used . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction An IGMP/MLD proxy with multiple upstream interfaces, as described in [I-D.ietf-pim-multipath-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.ietf-pim-multipath-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 24 April 2025 [Page 2] Internet-Draft Multiple upstream interfaces config October 2024 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.ietf-pim-multipath-igmpmldproxy] are also used in this document. 3. IGMP/MLD proxy with multiple upstream interfaces [I-D.ietf-pim-multipath-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". (Note: feasibility of subscriber verification is under analysis and will be described / referenced in future versions of this document). 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. (Note: feasibility of subscriber verification is under analysis and will be described / referenced in future versions of this document). * Associate the request of specific content delivered from a specific source, i.e. (S,G), to a specific upstream interface Contreras & Asaeda Expires 24 April 2025 [Page 3] Internet-Draft Multiple upstream interfaces config October 2024 * 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 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 information retrieval 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 information retrieval, the initial information retrieval 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. Contreras & Asaeda Expires 24 April 2025 [Page 4] Internet-Draft Multiple upstream interfaces config October 2024 +---------+ +---------+ | Proxy | | Host | +---------+ +---------+ | | | Report extension | |<------------------------| | (Section 6.1.1) | | | | | | Query extension | |------------------------>| | (Section 6.2.1) | | | | | The request of a channel from one or more upstream interfaces will be encoded in a report message. +---------+ +---------+ | Proxy | | Host | +---------+ +---------+ | | | Report extension | |<------------------------| | (Section 6.1.2) | | | | | Finally, the information of the multicast upstream used for a channel and a number of sources will be provided using a Query message. +---------+ +---------+ | Proxy | | Host | +---------+ +---------+ | | | Query extension | |------------------------>| | (Section 6.2.2) | | | | | 6. Extensions The following are the extensions proposed for supporting the signaling situations described above, using specific TLVs in aacordance with [RFC9279]. Contreras & Asaeda Expires 24 April 2025 [Page 5] Internet-Draft Multiple upstream interfaces config October 2024 The extensions are generic. Differences for MLD and IGMP will be described explicitly when necessary. 6.1. Report message extensions 6.1.1. Multicast channel/source information retrieval 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 information retrieval 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Info. Retrieval Req. Type | Info. Retrieval Req. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Information Retrieval Request Type: 2 octets. The type of the Information Retrieval Request TLV extension is TBD-1. * Information Retrieval 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. Contreras & Asaeda Expires 24 April 2025 [Page 6] Internet-Draft Multiple upstream interfaces config October 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record index =1 |M|R| Simult If |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record index =J |M|R| Simult If |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [K] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where * Record index enumerates either the Multicast Address Record stated in the conventional MLD Report message, or the Group Record in the IGMP Report one. Contreras & Asaeda Expires 24 April 2025 [Page 7] Internet-Draft Multiple upstream interfaces config October 2024 * 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. * 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 information retrieval of upstream interface(s) and associated sources for a session/channel The extended Query message including response for information retrieval extension will provide information to the host about the upstream interfaces and associated sources for multicast address groups included in the request of information retrieval 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Info. Retrieval Resp. Type | Info. Retrieval Resp. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Retrieval Response Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Information Retrieval Response Type: 2 octets. The type of the Information Retrieval Request TLV extension is TBD-3. * Information Retrieval Request Length: 2 octets. This field specifies the total length in octets of the TLV. Contreras & Asaeda Expires 24 April 2025 [Page 8] Internet-Draft Multiple upstream interfaces config October 2024 * Information Retrieval Response 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address index = 1 | Reserved |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address index = J | Reserved |List of Ups If | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface index [K] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where * The Source Address index enumerates the Source Addresses contained on either the conventional MLD Query message for the Multicast Address identified by the index, or, equivalently, the conventional IGMP Query message for the Group Address corresponding to that index. * 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]. Contreras & Asaeda Expires 24 April 2025 [Page 9] Internet-Draft Multiple upstream interfaces config October 2024 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. 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 Information Retrieval 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 Information Retrieval Response case. 7. Security Considerations The Security Considerations of [RFC3376], [RFC3810] and [RFC9279] also apply here. Apart from that, the following considerations have to be taken into account: * Malicious applications could request content from multiple available interfaces so to saturate the network links. * The frequency of the signaling messages, or the number of TLVs on them, could be maliciously high impacting the processing capability of the IGMP/MLD proxy. All of this could magnify a denial-of-service attack. 8. IANA Considerations [RFC9279] describes the IANA registry for "IGMP/MLD Extension Types". The extensions in this document are stated in the following table. Contreras & Asaeda Expires 24 April 2025 [Page 10] Internet-Draft Multiple upstream interfaces config October 2024 +===========+==========+============================+===========+ | Ext. Type | Length | Name | Reference | +===========+==========+============================+===========+ | TBD-1 | 32-bit | Info. Retrieval Request | RFC XXXX | +-----------+----------+----------------------------+-----------+ | TBD-2 | variable | Request from Upstream If | RFC XXXX | +-----------+----------+----------------------------+-----------+ | TBD-3 | variable | Info. Retrieval 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 [I-D.ietf-pim-multipath-igmpmldproxy] Asaeda, H. and L. M. Contreras, "Multipath Support for IGMP/MLD Proxy", Work in Progress, Internet-Draft, draft- ietf-pim-multipath-igmpmldproxy-01, 21 October 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [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, . Contreras & Asaeda Expires 24 April 2025 [Page 11] Internet-Draft Multiple upstream interfaces config October 2024 Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Hitoshi Asaeda NICT Email: asaeda@nict.go.jp Contreras & Asaeda Expires 24 April 2025 [Page 12]