PIM Working Group                                           L. Contreras
Internet-Draft                                                Telefonica
Intended status: Standards Track                               H. Asaeda
Expires: 11 January 2024                                            NICT
                                                            10 July 2023


     Signaling-based configuration for supporting multiple upstream
                     interfaces in IGMP/MLD proxies
                 draft-contreras-pim-multiif-config-00

Abstract

   The support of multiple upstream interfaces in IGMP/MLD proxies
   requires the capability of configuring the different upstream
   interfaces for specific multicast channels/sessions.  Recently
   [RFC9279] has defined a message extension mechanism for IGMP and MLD.
   This document leverages on that for proposing extension for
   signaling-based configuration the multiple upstream interfaces in
   IGMP/MLD proxies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 January 2024.

Copyright Notice

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

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



Contreras & Asaeda       Expires 11 January 2024                [Page 1]


Internet-Draft     Multiple upstream interfaces config         July 2023


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IGMP/MLD proxy with multiple upstream interfaces  . . . . . .   3
   4.  Policies applicable for selecting upstream interfaces . . . .   3
   5.  Signaling situations  . . . . . . . . . . . . . . . . . . . .   4
   6.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Report message extensions . . . . . . . . . . . . . . . .   5
       6.1.1.  Multicast channel/source discovery per upstream
               interface . . . . . . . . . . . . . . . . . . . . . .   5
       6.1.2.  Request of channel/source from one or more upstream
               interfaces  . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Query message extensions  . . . . . . . . . . . . . . . .   7
       6.2.1.  Response for discovery of upstream interface(s) and
               associated sources for a session/channel  . . . . . .   7
       6.2.2.  Maintenance of multicast membership on the downstream
               interfaces including information of the upstream
               interface used  . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   An IGMP/MLD proxy with multiple upstream interfaces, as described in
   [I-D.asaeda-pim-multiif-igmpmldproxy] permits a device to receive
   multicast sessions/channels through the different upstream
   interfaces.  The selection of a specific upstream interface can be
   based on multiple criteria, such as the subscriber address prefixes,
   channel/session IDs, and interface priority values.

   [I-D.asaeda-pim-multiif-igmpmldproxy] considers two options for the
   automatic configuration of the upstream interfaces.  On one hand, the
   configuration could be performed by a centralized controller,
   requiring from the proxy to have some control and management
   interface to receive configuration instructions from the controller.
   On the other hand, the configuration could be based in some
   signaling-based mechasnism by means of IGMP/MLD messages.  This
   document describes the latter, by using the extensions defined in
   [RFC9279].





Contreras & Asaeda       Expires 11 January 2024                [Page 2]


Internet-Draft     Multiple upstream interfaces config         July 2023


2.  Terminology

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

   In addition, the terms defined in
   [I-D.asaeda-pim-multiif-igmpmldproxy] are also used in this document.

3.  IGMP/MLD proxy with multiple upstream interfaces

   [I-D.asaeda-pim-multiif-igmpmldproxy] describes the capabilities of
   an IGMP/MLD proxy device for receiving multicast sessions/channels
   through the different upstream interfaces.  The proxy could work with
   either "channel-based upstream selection" or "subscriber-based
   upstream selection", or even both of them.  By channel-based upstream
   selection, an IGMP/MLD proxy device selects one or multiple upstream
   interface(s) from the candidate upstream interfaces "per channel/
   session".  By subscriber-based upstream selection, an IGMP/MLD proxy
   device selects one or multiple upstream interface(s) from the
   candidate upstream interfaces "per subscriber/receiver".

   With the ability of susbcribing to content through different multiple
   upstream interfaces, the proxy can either balance the load per
   session/channel, or simulatanously receive the content from more than
   one multiple upstream interface, providing a robust mechanism of
   content reception.  Then, this situaiton of subscribing to a channel
   and simultaneously receiving it through more than one upstream
   interface, should be also supported.

4.  Policies applicable for selecting upstream interfaces

   The support of multiple upstream interfaces allows for defining
   different policies in the IGMP/MLD proxy at the time of configuring
   those interfaces.  For instance, it can be taken into account the
   following criteria:

   *  Associate the requests from a specific user to a specific upstream
      interface

   *  Associate the request of specific content delivered from a
      specific source, i.e. (S,G), to a specific upstream interface

   *  Associate the request of specific content delivered from any
      source, i.e. (*,G), to a specific upstream interface

   *  Associate the request of any content delivered from a specific
      source, i.e. (S,*), to a specific upstream interface



Contreras & Asaeda       Expires 11 January 2024                [Page 3]


