PIM H. Asaeda Internet-Draft NICT Intended status: Informational L. Contreras Expires: 8 January 2025 Telefonica 7 July 2024 Multipath Support for IGMP/MLD Proxy draft-ietf-pim-multipath-igmpmldproxy-00 Abstract This document describes multipath support for Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as subscriber address prefixes, channel/ session IDs, and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. 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 8 January 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 Asaeda & Contreras Expires 8 January 2025 [Page 1] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 and restrictions with respect to this document. Code Components 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Upstream Selection Mechanism . . . . . . . . . . . . . . . . 5 3.1. Subscriber-Based Upstream Selection . . . . . . . . . . . 5 3.2. Channel-Based Upstream Selection . . . . . . . . . . . . 5 3.3. Multiple Upstream Interface Selection for Robust Data Reception . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Candidate Upstream Interface Configuration . . . . . . . . . 6 4.1. Address Prefix Record . . . . . . . . . . . . . . . . . . 6 4.2. Interface Priority . . . . . . . . . . . . . . . . . . . 8 4.3. Default Upstream Interface . . . . . . . . . . . . . . . 8 5. Upstream Interface Takeover . . . . . . . . . . . . . . . . . 9 5.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 5.2. Active Interval . . . . . . . . . . . . . . . . . . . . . 10 6. Dynamic Upstream Interface Configuration . . . . . . . . . . 10 6.1. Signaling-based Upstream Interface Configuration . . . . 10 6.2. Controller-based Upstream Interface Configuration . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Consideration for Updating YANG Model . . . . . . . . . . . . 11 9. Summary of Aspects Requiring Further Discussion . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Summary of Requirements . . . . . . . . . . . . . . 13 Appendix B. Proof of Concept . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Internet Group Management Protocol (IGMP) [RFC3376][RFC5790] for IPv4 and the Multicast Listener Discovery Protocol (MLD) [RFC3810][RFC5790] for IPv6 are the standard protocols for hosts to initiate the joining or leaving of multicast sessions. A proxy device device that performs IGMP/MLD-based forwarding (as known as IGMP/MLD proxy) [RFC4605] maintains multicast membership information using IGMP/MLD protocols on downstream interfaces and sends IGMP/MLD membership report messages via the upstream interface to upstream multicast routers when the membership information changes (e.g., by receiving solicited/unsolicited report messages). The proxy device Asaeda & Contreras Expires 8 January 2025 [Page 2] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 forwards the appropriate multicast packets received on its upstream interface to each downstream interface based on the subscription of the downstream receiver. According to the specification of [RFC4605], an IGMP/MLD proxy has _a single_ upstream interface and one or more downstream interfaces. The multicast forwarding tree must be configured manually by designating upstream and downstream interfaces on the IGMP/MLD proxy device, and the root of the tree is expected to be connected to a wider multicast infrastructure. Therefore, IGMP/MLD proxy devices perform the router portion of the IGMP or MLD protocol on their downstream interfaces and the host portion of IGMP/MLD on their upstream interface. They must not perform the router portion of IGMP/MLD on the upstream interface. Conversely, there is a scenario in which IGMP/MLD proxy devices enable multiple upstream interfaces and receive multicast packets through these interfaces. For example, a proxy device with more than one interface may want to access different networks, such as a global network such as the Internet and local-scope networks; a proxy device with a wired link (e.g., Ethernet) and high-speed wireless link (e.g., 5G) may want to have the capability to connect to the Internet through both links. These proxy devices receive multicast packets from different upstream interfaces and forward them to the downstream interface(s). The applicability of IGMP/MLD proxies with multiple upstream interfaces in Proxy Mobile IPv6 (PMIPv6) [RFC5213] is described in [RFC6224]. This document describes how IGMP/MLD proxy devices can receive multicast sessions/channels through different upstream interfaces. The upstream interfaces can be configured either with "channel-based upstream selection," "subscriber-based upstream selection," or both. By channel-based upstream selection, IGMP/MLD proxy devices select one or multiple upstream interface(s) from the candidate upstream interfaces "on a per channel/session basis." By subscriber-based upstream selection, IGMP/MLD proxy devices select one or multiple upstream interface(s) from the candidate upstream interfaces "on a per subscriber/receiver basis." Unlike the conventional approach [RFC4605], when a proxy device receives an IGMP/MLD report message on the downstream interface(s), it examines the source and multicast addresses in the records of the IGMP/MLD report message and selects the appropriate upstream interface(s) based on the aforementioned configuration. In general, a proxy device selects "one" upstream interface from the candidate upstream interfaces per session/channel. Furthermore, a proxy device can configure to select "more than two" upstream Asaeda & Contreras Expires 8 January 2025 [Page 3] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 interfaces from the candidate upstream interfaces per session/ channel. In this case, it can receive duplicate (redundant) packets for the session/channel from different upstream interfaces simultaneously, resulting in "robust data reception." A mechanism for "upstream interface takeover" is also described in this document; when the selected upstream interface is going down or the state of the link attached to the upstream interface is inactive, one of the other active candidate upstream interfaces takes over the upstream interface (if configured). The potential timer value for switching from an inactive upstream interface to an active upstream interface from a list of candidate upstream interfaces is described as the default value in this document. Operators may want to change this timer value according to the network conditions or other factors. A "dynamic upstream selection" is a mechanism that selects an appropriate upstream interface(s) for sessions/channels based on the conditions of the network and adjacent routers. It is briefly introduced in this document, whereas its detailed specifications and IGMP/MLD protocol extension are described in [I-D.contreras-pim-multiif-config]. 2. Terminology 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. In addition, the following terms are used in this document. * Selected upstream interface (or simply, upstream interface): The interface of a proxy device in the direction of the root of the multicast forwarding tree. A proxy device performs the host portion of IGMP/MLD on its upstream interface. An upstream interface is selected from a list of candidate upstream interfaces. * Default upstream interface: An upstream interface for multicast sessions/channels for which a proxy device does not select other upstream interfaces. The default upstream interface is configurable. * Active upstream interface: An upstream interface that has been receiving packets for specific multicast sessions/channels during a predefined active interval. Asaeda & Contreras Expires 8 January 2025 [Page 4] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 * Inactive upstream interface: An interface that has not received packets for specific multicast sessions/channels during a predefined active interval. * Downstream interface: An interface that is not in the direction of the root of the multicast forwarding tree. A proxy device performs the router portion of IGMP/MLD on its downstream interfaces. * Candidate upstream interface: An interface that potentially becomes an upstream interface of the proxy device. A list of candidate upstream interfaces is configured with subscriber address prefixes, channel/session IDs, and priority values on an IGMP/MLD proxy device. * Channel/session ID: It consists of source and multicast address prefixes for which a candidate upstream interface is assumed to be an upstream interface for specified multicast sessions/channels. The source or multicast address prefix can be "null". 3. Upstream Selection Mechanism 3.1. Subscriber-Based Upstream Selection "Subscriber-based upstream selection" involves IGMP/MLD proxy devices selecting one or multiple upstream interface(s) from candidate upstream interfaces "per subscriber/receiver." This approach enables proxy devices to use one or multiple upstream interface(s) per session/channel from "candidate upstream interfaces" based on the "subscriber address prefix" configuration. 3.2. Channel-Based Upstream Selection An IGMP/MLD proxy device selects one or multiple upstream interface(s) from candidate upstream interfaces "per channel/session" based on the "channel/session ID" configuration. This mechanism is known as "channel-based upstream selection". This mechanism enables IGMP/MLD proxy devices to use one or multiple upstream interface(s) from candidate upstream interfaces "per channel/session" based on the "channel/session ID" configuration. Asaeda & Contreras Expires 8 January 2025 [Page 5] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 3.3. Multiple Upstream Interface Selection for Robust Data Reception When more than one candidate upstream interface is configured with the same source and multicast addresses for the "channel/session IDs" and "interface priority values" (this will be described in Section 4.2) are identical, these candidate upstream interfaces act as upstream interfaces for the sessions/channels and receive the packets simultaneously. This multiple upstream interface selection approach implements duplicate packet reception from redundant paths. This may improve the data reception quality or robustness of a session/channel, because the same multicast data packets can come from different upstream interfaces simultaneously. However, robust data reception does not guarantee packets coming from disjoint paths. It only configures the adjacent upstream routers to differ. 4. Candidate Upstream Interface Configuration Candidate upstream interfaces are a set of interfaces from which an IGMP/MLD proxy device selects as an upstream interface. The upstream interface selection approach works with the configurations of "subscriber address prefix", "channel/session ID", and "interface priority value." 4.1. Address Prefix Record IGMP/MLD proxy devices can configure the "subscriber address prefix" and "channel/session ID" in the address prefix record for each candidate upstream interface. Channel/session ID consists of "source address prefix" and "multicast address prefix." Subscriber address prefix and source address prefixes MUST be valid unicast address prefixes, and multicast address prefixes MUST be a valid multicast address prefixes. A proxy selects an upstream interface from its candidate upstream interfaces based on the configuration of the following address prefix record: (subscriber address prefix, (channel/session ID)) where the channel/session ID includes the following: (source address prefix, multicast address prefix) Asaeda & Contreras Expires 8 January 2025 [Page 6] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 The default values of these address prefixes are "null." A null subscriber address prefix represents a wildcard subscriber address, which indicates any host. A null source address prefix represents a wildcard source address prefix, which indicates any host. A null multicast address prefix represents a wildcard multicast address prefix, which indicates the entire multicast address range (i.e., 224.0.0.0/4 for IPv4 or ff00::/8 for IPv6). The candidate upstream interface with the configuration of the subscriber address prefix is prioritized. If a specific upstream interface for specific subscribers should be assigned without depending on the source and multicast address prefixes, both the source and multicast addresses in the address prefix record must be configured as "null." The channel/session ID configuration comprises the source and multicast address prefixes. A candidate upstream interface with a non-null source and multicast address configuration is prioritized for upstream interface selection. For example, if a proxy device has two candidate upstream interfaces for the same multicast address prefix G_p but one of them has a non-null source address prefix S_p configuration, that candidate upstream interface is selected for the source and multicast address pair (i.e., (S_p,G_p)). The other candidate upstream interface is selected for the configured multicast address prefix, excluding the source address prefix configured by the prior interface (i.e., (*-S_p,G_p)). The source address prefix configuration is prioritized over the multicast address prefix configuration. For example, consider the case where an IGMP/MLD proxy device has a configuration with the source address prefix S_p for candidate upstream interface A and the multicast address prefix G_p for candidate upstream interface B. When dealing with an IGMP/MLD record whose source address (S) is in the range of S_p and whose multicast address (G) is in the range of G_p, the proxy device selects candidate upstream interface A, which supports the source address prefix, as the upstream interface and transmits the (S,G) record via interface A. In summary, the options for selecting an appropriate upstream interface are as follows: * Association of a subscriber address prefix identified by the source address of the IGMP/MLD message to a specific upstream interface, implying that the multicast traffic for that subscriber is received from a certain upstream interface. This condition is prioritized first. Asaeda & Contreras Expires 8 January 2025 [Page 7] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 * Association of (S,G) to a specific upstream interface, implying that subscriber requests for specific content delivered from a specific source should be received from a certain upstream interface. This condition is prioritized second. * Association of (S,*) to a specific upstream interface, implying that subscriber requests for specific content, independent of the group identifying the content, should be received from a certain upstream interface. This condition is prioritized third. * Association of (*,G) to a specific upstream interface, implying that subscriber requests for specific content, independent of the source of the content, should be received from a certain upstream interface. This condition is prioritized fourth. The same address prefix can be configured on different candidate upstream interfaces. When the same address prefix is configured on different candidate upstream interfaces, an upstream interface for that address prefix is selected on the basis of each interface priority value described in Section 4.2. 4.2. Interface Priority An IGMP/MLD proxy devices can configure the "interface priority" value for each candidate upstream interface. The priority is indicated by an integer value and is part of the configuration. A lower value indicates a lower priority, and the default value of the interface priority is zero. The interface priority value is reflected when neither the subscriber address prefix nor the channel/session ID is configured as the candidate upstream interface or when multiple candidate upstream interfaces configure the same channel/session ID without configuring a subscriber address prefix. In these cases, the candidate upstream interface with the highest priority is selected as the upstream interface. As stated in Section 3.3, if multiple candidate upstream interfaces have the same priority value, they act as upstream interfaces for the configured channel/session ID in parallel and may receive duplicate packets. 4.3. Default Upstream Interface Operators can configure "a default upstream interface" for all incoming sessions/channels in the IGMP/MLD proxy devices. A default upstream interface is used as the upstream interface when candidate upstream interfaces are not configured for the subscriber address prefix, channel/session ID, or interface priority value. A default upstream interface is also used if the proxy device detects Asaeda & Contreras Expires 8 January 2025 [Page 8] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 configuration errors. If a default upstream interface is not configured on an IGMP/MLD proxy device, the candidate upstream interface with the highest IPv4/ v6 address is selected as the default upstream interface. 5. Upstream Interface Takeover 5.1. Proxy Behavior "Upstream interface takeover" is a function for proxy devices to realize continuous multicast data reception. If a proxy device detects that a selected upstream interface is going down or inactive, it disables the current upstream interface and selects another active upstream interface with the highest priority among the candidate upstream interfaces covering the same channel/session ID. The list of candidate upstream interfaces (except the disabled interface) is recursively examined, and a new upstream interface is selected from the list. If another candidate upstream interface is not configured, the default upstream interface is selected. If a proxy device simultaneously uses more than two upstream interfaces per session/channel and one or some of these upstream interface(s) is/are inactive, the proxy device can only use the active interface or use another candidate upstream interface. Meanwhile, network operators may want to continue to maintain the inactive upstream interface without switching to the active upstream interface. This is especially the case when subscriber address prefix is configured according to the subscribers’ accounting policy (because the subscribers intend to use a particular upstream interface and cannot receive packets from other upstream interfaces according to their contract). In this case, the upstream interface takeover function must be disabled, and the proxy device continues to maintain the inactive upstream interface for the subscribers (and use it when the interface is reactivated). Thus, operators must configure whether upstream interface takeover is enabled or disabled on proxy devices. The condition of whether the upstream adjacent router is active or inactive can be determined by checking the link/interface conditions on the proxy device or by monitoring the IGMP/MLD Query or PIM [RFC7761] Hello message reception on the link. There are cases where PIM is not running on the link or IGMP/MLD Query messages are not always transmitted by the upstream router (e.g., when the explicit tracking function [I-D.ietf-pim-explicit-tracking] is enabled). [I-D.contreras-pim-multiif-config] describes how to detect link/ interface conditions. Asaeda & Contreras Expires 8 January 2025 [Page 9] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 5.2. Active Interval An active interval is a period in which the selected upstream interface on the proxy device remains active. The active interval of each candidate upstream interface can be configured. Active interval values vary depending on whether the network operators wish to trigger via IGMP/MLD or PIM messages. The default active interval for detecting an inactive upstream interface is approximately twice the IGMP/MLD General Query interval and PIM Hello interval; however, further discussion is TBD. 6. Dynamic Upstream Interface Configuration 6.1. Signaling-based Upstream Interface Configuration Operators may want proxy devices to dynamically configure upstream interfaces for specific multicast channels/sessions. [I-D.contreras-pim-multiif-config] describes a signaling-based dynamic upstream interface configuration method to support multiple upstream interfaces for IGMP/MLD proxies. The dynamic upstream interface configuration is enabled when network operators set it up on their proxy devices; however, if upstream interface(s) are statically configured either with "channel-based upstream selection" or "subscriber-based upstream selection," the static configuration is prioritized. 6.2. Controller-based Upstream Interface Configuration A centralized controller can instruct a proxy device on the upstream interface to use for specific multicast channels or subscribers. The controller should configure a default upstream interface for subscription requests that do not match an explicitly configured behavior. In case of an upstream interface failure, the default upstream interface can take over the failed upstream to provide redundancy. To enable this type of configuration, some control and management interfaces must be supported by a proxy to receive configuration instructions from the controller. The controller can interact with multiple proxies in the network. As a centralized element, it can make coordinated decisions to manage multicast traffic in the network in a coordinated manner. Asaeda & Contreras Expires 8 January 2025 [Page 10] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 7. Security Considerations This document neither provides new functions nor modifies the standard functions defined in [RFC3376][RFC3810][RFC5790]; therefore, no additional security considerations are provided for these protocols. Conversely, it is possible to encounter denial-of-service (DoS) attacks to stop upstream interface takeover if attackers illegally send IGMP/MLD Query or PIM Hello messages on a LAN within a shorter period (i.e., before the expiration of the active upstream interface interval). To bypass such threats, it is recommended to capture the source addresses of the IGMP/MLD Query or PIM Hello message senders and examine whether these addresses correspond to the correct adjacent upstream routers. These considerations are TBD. 8. Consideration for Updating YANG Model Regarding the IGMP/MLD YANG model proposed in [RFC9166], there is a description of interfaces for IGMP (similarly for MLD). Once this document has been officially approved, it will be necessary to update the proposed YANG model to include all information about the upstream interfaces discussed in this study and to consider actions related to the dynamic upstream interface configuration, as mentioned in Section 6. 9. Summary of Aspects Requiring Further Discussion We have the following open issues. * Specific default active interval for detecting an inactive upstream interface (Section 5.2). * Interaction with signaling methods (i.e., IGMP/MLD messages) to configure the upstream interface(s) (Section 6). * Security threats from potential DoS attacks (Section 7). They will be discussed in the future revisions of this document. 10. IANA Considerations This document has no IANA actions required. 11. Acknowledgements TBD. 12. References Asaeda & Contreras Expires 8 January 2025 [Page 11] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [I-D.contreras-pim-multiif-config] Contreras, L. M. and H. Asaeda, "Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies", Work in Progress, Internet-Draft, draft-contreras-pim-multiif-config-01, 23 October 2023, . [I-D.ietf-pim-explicit-tracking] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Work in Progress, Internet-Draft, draft-ietf-pim-explicit-tracking-13, 1 November 2015, . [I-D.ietf-pim-multiple-upstreams-reqs] Contreras, L. M., Bernardos, C. J., Asaeda, H., and N. Leymann, "Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces", Work in Progress, Internet-Draft, draft-ietf- pim-multiple-upstreams-reqs-08, 9 November 2018, . [ICIN.xml] Fernandez, D., Contreras, L. M., Moyano, R. F., Garcia, S., and IEEE, "NFV/SDN Based Multiple Upstream Interfaces Multicast Proxy Service", 2021 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/icin51074.2021.9385529, 1 March 2021, . [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, . Asaeda & Contreras Expires 8 January 2025 [Page 12] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, . [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224, April 2011, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC9166] Zhao, H., Liu, X., Liu, Y., Peter, A., and M. Sivakumar, "A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping", RFC 9166, DOI 10.17487/RFC9166, February 2022, . Appendix A. Summary of Requirements The following table summarizes the requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces as stated in [I-D.ietf-pim-multiple-upstreams-reqs]. The solution described in this document is designed based on these requirements. Asaeda & Contreras Expires 8 January 2025 [Page 13] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 +---------+-----------+-----------+-----------+-----------+-----------+ |Functio- | Multicast | Multicast | Load | Network | Network | |nality | Wholesale | Resiliency| Balancing | Merging | Migration | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstream | | | | | | |Control | X | X | X | X | X | |Delivery | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Downstr. | | | | | | |Control | X | X | X | X | X | |Delivery | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Active / | | | | | | |Standby | | X | | | | |Upstream | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstr i/f| | | | | | |selection| | | X | X | | |per group| | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ |Upstr i/f| | | | | | |selection| | X | | | X | |all group| | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ | | | | | | | | ASM | X | X | X | X | X | | | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ | | | | | | | | SSM | X | X | X | | X | | | | | | | | +---------+-----------+-----------+-----------+-----------+-----------+ Figure 1: Summary of requirements For a more detailed description on the need for the listed requirements, [I-D.ietf-pim-multiple-upstreams-reqs] should be referred to. Appendix B. Proof of Concept The support of multiple upstream interfaces for IGMP/MLD proxies was experimentally implemented following a controller-based configuration approach. The implementation was based on Linux using a software- defined networking application running over a Ryu controller. This application uses OpenFlow from the controller to control an Open vSwitch, which relays downstream multicast data flows and upstream IGMP/MLD control traffic. The proof of concept is comprehensively Asaeda & Contreras Expires 8 January 2025 [Page 14] Internet-Draft Multipath Support for IGMP/MLD Proxy July 2024 described in [ICIN.xml]. Authors' Addresses Hitoshi Asaeda National Institute of Information and Communications Technology Email: asaeda@nict.go.jp Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Asaeda & Contreras Expires 8 January 2025 [Page 15]