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

PIM Working Group                                              H. Asaeda
Internet-Draft                                                      NICT
Intended status: Informational                             LM. Contreras
Expires: May 6, 2020                                          Telefonica
                                                        November 3, 2019

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

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 is selected based on 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 May 6, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Asaeda & Contreras         Expires May 6, 2020                  [Page 1]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified 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 . . . . . . . . . . .   5
     3.3.  Multiple Upstream Interface Selection for Robust Data
           Reception . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Candidate Upstream Interface Configuration  . . . . . . . . .   6
     4.1.  Address Prefix Record . . . . . . . . . . . . . . . . . .   6
     4.2.  Channel/Session ID  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Interface Priority  . . . . . . . . . . . . . . . . . . .   7
     4.4.  Default Upstream Interface  . . . . . . . . . . . . . . .   8
   5.  Upstream Interface Takeover . . . . . . . . . . . . . . . . .   8
     5.1.  Proxy Behavior  . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Active Interval . . . . . . . . . . . . . . . . . . . . .   9
   6.  Automatic Upstream Interface Configuration  . . . . . . . . .   9
     6.1.  Signaling-based Upstream Interface Configuration  . . . .  10
     6.2.  Controller-based Upstream Interface Configuration . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Consideration for Updating YANG Model . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The Internet Group Management Protocol (IGMP) [2][4] for IPv4 and the
   Multicast Listener Discovery Protocol (MLD) [3][4] 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) [5] 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 solicited/
   unsolicited report messages).  The proxy device forwards appropriate
   multicast packets received on its upstream interface to each
   downstream interface based on the downstream interface's
   subscriptions.

Asaeda & Contreras         Expires May 6, 2020                  [Page 2]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   According to the specification of [5], 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., WiMAX or LTE) 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).  Several other
   scenarios and subsequent requirements for the support of multiple
   upstream interfaces on IGMP/MLD proxy are documented in [7].

   This document describes the mechanism that enables an IGMP/MLD proxy
   device to receive multicast sessions/channels through the different
   upstream interfaces.  The mechanism is configured with either
   "channel-based upstream selection" or "subscriber-based upstream
   selection", or both of them.  By channel-based upstream selection, an
   IGMP/MLD proxy device selects one or multiple upstream interface(s)
   from the candidate upstream interfaces "per channel/session".  By
   subscriber-based upstream selection, an IGMP/MLD proxy device selects
   one or multiple upstream interface(s) from the candidate upstream
   interfaces "per subscriber/receiver".

   When a proxy device transmits an IGMP/MLD report message, it examines
   the source and multicast addresses in the IGMP/MLD records of the
   report message.  It then transmits the appropriate IGMP/MLD report
   message(s) from the selected upstream interface(s).  When a proxy
   device selects "one" upstream interface from the candidate upstream
   interfaces per session/channel, it enables "load balancing" per
   session/channel.  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 different upstream
   interfaces simultaneously and provides "robust data reception".

Asaeda & Contreras         Expires May 6, 2020                  [Page 3]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   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 values to
   switch from an inactive upstream interface to an active upstream
   interface from a list of candidate upstream interfaces are discussed
   in this document as well.

   An "automatic upstream configuration" mechanism that selects an
   appropriate upstream interface(s) for sessions/channels based on the
   network and adjacent routers' conditions is also described in this
   document.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [1].

   In addition, the following terms are used in this document.

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

   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.

Asaeda & Contreras         Expires May 6, 2020                  [Page 4]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   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).  enables
   an IGMP/MLD proxy device to use one or multiple 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

Asaeda & Contreras         Expires May 6, 2020                  [Page 5]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

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

Asaeda & Contreras         Expires May 6, 2020                  [Page 6]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

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

   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.  It is an integer value and is
   part of the configuration.  The default value of the interface
   priority is the lowest value.

   The interface priority value effects only when either of the
   following conditions is satisfied.

   o  None of the candidate upstream interfaces configures both the
      subscriber address prefix and the channel/session ID.

   o  More than one candidate upstream interface configures the same
      channel/session IDs but does not configure the subscriber address
      prefix.

Asaeda & Contreras         Expires May 6, 2020                  [Page 7]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   In these conditions, the candidate upstream interface with the
   highest priority is chosen as the upstream interface.  And as stated
   in Section 3.3, if the priority values for candidate upstream
   interfaces are also identical, all of these interfaces act as the
   upstream interfaces for the configured channel/session ID and may
   receive duplicate packets.

