Multipath Support for IGMP/MLD Proxy
draft-ietf-pim-multipath-igmpmldproxy-05

PIM                                                            H. Asaeda
Internet-Draft                                                      NICT
Intended status: Informational                              L. Contreras
Expires: 24 April 2027                                        Telefonica
                                                         21 October 2026

                  Multipath Support for IGMP/MLD Proxy
                draft-ietf-pim-multipath-igmpmldproxy-05

Abstract

   This document specifies the framework to support multipath reception
   in Internet Group Management Protocol (IGMP) / Multicast Listener
   Discovery (MLD) proxy devices.  The proposed mechanism allows IGMP/
   MLD proxy devices to receive multicast sessions/channels through
   different upstream interfaces.  It defines static configuration
   methods for associating upstream interfaces with channel identifiers
   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 24 April 2027.

Copyright Notice

   Copyright (c) 2026 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 24 April 2027                 [Page 1]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   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.  Static Upstream Interface Configuration and Selection
           Mechanism . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Channel-Based Upstream Selection  . . . . . . . . . . . .   5
     3.2.  Multiple Upstream Interface Selection for Robust Data
           Reception . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Upstream Interface Takeover . . . . . . . . . . . . . . .   6
   4.  Candidate Upstream Interface Configuration  . . . . . . . . .   6
     4.1.  Multicast Channel Record  . . . . . . . . . . . . . . . .   7
     4.2.  Interface Priority  . . . . . . . . . . . . . . . . . . .   8
     4.3.  Default Upstream Interface  . . . . . . . . . . . . . . .   8
   5.  Updating YANG Model . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Proof of Concept . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 that performs IGMP/MLD-based forwarding (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
   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.
   Upstream and downstream interfaces on the IGMP/MLD proxy device must

Asaeda & Contreras        Expires 24 April 2027                 [Page 2]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   be configured manually, and the upstream interface 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 the
   Internet and local-scope networks, or 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 specifies the framework to support multipath reception
   in IGMP/MLD proxy devices and defines the static upstream interface
   configuration mechanisms for IGMP/MLD proxies to select one or more
   upstream interfaces per multicast channel/session.  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).
   The upstream interfaces can be selected by static configurations
   based on channel identifiers and interface priority values.  Note
   that the upstream interface selection by dynamic configurations is
   introduced in another document [I-D.contreras-pim-multiif-config] and
   out of scope of this document.

   In addition, this document defines the method for a proxy device to
   select one or more upstream 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 becomes
   unavailable or does not receive packets for the corresponding
   multicast channel during the configured active interval, one of the
   other available candidate upstream interfaces (i.e., backup upstream
   interface) takes over the upstream interface if configured.

Asaeda & Contreras        Expires 24 April 2027                 [Page 3]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

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.

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

   *  Active upstream interface: An upstream interface that has been
      receiving packets for specific multicast sessions/channels during
      a predefined active interval.

   *  Inactive upstream interface: An interface that has not received
      packets for specific multicast sessions/channels during a
      predefined active interval.

   *  Candidate upstream interface: An interface that potentially
      becomes an upstream interface of the proxy device.  A list of
      candidate upstream interfaces is configured with channel/session
      identifiers and/or priority values on an IGMP/MLD proxy device.

   *  Backup upstream interface: A candidate upstream interface that
      remains passive (i.e., not receiving traffic for the corresponding
      multicast channel until a failover event occurs).  It may be used
      where operator policy prioritizes maintaining a backup path to
      ensure data transfer rather than active multipath forwarding.

Asaeda & Contreras        Expires 24 April 2027                 [Page 4]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   *  Channel/session identifier: A pair consisting of a source address
      prefix and a multicast address prefix.  Either prefix can be
      "null".  A null value acts as a wildcard for the corresponding
      field.  For example, a null source address prefix matches any
      source for the specified multicast address prefix (i.e., (*,G)).
      For the default upstream interface, both values are set to null so
      that the entry matches any multicast session/channel.

   *  Robust data reception: The behavior in which multiple upstream
      interfaces are used in parallel to receive the same multicast
      content from them concurrently.  It is OPTIONAL for
      implementations to support this behavior.  If this feature is
      disabled or not implemented, a single upstream interface is
      selected for each multicast channel.

   *  Upstream interface takeover: The behavior in which a proxy device
      stops using an unavailable or inactive selected upstream interface
      for a session/channel and switches to a backup upstream interface.

