PIM Working Group H. Asaeda
Internet-Draft K. Matsuzono
Expires: September 24, 2015 NICT
March 23, 2015
Multiple Upstream Interface Support for IGMP/MLD Proxy
draft-asaeda-pim-multiif-igmpmldproxy-00
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 pre-configured supported address
prefixes and interface priority value. A mechanism for upstream
interface takeover that switches 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 http://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 September 24, 2015.
Copyright Notice
Copyright (c) 2015 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
(http://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 extracted from this document must
Asaeda & Matsuzono Expires September 24, 2015 [Page 1]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
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
4. Upstream Interface Takeover . . . . . . . . . . . . . . . . . 5
5. Candidate Upstream Interface Configuration . . . . . . . . . 6
5.1. Subscriber Address Prefix and Supported Address Prefix . 7
5.2. Interface Priority . . . . . . . . . . . . . . . . . . . 8
5.3. Active Interval . . . . . . . . . . . . . . . . . . . . . 8
5.4. Default Upstream Interface . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
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
Asaeda & Matsuzono Expires September 24, 2015 [Page 2]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
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).
This document describes the mechanism that makes an IGMP/MLD proxy
device enable 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 pre-configured candidate upstream interfaces "per
channel/session". By subscriber-based upstream selection, an IGMP/
MLD proxy device selects one or multiple upstream interface(s) from
pre-configured 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 improves the robustness of 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 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.
Asaeda & Matsuzono Expires September 24, 2015 [Page 3]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
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 manually 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.
Candidate upstream interface:
An interface that potentially becomes an upstream interface of the
proxy device. A list of candidate upstream interfaces with supported
address prefixes is manually configured on an IGMP/MLD proxy device.
Supported address prefix:
The supported address prefix is the address prefix for which a
candidate upstream interface supposes to be an upstream interface for
specified multicast sessions/channels. The supported source address
prefix and the supported multicast address prefix an IGMP/MLD proxy
device can configure.
Asaeda & Matsuzono Expires September 24, 2015 [Page 4]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
3. Upstream Selection Mechanism
3.1. Channel-Based Upstream Selection
Channel-based upstream selection enables a proxy device to use one or
multiple upstream interface(s) per session/channel from the
"candidate upstream interfaces" based on the "supported address
prefix" configuration (as will be in Section 5.1).
A proxy device selects a candidate upstream interface having
supported source and multicast address prefixes that include both
source and multicast address, rather than the other one whose
supported source and multicast address prefixes includes either
source or multicast address.
When more than one candidate upstream interfaces are configured with
the same source and multicast addresses as the supported address
prefixes and the interface priority values 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 configuration does not guarantee that
the packets come from disjoint paths. It only configures that the
adjacent upstream routers are different.
3.2. Subscriber-Based Upstream Selection
Subscriber-based upstream selection 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 5.1).
It is also possible to configure both supported address prefix
(described in Section 3.1) and subscriber address prefix. If both
prefixes are configured, the configuration of subscriber address
prefix is prioritized.
4. Upstream Interface Takeover
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 supported address
prefix can act as a new upstream interface. It recursively examines
the list of the candidate upstream interfaces (except the disabled
Asaeda & Matsuzono Expires September 24, 2015 [Page 5]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
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
of the following behaviors based on the configuration; (1) it only
uses the active upstream interface(s) and does not add (i.e.,
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 transmitted by
the upstream router (e.g., because of enabling the explicit tracking
function [7]). 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. 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 and supported address prefix" and "interface priority"
value.
Asaeda & Matsuzono Expires September 24, 2015 [Page 6]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
5.1. Subscriber Address Prefix and Supported Address Prefix
An IGMP/MLD proxy device can configure the "subscriber address
prefix" and "supported address prefix" for each candidate upstream
interface. A proxy selects an upstream interface from its candidate
upstream interfaces based on the configuration below:
(subscriber address prefix, source address prefix, multicast
address prefix)
If network operators want to select specific upstream interface(s)
without depending on subscriber address prefix, subscriber address
prefix in this record is "null". 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 this record is "null".
The default values of subscriber address prefix and both source and
multicast address prefixes are "null". If the default value is set
up on a candidate upstream interface, the decision whether the
candidate upstream interface is selected as the upstream interface or
not is made by the "interface priority" value described in
Section 5.2.
The wildcard multicast address prefix is represented by the entire
multicast address range (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8'
for IPv6). The wildcard source address prefix is represented by any
host. If the default value is set up on a candidate upstream
interface, the decision whether the candidate upstream interface is
selected as the upstream interface or not is made by the "interface
priority" value.
The same address prefix may be configured on different candidate
upstream interfaces. As well as the above-mentioned default
configuration, 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 described in Section 5.2.
For upstream interface selection, source address prefix takes
priority over multicast address prefix. This avoids conflict of
upstream interface selection. 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
Asaeda & Matsuzono Expires September 24, 2015 [Page 7]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
interface A, which supports the source address prefix, as the
upstream interface, and transmits the (S,G) record via the interface
A.
5.2. Interface Priority
An IGMP/MLD proxy device can configure the "interface priority" value
for each candidate upstream interface. It is an integer value and
manually configured. 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 configure the supported
address prefix.
o Both source and multicast addresses are included in the supported
address prefixes for more than one candidate upstream interface.
o Neither source nor multicast address is included in the supported
address prefixes for any of the candidate upstream interfaces.
o The supported source address prefix is not configured or does not
include the source address, but (on the other hand) the multicast
address is included in the supported multicast address prefix for
more than one candidate upstream interface.
In these conditions, the candidate upstream interface with the
highest priority is chosen as the upstream interface. And as stated
in Section 3.1, if the priority values for candidate upstream
interfaces are identical, all of these interfaces act as the upstream
interfaces for the supported address prefix and may receive duplicate
packets.
5.3. 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. [TBD]
Asaeda & Matsuzono Expires September 24, 2015 [Page 8]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
5.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 configure the supported address prefix
and interface priority value, or with either of the following
conditions.
o Neither source nor multicast address is included in the supported
address prefixes for any of the candidate upstream interfaces, and
all candidate upstream interfaces' priorities are identical.
o The supported source address prefix is not configured or does not
include the source address, and the multicast address is included
in the supported multicast address prefix for more than one
candidate upstream interface, yet these candidate upstream
interfaces' priorities are identical.
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.
6. IANA Considerations
This document has no actions for IANA.
7. 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.
8. References
Asaeda & Matsuzono Expires September 24, 2015 [Page 9]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
8.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., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
8.2. Informative References
[7] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking
Function for Multicast Routers", draft-ietf-pim-explicit-
tracking-11 (work-in-progress), March 2015.
Authors' Addresses
Hitoshi Asaeda
National Institute of Information and Communications Technology
Network Research Headquarters
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: asaeda@nict.go.jp
Asaeda & Matsuzono Expires September 24, 2015 [Page 10]
Internet-Draft Multiple Upstream for IGMP/MLD Proxy March 2015
Kazuhisa Matsuzono
National Institute of Information and Communications Technology
Network Architecture Laboratory
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: matsuzono@nict.go.jp
Asaeda & Matsuzono Expires September 24, 2015 [Page 11]