Internet DRAFT - draft-asaeda-pim-multiif-igmpmldproxy

draft-asaeda-pim-multiif-igmpmldproxy







PIM                                                            H. Asaeda
Internet-Draft                                                      NICT
Intended status: Informational                              L. Contreras
Expires: 4 September 2024                                     Telefonica
                                                            3 March 2024


         Multiple Upstream Interface Support for IGMP/MLD Proxy
                draft-asaeda-pim-multiif-igmpmldproxy-07

Abstract

   This document describes the way of supporting multiple upstream
   interfaces for an IGMP/MLD proxy device.  The proposed extension
   enables an IGMP/MLD proxy device to receive multicast sessions/
   channels through the different upstream interfaces.  The upstream
   interface can be selected based on multiple criteria, such as the
   subscriber address prefixes, channel/session IDs, and interface
   priority values.  A mechanism for upstream interface takeover that
   enables to switch from an inactive upstream interface to an 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 4 September 2024.

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 4 September 2024                [Page 1]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 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.  Channel-Based Upstream Selection  . . . . . . . . . . . .   5
     3.2.  Subscriber-Based Upstream Selection . . . . . . . . . . .   6
     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.  Channel/Session ID  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Interface Priority  . . . . . . . . . . . . . . . . . . .   8
     4.4.  Default Upstream Interface  . . . . . . . . . . . . . . .   9
   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  . . . .  11
     6.2.  Controller-based Upstream Interface Configuration . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Consideration for Updating YANG Model . . . . . . . . . . . .  12
   9.  Summary of aspects requiring further discussion . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Summary of requirements  . . . . . . . . . . . . . .  14
   Appendix B.  Proof of concept . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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 joining or leaving of multicast sessions.  A proxy device
   performing IGMP/MLD-based forwarding (as known as IGMP/MLD proxy)
   [RFC4605] maintains multicast membership information by IGMP/MLD
   protocols on the downstream interfaces and sends IGMP/MLD membership
   report messages via the upstream interface to the upstream multicast
   routers when the membership information changes (e.g., by receiving



Asaeda & Contreras      Expires 4 September 2024                [Page 2]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   solicited/unsolicited report messages).  The proxy device forwards
   appropriate multicast packets received on its upstream interface to
   each downstream interface based on the downstream receiver's
   subscriptions.

   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 manually configured by
   designating upstream and downstream interfaces on an IGMP/MLD proxy
   device, and the root of the tree is expected to be connected to a
   wider multicast infrastructure.  An IGMP/MLD proxy device hence
   performs the router portion of the IGMP or MLD protocol on its
   downstream interfaces, and the host portion of IGMP/MLD on its
   upstream interface.  The proxy device must not perform the router
   portion of IGMP/MLD on its upstream interface.

   On the other hand, there is a scenario in which an IGMP/MLD proxy
   device enables multiple upstream interfaces and receives multicast
   packets through these interfaces.  For example, a proxy device having
   more than one interface may want to access to different networks,
   such as a global network like the Internet and local-scope networks.
   Or, a proxy device having 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 shall
   receive multicast packets from the different upstream interfaces and
   forward to the downstream interface(s).

   This document describes the way of enabling an IGMP/MLD proxy device
   to receive multicast sessions/channels through the different upstream
   interfaces.  The upstream interfaces can be configured either with
   "channel-based upstream selection" or "subscriber-based upstream
   selection" or both.  By channel-based upstream selection, an IGMP/MLD
   proxy device selects one or multiple upstream interface(s) from the
   candidate upstream interfaces "on a per channel/session basis".  By
   subscriber-based upstream selection, an IGMP/MLD proxy device selects
   one or multiple upstream interface(s) from the candidate upstream
   interfaces "on a per subscriber/receiver basis".

   When a proxy device transmits an IGMP/MLD report message, it examines
   the source and multicast addresses in the records of the IGMP/MLD
   report message.  It then transmits the appropriate IGMP/MLD report
   message(s) from the selected upstream interface(s).  Based on this,
   when a proxy device selects "one" upstream interface from the
   candidate upstream interfaces per session/channel, it is possible to
   enable "load balancing" per session/channel.  Moreover, when a proxy
   device selects "more than two" upstream interfaces from the candidate
   upstream interfaces per session/channel, it potentially receives
   duplicate (redundant) packets for the session/channel from the