3.  Static Upstream Interface Configuration and Selection Mechanism

3.1.  Channel-Based Upstream Selection

   An IGMP/MLD proxy device selects one or more upstream interfaces from
   the candidate upstream interfaces for each session/channel based on
   the configured channel/session identifier.  This mechanism is
   referred to as "channel-based upstream selection."

3.2.  Multiple Upstream Interface Selection for Robust Data Reception

   When more than one candidate upstream interface is configured with
   identical source and multicast addresses for the "channel/session
   identifiers" and with the same "interface priority value" (as
   described in Section 4.2), these candidate upstream interfaces act as
   upstream interfaces for the corresponding sessions/channels and
   receive the same multicast traffic simultaneously.

   Receiving the same multicast traffic through multiple upstream
   interfaces provides redundant packet reception and may improve the
   robustness of data reception.  This behavior is similar to the
   redundant multicast reception used by Multicast-Only Fast Reroute
   (MoFRR) [RFC7431].  Duplicate multicast packets may therefore be
   received through the selected upstream interfaces.  Duplicate packet
   detection and elimination are outside the scope of this document.

Asaeda & Contreras        Expires 24 April 2027                 [Page 5]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   Robust data reception does not guarantee that packets are received
   over disjoint paths.  The selected upstream interfaces are connected
   to different adjacent upstream routers, but the paths from these
   routers toward the multicast source may still overlap.

3.3.  Upstream Interface Takeover

   "Upstream interface takeover" is a function for proxy devices to
   realize continuous multicast data reception.  A proxy device can
   simultaneously use multiple upstream interfaces per session/
   channel.　If a proxy device detects that a selected upstream interface
   is　unavailable or inactive, it stops using that interface for the　
   session/channel and switches to a backup upstream interface.　To
   enable upstream interface takeover, the backup upstream interface
   MUST be configured.  The backup upstream interface is selected from
   the candidate upstream　interfaces that match the same session/
   channel.　If multiple backup upstream interfaces are configured, the
   interface priority value for each backup upstream interface MUST be
   configured.

   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.  Note that 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).

   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 MAY be approximately
   twice the IGMP/MLD General Query interval and PIM Hello interval.
   However, defining the optimal timer value for switching from an
   inactive upstream interface to an active upstream interface from a
   list of candidate upstream interfaces is out of scope of this
   document.  It SHOULD be possible for operators to change the timer
   value according to the network conditions or other factors.

4.  Candidate Upstream Interface Configuration

   An IGMP/MLD proxy device selects one or more upstream interfaces from
   a set of candidate upstream interfaces.  The upstream interface
   selection approach works with the configurations of "channel/session
   identifier" and "interface priority value."

Asaeda & Contreras        Expires 24 April 2027                 [Page 6]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

4.1.  Multicast Channel Record

   IGMP/MLD proxy devices can configure the "channel/session identifier"
   in the multicast channel record for each candidate upstream
   interface.

   A channel/session identifier consists of a source address prefix and
   a multicast address prefix.  Source address prefixes MUST be valid
   unicast address prefixes, and multicast address prefixes MUST be
   valid multicast address prefixes.  A proxy selects an upstream
   interface from its candidate upstream interfaces based on the
   channel/session identifier configuration.

   The default values of these address prefixes are "null."  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 channel/session identifier 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, in environments where multiple static upstream interface
   configurations are defined, the proxy device determines the
   applicable upstream interface based on the following precedence
   order:

Asaeda & Contreras        Expires 24 April 2027                 [Page 7]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   *  (S,G) association: If a specific source and multicast group pair
      is configured, the corresponding upstream interface is used for
      delivering traffic matching that pair.

   *  (S,*) association: If a source address is configured without a
      specific group, the corresponding upstream interface is used for
      traffic from that source, regardless of group.

   *  (*,G) association: If a multicast group is configured without a
      specific source, the corresponding upstream interface is used for
      traffic to that group, regardless of source.

   When multiple upstream interfaces are configured with overlapping
   address prefixes, the interface with the highest priority value, as
   described in Section 4.2, is used.  If multiple interfaces share the
   same highest priority value, they are used in parallel for redundant
   reception as described in Section 3.2.