4.4.  Default Upstream Interface

   An IGMP/MLD proxy device SHOULD configure "a default upstream
   interface" for all incoming sessions/channels.  A default upstream
   interface is selected as the upstream interface, when none of the
   candidate upstream interfaces configures subscriber address prefix,
   channel/session ID, or interface priority value, or with either of
   the following conditions.

   o  None of the candidate upstream interfaces configures both the
      subscriber address prefix, the channel/session ID, and identical
      interface priority value.

   o  More than one candidate upstream interface configures the same
      channel/session IDs and identical interface priority value, but
      does not configure the subscriber address prefix.

   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 of others is configured as the default upstream
   interface for the proxy device.

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.

   This function called "upstream interface takeover" is a default
   function for a proxy device that enables multiple upstream interface
   support.  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 acts either

Asaeda & Contreras         Expires May 6, 2020                  [Page 8]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   of the following behaviors based on the configuration; (1) it only
   uses the active upstream interface(s) and does not add (i.e., does
   not complement) other upstream interfaces, (2) it uses the active
   upstream interface(s) and another candidate upstream interface whose
   priority is highest among the configured upstream interfaces, or (3)
   it uses the active upstream interface(s) and the default upstream
   interface.

   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 [6] 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 [8]).  Therefore, network operators MUST
   configure either; (1) the proxy device disables the upstream
   interface takeover, (2) the proxy device triggers upstream interface
   takeover by detecting no IGMP/MLD Query message within the active
   interval, or (3) the proxy device triggers upstream interface
   takeover by detecting no PIM Hello message within the active
   interval, for each candidate upstream interface.

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

5.2.  Active Interval

   Active interval is a period, after which a proxy device recognizes
   that the selected upstream interface is inactive.  Active interval
   for each candidate upstream interface SHOULD 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.  Further discussion [TBD].

6.  Automatic Upstream Interface Configuration

Asaeda & Contreras         Expires May 6, 2020                  [Page 9]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

6.1.  Signaling-based Upstream Interface Configuration

   There may be the ways for a proxy device to automatically configure
   the upstream interface for specific multicast channels/sessions.  It
   works for the case in which there are no static configurations for a
   candidate upstream interface or operators decide.  The algorithms are
   achieved by monitoring existing or newly proposed IGMP/MLD messages,
   but further discussions are TBD.

6.2.  Controller-based Upstream Interface Configuration

   A centralized controller can instruct the proxy what upstream
   interface is the appropriate one to use based on a certain multicast
   channel or on the user herself.  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.  IANA Considerations

   This document has no actions for IANA.

8.  Security Considerations

   This document neither provides new functions nor modifies the
   standard functions defined in [2][3][4]; hence there is no additional
   security consideration provided for these protocols themselves.  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.  Consideration [TBD].

9.  Consideration for Updating YANG Model

   About the IGMP/MLD YANG model proposed in [9], there is a description
   of interfaces for IGMP (similar for MLD).  When this document is
   officially approved, it is 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

Asaeda & Contreras         Expires May 6, 2020                 [Page 10]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   to the selection of the upstream interfaces as mentioned in
   Section 6.

10.  References

10.1.  Normative References

   [1]        Bradner, S., "Key words for use in RFCs to indicate
              requirement levels", RFC 2119, March 1997.

   [2]        Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [3]        Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [4]        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,
              February 2010.

   [5]        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, August 2006.

   [6]        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)", RFC 7761, March 2016.

10.2.  Informative References

   [7]        Contreras, LM., Bernardos, CJ., Asaeda, H., and N.
              Leymann, "Requirements for the extension of the IGMP/MLD
              proxy functionality to support multiple upstream
              interfaces", draft-ietf-pim-multiple-upstreams-reqs-08
              (work-in-progress), November 2018.

   [8]        Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking
              Function for Multicast Routers", draft-ietf-pim-explicit-
              tracking-13 (work-in-progress), November 2015.

Asaeda & Contreras         Expires May 6, 2020                 [Page 11]
Internet-Draft    Multiple Upstream for IGMP/MLD Proxy     November 2019

   [9]        Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A.
              Peter, "A YANG Data Model for Internet Group Management
              Protocol (IGMP) and Multicast Listener Discovery (MLD)",
              draft-ietf-pim-igmp-mld-yang-15 (work-in-progress), June
              2019.

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
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com/

Asaeda & Contreras         Expires May 6, 2020                 [Page 12]