Asaeda & Contreras      Expires 4 September 2024                [Page 3]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   different upstream interfaces simultaneously and provides "robust
   data reception".  Unlike the conventional approach [RFC4605], when a
   proxy device specified in this document 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
   decides appropriate upstream interface(s).  The decision defined in
   this document is made by the configuration mentioned above, while a
   dynamic upstream selection mechanism is introduced in another
   document [I-D.contreras-pim-multiif-config].

   In general, a proxy device selects "one" upstream interface from the
   candidate upstream interfaces per session/channel.  It is also
   possible to configure that a proxy device selects "more than two"
   upstream interfaces from the candidate upstream interfaces per
   session/channel.  In that case, it potentially receives duplicate
   (redundant) packets for the session/channel from the different
   upstream interfaces simultaneously and provides "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 to
   switch 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 condition or other factors.

   A "dynamic upstream selection" is a mechanism that selects an
   appropriate upstream interface(s) for sessions/channels based on the
   network and adjacent routers' conditions.  It is briefly introduced
   in this document whereas its detail specification as well as IGMP/MLD
   protocol extension is 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.






Asaeda & Contreras      Expires 4 September 2024                [Page 4]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   *  Selected upstream interface (or simply, upstream interface): A
      proxy device's interface in the direction of the root of the
      multicast forwarding tree.  A proxy device performs the host
      portion of IGMP/MLD on its upstream interfaces.  An upstream
      interface is selected from a list of candidate upstream
      interfaces.

   *  Default upstream interface: A default upstream interface is the
      upstream interface for multicast sessions/channels for which a
      proxy device cannot choose other interfaces as the upstream
      interface.  A default upstream interface is configurable.

   *  Active upstream interface: An active upstream interface is the
      upstream interface that has been receiving packets for specific
      multicast sessions/channels during the pre-defined active
      interval.

   *  Inactive upstream interface: An inactive upstream interface is the
      interface that has not received packets for specific multicast
      sessions/channels during the pre-defined active interval.

   *  Downstream interface: Each of a proxy device's interfaces 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: Channel/session ID consists of source address
      prefix and multicast address prefix for which a candidate upstream
      interface supposes to be an upstream interface for specified
      multicast sessions/channels.  Both or either source address prefix
      and/or multicast address prefix can be "null".

3.  Upstream Selection Mechanism

3.1.  Channel-Based Upstream Selection

   An IGMP/MLD proxy device selects one or multiple upstream
   interface(s) from the candidate upstream interfaces "per channel/
   session" based on the "channel/session ID" configuration.  This
   mechanism is called "channel-based upstream selection" whose
   configuration is explained in Section 4.1 and Section 4.2.  This
   mechanism enables an IGMP/MLD proxy device to use one or multiple



Asaeda & Contreras      Expires 4 September 2024                [Page 5]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   upstream interface(s) from the candidate upstream interfaces "per
   channel/session" based on the "channel/session ID" configuration (as
   will be in Section 4.1 and Section 4.2).

3.2.  Subscriber-Based Upstream Selection

   An IGMP/MLD proxy device selects one or multiple upstream
   interface(s) from the candidate upstream interfaces "per subscriber/
   receiver".  This is called "subscriber-based upstream selection".  It
   enables a proxy device to use one or multiple upstream interface(s)
   per session/channel from the "candidate upstream interfaces" based on
   the "subscriber address prefix" configuration (as will be in
   Section 4.1).

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" (as will be in Section 4.3) are
   identical, these candidate upstream interfaces act as the upstream
   interfaces for the sessions/channels and receive the packets
   simultaneously.  This multiple upstream interface selection
   implements duplicate packet reception from redundant paths.  It may
   improve data reception quality or robustness for a session/channel,
   as the same multicast data packets can come from different upstream
   interfaces simultaneously.  However, this robust data reception does
   not guarantee that the packets come from disjoint paths.  It only
   configures that the adjacent upstream routers are different.

4.  Candidate Upstream Interface Configuration

   Candidate upstream interfaces are the interfaces from which an IGMP/
   MLD proxy device selects as an upstream interface.  The upstream
   interface selection works with the configurations of "subscriber
   address prefix", "channel/session ID", and "interface priority
   value".

4.1.  Address Prefix Record

   An IGMP/MLD proxy device can configure the "subscriber address
   prefix" and "channel/session ID" for each candidate upstream
   interface.









Asaeda & Contreras      Expires 4 September 2024                [Page 6]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   Channel/session ID consists of "source address prefix" and "multicast
   address prefix".  Subscriber address prefix and source address prefix
   MUST be a valid unicast address prefix, and multicast address prefix
   MUST be a valid multicast address prefix.  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 channel/session ID includes:

     (source address prefix, multicast address prefix)

   The default values of these address prefixes are "null".  Null source
   address prefix represents the wildcard source address prefix, which
   indicates any host.  Null multicast address prefix represents the
   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 having the configuration of
   subscriber address prefix is prioritized.  If network operators want
   to assign a specific upstream interface for specific subscribers
   without depending on source and multicast address prefixes, both
   source and multicast addresses in the address prefix record is
   configured "null".

   If network operators want to select specific upstream interface(s)
   without depending on subscriber address prefix, subscriber address
   prefix in the address prefix record is configured "null".