4.2.  Interface Priority

   An IGMP/MLD proxy device can configure an "interface priority" value
   for each candidate upstream interface.  The priority is indicated by
   a non-negative integer value and is part　of the configuration.  A
   lower value indicates a lower priority, and　the default value is
   zero.

   The interface priority value is used when no channel/session
   identifier is configured for a candidate upstream interface or when
   multiple candidate upstream interfaces are configured with the same
   channel/session identifier.  In these cases, the candidate upstream
   interface with the highest priority is selected as the upstream
   interface.  As stated in Section 3.2, if multiple candidate upstream
   interfaces have the same priority value, they act as upstream
   interfaces for the configured channel/session identifier in parallel
   and may receive duplicate packets.

4.3.  Default Upstream Interface

   A proxy device MAY be configured with a default upstream interface.
   The default upstream interface is selected for a multicast session/
   channel when no multicast channel record is configured for that
   session/channel.  The source and multicast address prefixes of the
   default upstream interface are both set to null so that they match
   any session/channel.

   When a multicast channel record is configured for a session/channel,
   the proxy device selects an upstream interface from the candidate
   upstream interfaces specified in that record.  If the selected

Asaeda & Contreras        Expires 24 April 2027                 [Page 8]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

   upstream interface becomes unavailable, another candidate upstream
   interface is selected according to the upstream interface takeover
   procedure described in Section 3.3.  The default upstream interface
   is not used unless it is explicitly included as a candidate upstream
   interface in the record.  If no candidate upstream interface can be
   selected, the proxy device does not send the corresponding IGMP/MLD
   Report through an upstream interface.

   An implementation SHOULD validate multicast channel records when the
   configuration is applied and reject invalid records.  An invalid
   record MUST NOT be used for upstream interface selection.  An invalid
   multicast channel record does not cause the default upstream
   interface to be selected.

5.  Updating YANG Model

   Regarding the IGMP/MLD YANG model proposed in [RFC9166], there is a
   description of interfaces for IGMP (similarly for MLD).  However, it
   is necessary to update the proposed YANG model to include all
   information about the upstream interfaces described in this document
   and to consider actions related to the dynamic upstream interface
   configuration.  [I-D.zcl-pim-multiif-igmp-mld-proxy-yang] is a
   potential data model proposal used for this purpose.

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

7.  IANA Considerations

   This document does not define any new IANA registries.

8.  Acknowledgements

   TBD.

9.  References

Asaeda & Contreras        Expires 24 April 2027                 [Page 9]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

9.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,
              <https://www.rfc-editor.org/info/rfc2119>.

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

9.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-03, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              pim-multiif-config-03>.

   [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, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pim-explicit-tracking-13>.

   [I-D.zcl-pim-multiif-igmp-mld-proxy-yang]
              Zhao, H., Contreras, L. M., Liu, X., and H. Asaeda, "YANG
              Data Model for supporting multipath IGMP/MLD proxies",
              Work in Progress, Internet-Draft, draft-zcl-pim-multiif-
              igmp-mld-proxy-yang-04, 15 October 2026,
              <https://datatracker.ietf.org/doc/html/draft-zcl-pim-
              multiif-igmp-mld-proxy-yang-04>.

   [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), pp. 159-163, DOI 10.1109/icin51074.2021.9385529, 1
              March 2021,
              <https://doi.org/10.1109/icin51074.2021.9385529>.

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

Asaeda & Contreras        Expires 24 April 2027                [Page 10]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

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

   [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, <https://www.rfc-editor.org/info/rfc4605>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [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,
              <https://www.rfc-editor.org/info/rfc5790>.

   [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, <https://www.rfc-editor.org/info/rfc6224>.

   [RFC7431]  Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
              Decraene, "Multicast-Only Fast Reroute", RFC 7431,
              DOI 10.17487/RFC7431, August 2015,
              <https://www.rfc-editor.org/info/rfc7431>.

   [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, <https://www.rfc-editor.org/info/rfc7761>.

   [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,
              <https://www.rfc-editor.org/info/rfc9166>.

Asaeda & Contreras        Expires 24 April 2027                [Page 11]
Internet-Draft    Multipath Support for IGMP/MLD Proxy      October 2026

Appendix A.  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
   described in [ICIN.xml].

Authors' Addresses

   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Koganei,
   Tokyo 184-8795
   Japan
   Email: asaeda@nict.go.jp

   Luis M. Contreras
   Telefonica
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com

Asaeda & Contreras        Expires 24 April 2027                [Page 12]