Internet-Draft     Multiple upstream interfaces config         July 2023


   These policies are expected to be configured in the proxy to be
   applied once the signaling messages are exchanged between the proxy
   and the devices connected to the proxy.

5.  Signaling situations

   There are different situations that require the definition of
   signaling messages.  The situations identified so far are:

   *  Multicast channel/source discovery per upstream interface: in
      order to allow the request from the host of channel and/or source
      for specific multiple upstream interfaces, it is necessary to
      retrieve such information from the proxy in advance.

   *  Multicast channel/source request from one or more upstream
      interfaces: this is a request from the host indicating candidate
      upstream interfaces for a content.

   *  Maintenance of multicast membership on the downstream interfaces
      including information of the upstream interface used per channel
      and source: this is sent by the proxy to the hosts as a means of
      informing the upstream interfaces used for the subscribed channels
      from the indicated sources.

   [RFC9279] presents extensions for both Report and Query messages.
   Then the signaling situations above should be encoded as part of
   Report and Query messages.

   For the discovery, the initial discovery request from the host to the
   proxy will be enconded as a Report message, while the answer from the
   proxy to the host will be done as a Query message.  The request of a
   channel from one or more upstream interfaces will be encoded in a
   report message.  Finally, the information of the multicast upstream
   used for a channel and a number of sources will be provided using a
   Query message.

6.  Extensions

   The following are the extensions proposed for supporting the
   signaling situations described above, using specific TLVs in
   aacordance with [RFC9279].

   Note: in this version the extensions are referred to MLD.  Extensions
   for IGMP will be provided in next versions of this document.







Contreras & Asaeda       Expires 11 January 2024                [Page 4]


Internet-Draft     Multiple upstream interfaces config         July 2023


6.1.  Report message extensions

6.1.1.  Multicast channel/source discovery per upstream interface

   By means of an extended Report message, a host will request to the
   proxy information about the upstream interface(s) and source(s)
   providing the multicast addresses indicated in the message.  When
   received by the proxy, this message will trigger a response with the
   requested information.  The multicast content will not be delivered
   to the host until another Report message not intended for discovery
   is received.

   The proposed extension format is as follows.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Discovery Request Type      |    Discovery Request Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Discovery Request Type: 2 octets.  The type of the Discovery
      Request TLV extension is TBD-1.

   *  Discovery Request Length: 2 octets.  This field specifies the
      total length in octets of the TLV.  Since no Value field is
      considered for this TLV, the length is set to 0.

6.1.2.  Request of channel/source from one or more upstream interfaces

   Using an extended Report message, a host will request to the proxy
   the subscription to one multicast group indicating the sources and
   upstream interfaces of interest.  When received by the proxy, the
   host will start receiving the content from one of the indicated
   sources and from one of the indicated upstream intrfaces.

   Note: the behavior for the incude / exclude modes will be described
   in future versions of the document.

   The proposed extension format is as follows.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Request from Upstream If Type |Request from Upstream If Length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Request from Upstream Interface Value                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Contreras & Asaeda       Expires 11 January 2024                [Page 5]


Internet-Draft     Multiple upstream interfaces config         July 2023


   where

   *  Request from Upstream Interface Type: 2 octets.  The type of the
      Request from Upstream Interface TLV extension is TBD-2.

   *  Request from Upstream Interface Length: 2 octets.  This field
      specifies the total length in octets of the TLV.

   *  Request from Upstream Interface Value: the value of this extension
      is encoded as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Mcast Address Record index =1 |M|R| Simult If |List of Ups If |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [1]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [N]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Mcast Address Record index =J |M|R| Simult If |List of Ups If |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [1]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [K]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where

   *  Multicast Address Record index enumerates the Multicast Address
      Record stated in the conventional MLD Report message.

   *  Mode (M) bit indicates if the multicast content is requested from
      more than one upstream interface for robust reception.  The bit M
      is set to 0 if the content is requested from one single upstream
      interface, and 1 if the reception is expected from multiple
      upstream interfaces simultaneously.

   *  Reserved (R) bit is reserved for future use.






Contreras & Asaeda       Expires 11 January 2024                [Page 6]


Internet-Draft     Multiple upstream interfaces config         July 2023


   *  Number of Simultaneaous Upstream Interfaces (Simult If) indicates
      the number of simultaneous interfaces from where to obtain the
      multicast flows in case the bit M is set to 1.  Otherwise, it will
      be ignored.

   *  List of Upstream Interfaces indicates the number of candidate
      upstream interfaces for the multicast address record.  This number
      should be higher or equal to the value in Simult If.  Otherwise,
      the robust reception will be ignored.  (Note: to be revisited
      after further analysis)

   *  Upstream Interface index provides the identifier of the candidate
      upstream interface.  This identifier follows the encoding in
      [RFC8343].