4.2.  Channel/Session ID

   Channel/session ID configuration consists of source and multicast
   address prefixes.  Both/either source and/or multicast address may be
   configured "null".  A candidate upstream interface having non-null
   source and multicast address configuration is prioritized for the
   upstream interface selection.  For example, if a proxy device has two
   candidate upstream interfaces for the same multicast address prefix
   and one of them has non-null source address configuration, then that
   candidate upstream interface is selected for the source and multicast
   address pair.  The other candidate upstream interface is selected for
   the configured multicast address prefix except the source address
   configured by the prior interface.

   Source address prefix configuration takes priority over multicast
   address prefix configuration.  For example, consider the case that an
   IGMP/MLD proxy device has a configuration with source address prefix



Asaeda & Contreras      Expires 4 September 2024                [Page 7]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   S_p for the candidate upstream interface A and multicast address
   prefix G_p for the candidate upstream interface B.  When it deals
   with an IGMP/MLD record whose source address, let's say S, is in the
   range of S_p, and whose multicast address, let's say G, is in the
   range of G_p, the proxy device selects the candidate upstream
   interface A, which supports the source address prefix, as the
   upstream interface, and transmits the (S,G) record via the interface
   A.

   In summary, there are options for selecting the appropriate upstream
   interface as follows:

   *  Association of membership requests from a specific user,
      identified by the source IP of the IGMP/MLD message, to a specific
      upstream interface, meaning that all the multicast traffic for
      that a user is received from a certain upstream interface.  This
      condition is prioritized first.

   *  Association of (S,G) to a specific upstream interface, meaning
      that a user request for specific content delivered from a specific
      source should be received from a certain upstream interface.  This
      condition is prioritized second.

   *  Association of (*,G) to a specific upstream interface, meaning
      that a user request of given content, independently of the source
      of that content, should be received from a certain upstream
      interface.  This condition is prioritized fourth.

   *  Association of (S,*) to a specific upstream interface, meaning
      that all the requests from a certain user, independently of the
      group identifying the content, should be received from a certain
      upstream interface.  This condition is prioritized third.

   The same address prefix may 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 based on each interface priority
   value (as will be in Section 4.3).

4.3.  Interface Priority

   An IGMP/MLD proxy device can configure the "interface priority" value
   for each candidate upstream interface.  The priority is indicated
   with an integer value and is part of the configuration.  Lower value
   is lower priority and the default value of the interface priority is
   zero.





Asaeda & Contreras      Expires 4 September 2024                [Page 8]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   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 chosen as the upstream
   interface.  As stated in Section 3.3, if multiple candidates upstream
   interfaces have the same priority value, these interfaces will act as
   upstream interfaces for the configured channel/session ID and may
   receive duplicate packets.

4.4.  Default Upstream Interface

   Operators can configure "a default upstream interface" for all
   incoming sessions/channels in an IGMP/MLD proxy device.  A default
   upstream interface is used as the upstream interface, when candidate
   upstream interfaces are not configured for subscriber address prefix,
   channel/session ID, or interface priority value.  A default upstream
   interface is also used if a proxy device detects configuration
   errors.

   If a default upstream interface is not configured on an IGMP/MLD
   proxy device, the candidate upstream interface whose IPv4/v6 address
   is the highest is chosen as the default upstream interface.

5.  Upstream Interface Takeover

5.1.  Proxy Behavior

   If a selected upstream interface is going down or inactive, or an
   adjacent upstream router is not working, the upstream interface can
   be disabled and the other active upstream interface listed in the
   candidate upstream interfaces covering the same channel/session ID
   can act as a new upstream interface.  It recursively examines the
   list of the candidate upstream interfaces (except the disabled
   interface) and decides a new upstream interface from them.  If no
   active candidate upstream interfaces exist, the default upstream
   interface takes its role.













Asaeda & Contreras      Expires 4 September 2024                [Page 9]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   This function called "upstream interface takeover" is a function for
   a proxy device to enable continuous multicast data reception.  If a
   proxy device detects the upstream interface is inactive, it uses
   another candidate upstream interface whose priority is the highest
   among the configured upstream interfaces.  If another candidate
   upstream interface is not configured, it uses the default upstream
   interface.  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 uses another candidate upstream interface as
   specified above.

   Network operators may want to keep out of use for the inactive
   upstream interface(s).  This causes, for example, when subscriber-
   based upstream selection is configured, according to their accounting
   policy (because the specific subscribers are planned to use the
   specific upstream interface and cannot receive packets from other
   upstream interfaces.)  In that case, this upstream interface takeover
   must be disabled, and the proxy device keeps using that interface as
   the upstream interface for them (and waits for working the interface
   later again).  Therefore, whether the upstream interface takeover is
   enabled or not on the proxy device must be configured by operators.

   The condition whether the upstream adjacent router is active or not
   can be decided by checking the link/interface condition on the proxy
   device or detected by monitoring IGMP/MLD Query or PIM [RFC7761]
   Hello message reception on the link.  There are the cases that PIM is
   not running on the link or IGMP/MLD Query messages are not always
   transmitted by the upstream router (e.g., because of enabling the
   explicit tracking function [I-D.ietf-pim-explicit-tracking]).
   [I-D.contreras-pim-multiif-config] discusses the way to detect link/
   interface conditions.

