PIM Working Group L. Contreras
Internet-Draft Telefonica
Intended status: Standards Track H. Asaeda
Expires: 25 April 2024 NICT
23 October 2023
Signaling-based configuration for supporting multiple upstream
interfaces in IGMP/MLD proxies
draft-contreras-pim-multiif-config-01
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 25 April 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 25 April 2024 [Page 1]
Internet-Draft Multiple upstream interfaces config October 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Report message extensions . . . . . . . . . . . . . . . . 5
6.1.1. Multicast channel/source information retrieval per
upstream interface . . . . . . . . . . . . . . . . . 5
6.1.2. Request of channel/source from one or more upstream
interfaces . . . . . . . . . . . . . . . . . . . . . 6
6.2. Query message extensions . . . . . . . . . . . . . . . . 8
6.2.1. Response for information retrieval of upstream
interface(s) and associated sources for a session/
channel . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. Maintenance of multicast membership on the downstream
interfaces including information of the upstream
interface used . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 25 April 2024 [Page 2]
Internet-Draft Multiple upstream interfaces config October 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 25 April 2024 [Page 3]
Internet-Draft Multiple upstream interfaces config October 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 information retrieval 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 information retrieval, the initial information retrieval
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.
+---------+ +---------+
| Proxy | | Host |
+---------+ +---------+
| |
| Report extension |
|<------------------------|
| (Section 6.1.1) |
| |
| |
| Query extension |
|------------------------>|
| (Section 6.2.1) |
| |
| |
Contreras & Asaeda Expires 25 April 2024 [Page 4]
Internet-Draft Multiple upstream interfaces config October 2023
The request of a channel from one or more upstream interfaces will be
encoded in a report message.
+---------+ +---------+
| Proxy | | Host |
+---------+ +---------+
| |
| Report extension |
|<------------------------|
| (Section 6.1.2) |
| |
| |
Finally, the information of the multicast upstream used for a channel
and a number of sources will be provided using a Query message.
+---------+ +---------+
| Proxy | | Host |
+---------+ +---------+
| |
| Query extension |
|------------------------>|
| (Section 6.2.2) |
| |
| |
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.
6.1. Report message extensions
6.1.1. Multicast channel/source information retrieval 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 information
retrieval is received.
Contreras & Asaeda Expires 25 April 2024 [Page 5]
Internet-Draft Multiple upstream interfaces config October 2023
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info. Retrieval Req. Type | Info. Retrieval Req. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Information Retrieval Request Type: 2 octets. The type of the
Information Retrieval Request TLV extension is TBD-1.
* Information Retrieval 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
Contreras & Asaeda Expires 25 April 2024 [Page 6]
Internet-Draft Multiple upstream interfaces config October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
* 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)
Contreras & Asaeda Expires 25 April 2024 [Page 7]
Internet-Draft Multiple upstream interfaces config October 2023
* 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 information retrieval of upstream interface(s) and
associated sources for a session/channel
The extended Query message including response for information
retrieval extension will provide information to the host about the
upstream interfaces and associated sources for multicast address
groups included in the request of information retrieval 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info. Retrieval Resp. Type | Info. Retrieval Resp. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Retrieval Response Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Information Retrieval Response Type: 2 octets. The type of the
Information Retrieval Request TLV extension is TBD-3.
* Information Retrieval Request Length: 2 octets. This field
specifies the total length in octets of the TLV.
* Information Retrieval Response Value: the value of this extension
is encoded as follows:
Contreras & Asaeda Expires 25 April 2024 [Page 8]
Internet-Draft Multiple upstream interfaces config October 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 25 April 2024 [Page 9]
Internet-Draft Multiple upstream interfaces config October 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 Information Retrieval 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 Information Retrieval 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 | Info. Retrieval Request | RFC XXXX |
+-----------+----------+----------------------------+-----------+
| TBD-2 | variable | Request from Upstream If | RFC XXXX |
+-----------+----------+----------------------------+-----------+
| TBD-3 | variable | Info. Retrieval 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
[I-D.asaeda-pim-multiif-igmpmldproxy]
Asaeda, H. and L. M. Contreras, "Multiple Upstream
Interface Support for IGMP/MLD Proxy", Work in Progress,
Contreras & Asaeda Expires 25 April 2024 [Page 10]
Internet-Draft Multiple upstream interfaces config October 2023
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 25 April 2024 [Page 11]