6.2.  Query message extensions

6.2.1.  Response for discovery of upstream interface(s) and associated
        sources for a session/channel

   The extended Query message including response for discovery extension
   will provide information to the host about the upstream interfaces
   and associated sources for multicast address groups included in the
   request of discovery message.

   The proposed extension format is as follows.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Discovery Response Type     |   Discovery Response Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Discovery Response Value                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Discovery Response Type: 2 octets.  The type of the Discovery
      Request TLV extension is TBD-3.

   *  Discovery Request Length: 2 octets.  This field specifies the
      total length in octets of the TLV.

   *  Discovery Response Value: the value of this extension is encoded
      as follows:








Contreras & Asaeda       Expires 11 January 2024                [Page 7]


Internet-Draft     Multiple upstream interfaces config         July 2023


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Source Address index = 1   |   Reserved    |List of Ups If |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [1]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [N]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Source Address index = 1   |   Reserved    |List of Ups If |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [1]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Upstream Interface index [K]                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where

   *  Source Address index enumerates the Source Address Record stated
      in the conventional MLD Query message for the Multicast Address
      Group stated there.

   *  Reserved field is reserved for future use.

   *  List of Upstream Interfaces indicates the number of candidate
      upstream interfaces for the multicast address record.  This number
      should be higher or equal to the value in Simult If.  Otherwise,
      the robust reception will be ignored.  (Note: to be revisited
      after further analysis)

   *  Upstream Interface index provides the identifier of the candidate
      upstream interface.  This identifier follows the encoding in
      [RFC8343].

6.2.2.  Maintenance of multicast membership on the downstream interfaces
        including information of the upstream interface used

   An extended Query message will provide information to the host about
   the upstream interfaces and associated sources for multicast address
   groups included in the conventional Query message.

   The proposed extension format is as follows.



Contreras & Asaeda       Expires 11 January 2024                [Page 8]


Internet-Draft     Multiple upstream interfaces config         July 2023


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Query with Ups Info Type    |   Query with Ups Info Length  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Query with Ups Info Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Query with Upstream Interface Information Type: 2 octets.  The
      type of the Discovery Request TLV extension is TBD-4.

   *  Query with Upstream Interface Information Length: 2 octets.  This
      field specifies the total length in octets of the TLV.

   *  Query with Upstream Interface Information Value: the value of this
      extension is the same as in the Discovery Response case.

7.  Security Considerations

   To be provided.

8.  IANA Considerations

   [RFC9279] describes the IANA registry for "IGMP/MLD Extension Types".
   The extensions in this document are stated in the following table.


         +===========+==========+============================+===========+
     | Ext. Type | Length   | Name                       | Reference |
     +===========+==========+============================+===========+
     | TBD-1     | 32-bit   | Discovery Request          | RFC XXXX  |
     +-----------+----------+----------------------------+-----------+
     | TBD-2     | variable | Request from Upstream If   | RFC XXXX  |
     +-----------+----------+----------------------------+-----------+
     | TBD-3     | variable | Discovery Response         | RFC XXXX  |
     +-----------+----------+----------------------------+-----------+
     | TBD-4     | variable | Query with Ups Info        | RFC XXXX  |
     +-----------+----------+----------------------------+-----------+

   In case this document progress to become an RFC, RFC XXXX should be
   substituted by the number assigned to this document.

9.  Informative References








Contreras & Asaeda       Expires 11 January 2024                [Page 9]


Internet-Draft     Multiple upstream interfaces config         July 2023


   [I-D.asaeda-pim-multiif-igmpmldproxy]
              Asaeda, H. and L. M. Contreras, "Multiple Upstream
              Interface Support for IGMP/MLD Proxy", Work in Progress,
              Internet-Draft, draft-asaeda-pim-multiif-igmpmldproxy-05,
              13 March 2023, <https://datatracker.ietf.org/doc/html/
              draft-asaeda-pim-multiif-igmpmldproxy-05>.

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

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC9279]  Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
              "Internet Group Management Protocol Version 3 (IGMPv3) and
              Multicast Listener Discovery Version 2 (MLDv2) Message
              Extension", RFC 9279, DOI 10.17487/RFC9279, August 2022,
              <https://www.rfc-editor.org/info/rfc9279>.

Authors' Addresses

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


   Hitoshi Asaeda
   NICT
   Email: asaeda@nict.go.jp



















Contreras & Asaeda       Expires 11 January 2024               [Page 10]