5.2.  Active Interval

   Active interval is a period in which the selected upstream interface
   on a proxy device keeps working.  Active interval for each candidate
   upstream interface may be configured.  The active interval values are
   different in the situation whether the network operators want to
   trigger by either IGMP/MLD or PIM messages.  The default active
   interval to detect an inactive upstream interface is around twice of
   IGMP/MLD General Query interval and PIM Hello interval; however,
   further discussion is TBD.

6.  Dynamic Upstream Interface Configuration






Asaeda & Contreras      Expires 4 September 2024               [Page 10]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


6.1.  Signaling-based Upstream Interface Configuration

   Operators may want a proxy device to dynamically configure the
   upstream interface 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
   will be prioritized.

6.2.  Controller-based Upstream Interface Configuration

   A centralized controller can instruct a proxy device which upstream
   interface is selected for certain multicast channels or users.

   The controller should configure a default upstream interface for
   those subscription requests that do not match an explicitly
   configured behavior.  In case of upstream interface failure, the
   default upstream interface could take over the failed upstream to
   provide redundancy.

   To enable this manner of configuration, some control and management
   interface has to be supported by the proxy in order to receive
   configuration instructions from the controller.

   The controller could interact with a number of proxies in the
   network.  Being a centralized element, it could take coordinated
   decisions for managing all the multicast traffic in the network in a
   coordinated manner.

7.  Security Considerations

   This document neither provides new functions nor modifies the
   standard functions defined in [RFC3376][RFC3810][RFC5790]; hence
   there is no additional security consideration provided for these
   protocols.  On the other hand, it may be possible to encounter DoS
   attacks to make the function for upstream interface takeover stop if
   attackers illegally sends IGMP/MLD Query or PIM Hello messages on a
   LAN within a shorter period (i.e., before expiring the active
   interval for the upstream interface).  To bypass such threats, it is
   recommended to capture the source addresses of IGMP/MLD Query or PIM
   Hello message senders and check whether the addresses correspond to
   the correct adjacent upstream routers.  These considerations are TBD.





Asaeda & Contreras      Expires 4 September 2024               [Page 11]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


8.  Consideration for Updating YANG Model

   About the IGMP/MLD YANG model proposed in [RFC9166], there is a
   description of interfaces for IGMP (similar for MLD).  Once this
   document is officially approved, it will be necessary to update the
   proposed YANG model to include all the information related to the
   upstream interfaces defined in this document, and consider the
   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.

   *  Value of the default active interval to detect an inactive
      upstream interface (Section 5.2).

   *  Interaction with signaling methods (i.e., IGMP/MLD messages) for
      configuring 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

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

12.2.  Informative References





Asaeda & Contreras      Expires 4 September 2024               [Page 12]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   [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,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              pim-multiif-config-01>.

   [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.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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
              multiple-upstreams-reqs-08>.

   [ICIN]     "D. Fernández, L. M. Contreras, R. F. Moyano and S.
              García, "NFV/SDN Based Multiple Upstream Interfaces
              Multicast Proxy Service," 2021 24th Conference on
              Innovation in Clouds, Internet and Networks and Workshops
              (ICIN), Paris, France, 2021, pp. 159-163.", 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,
              <https://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

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






Asaeda & Contreras      Expires 4 September 2024               [Page 13]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


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

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

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 previously stated in
   [I-D.ietf-pim-multiple-upstreams-reqs].  The solution described in
   this document is designed based on these requirements.


























Asaeda & Contreras      Expires 4 September 2024               [Page 14]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 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, the reader is referred to
   [I-D.ietf-pim-multiple-upstreams-reqs].

Appendix B.  Proof of concept

   The support of multiple upstream interfaces for IGMP/MLD Proxy has
   been experimentally implemented following the controller-based
   configuration approach.  The implementation has been based on Linux
   using an SDN application running over Ryu controller.  Such
   application is able to control by means of OpenFlow from the
   controller an Open vSwitch which is in charge of relaying the
   downstream multicast data flows and the upstream IGMP/MLD control



Asaeda & Contreras      Expires 4 September 2024               [Page 15]

Internet-Draft    Multiple Upstream for IGMP/MLD Proxy        March 2024


   traffic.  The proof of concept is fully described in [ICIN].

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 4 September 2024               [Page 16]