< draft-asaeda-pim-mldproxy-multif-00.txt   draft-asaeda-pim-mldproxy-multif-01.txt >
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track S. Jeon Expires: August 29, 2013 S. Jeon
Expires: April 18, 2013 Institute de Telecomunicacoes Institute de Telecomunicacoes
October 15, 2012 February 25, 2013
Multiple Upstream Interfaces Support for IGMP/MLD Proxy Multiple Upstream Interface Support for IGMP/MLD Proxy
draft-asaeda-pim-mldproxy-multif-00 draft-asaeda-pim-mldproxy-multif-01
Abstract Abstract
This document describes the way of supporting multiple upstream This document describes the way of supporting multiple upstream
interfaces for an IGMP/MLD proxy device. The proposed extension interfaces for an IGMP/MLD proxy device. The proposed extension
enables that an IGMP/MLD proxy device receives multicast packets enables that an IGMP/MLD proxy device receives multicast packets
through multiple upstream interfaces, so that it is useful for through multiple upstream interfaces. The upstream interface is
multihoming support. selected with manually configured supported address prefixes and
interface priority value. A take-over operation switching from an
inactive upstream interface to an active upstream interface is also
considered.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Upstream Interface Selection . . . . . . . . . . . . . . . . . 4 3. Per-Channel Load Balancing . . . . . . . . . . . . . . . . . . 4
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . . 4 4. Candidate Upstream Interface Configuration . . . . . . . . . . 5
3.2. Supported Address Prefix . . . . . . . . . . . . . . . . . 5 4.1. Supported Address Prefix . . . . . . . . . . . . . . . . . 5
3.3. Interface Priority . . . . . . . . . . . . . . . . . . . . 6 4.2. Interface Priority . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Default Interface . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [1][2][3][4] for IPv4 The Internet Group Management Protocol (IGMP) [1][2] for IPv4 and the
and the Multicast Listener Discovery Protocol (MLD) [5][6][4] for Multicast Listener Discovery Protocol (MLD) [3][2] for IPv6 are the
IPv6 are the standard protocols for hosts to initiate joining or standard protocols for hosts to initiate joining or leaving of
leaving of multicast sessions. The IGMP/MLD proxy [7] maintains multicast sessions. A proxy device performing IGMP/MLD-based
multicast membership information by IGMP/MLD protocols on the forwarding (as known as IGMP/MLD proxy) [4] maintains multicast
downstream interfaces and forwards IGMP/MLD report via the upstream membership information by IGMP/MLD protocols on the downstream
interface to the upstream multicast routers. 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 [7], a proxy device performing According to the specification of [4], an IGMP/MLD proxy has *a
IGMP/MLD-based forwarding (as known as IGMP/MLD proxy) has *a single* single* upstream interface and one or more downstream interfaces.
upstream interface and one or more downstream interfaces. It 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 performs the router portion of the IGMP or MLD protocol on its
downstream interfaces, and the host portion of IGMP/MLD on its downstream interfaces, and the host portion of IGMP/MLD on its
upstream interface. The proxy device must not perform the router upstream interface. The proxy device must not perform the router
portion of IGMP/MLD on its upstream interface. portion of IGMP/MLD on its upstream interface.
On the other hand, there are requirements that an IGMP/MLD proxy On the other hand, there is a scenario in which an IGMP/MLD proxy
device allows to use multiple upstream interfaces. For example, a device enables multiple upstream interfaces and receives multicast
proxy device having more than two interfaces may want to access to packets through these interfaces. For example, a proxy device having
different networks, such as Internet and Intranet. Or, a proxy more than one interface may want to access to different networks,
device having wired link (e.g., ethernet) and high-speed wireless such as Internet and Intranet. Or, a proxy device having wired link
link (e.g., WiMAX or LTE) may want to have the capability to connect (e.g., ethernet) and high-speed wireless link (e.g., WiMAX or LTE)
to the Internet through both links. These proxy devices shall may want to have the capability to connect to the Internet through
receive multicast packets from the different upstream interfaces and both links. These proxy devices shall receive multicast packets from
forward to the downstream interface(s). the different upstream interfaces and forward to the downstream
interface(s).
This document describes the way of supporting the scenario in which This document adds the way to manually configure candidate upstream
an IGMP/MLD proxy device enables to configure "multiple upstream interfaces for an IGMP/MLD proxy device and select "one" single
interfaces" and receives multicast packets through these interfaces. upstream interface from candidate upstream interfaces per session/
An IGMP/MLD proxy device selects a single upstream interface from channel. When the selected upstream interface is down or disabled,
configured upstream interfaces per IGMP/MLD records; same IGMP/MLD one of the other candidate upstream interfaces takes over the
records MUST NOT be transmitted from different upstream interfaces upstream interface (if configured). This enables "per-channel load
simultaneously. This document does not make any changes to the balancing".
IGMPv3 and MLDv2 protocols, and only adds the functionality to
configure multiple upstream interfaces on an IGMP/MLD proxy device by Note that this document only specifies the way to configure per-
operation. Therefore, this document does not provide any mechanism channel load balancing; it does not specify any intelligent
to "dynamically configure" multiple upstream interfaces, and provides mechanism/algorithm (e.g., based on link or network condition/usage)
a mechanism to "manually configure" an upstream interface by or threshold value to select an upstream interface from candidate
operation. upstream interfaces to improve data reception quality. Also, an
IGMP/MLD proxy device does not select multiple upstream interfaces
for the same channels/sessions simultaneously; enabling redundant
paths to receive duplicate packets via multiple upstream interfaces
to improve data reception quality or robustness for a session/channel
is out of scope of this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [8]. this document are to be interpreted as described in RFC 2119 [5].
In addition, the following terms are used in this document. In addition, the following terms are used in this document.
Upstream interface (or selected upstream interface): Upstream interface (or selected upstream interface):
A proxy device's interface in the direction of the root of the A proxy device's interface in the direction of the root of the
multicast forwarding tree. multicast forwarding tree. An upstream interface is selected by
either manual or automatic configuration.
Downstream interface: Downstream interface:
Each of a proxy device's interfaces that is not in the direction of Each of a proxy device's interfaces that is not in the direction of
the root of the multicast forwarding tree. the root of the multicast forwarding tree.
Configured upstream interface: Candidate upstream interface:
An interface that potentially becomes an upstream interface of the An interface that potentially becomes an upstream interface of the
proxy device. proxy device. Candidate upstream interfaces are manually set up on
an IGMP/MLD proxy.
3. Upstream Interface Selection Supported address prefix:
The supported address prefix is the address prefix for which a
candidate upstream interface supposes to be an upstream interface.
The supported source address prefix and the supported multicast
address prefix an IGMP/MLD proxy device can configure. The supported
address prefix in this document means both source and multicast
address prefixes, unless otherwise specified.
3.1. Basic Operation 3. Per-Channel Load Balancing
An IGMP/MLD proxy device maintains a database consisting of the An IGMP/MLD proxy device enables "per-channel load balancing" using
merger of all subscriptions on any downstream interface. It sends multiple upstream interfaces to receive different multicast sessions/
IGMP/MLD membership report messages on the upstream interface when channel through the different upstream interfaces. Per-channel load
the database changes (e.g., by receiving solicited/unsolicited report balancing makes an IGMP/MLD proxy device select "one" single upstream
messages). The proxy device then forwards appropriate multicast interface from candidate upstream interfaces per session/channel,
packets received on its upstream interface to each downstream based on the configurations, which will be described in Section 4.
interface based on the downstream interface's subscriptions.
The multicast forwarding tree must be manually configured by If an IGMP proxy recognizes that an adjacent upstream router is not
designating upstream and downstream interfaces on an IGMP/MLD proxy working, the selected upstream interface attached to that router can
device, and the root of the tree is expected to be connected to a be taken over with the different candidate upstream interface. Or,
wider multicast infrastructure. This document provides the way of if the selected upstream interface is going down, the proxy would
supporting the scenario in which an IGMP/MLD proxy device enables to switch from the inactive interface to the other active upstream
configure multiple upstream interfaces and receives multicast packets interface. This "take-over operation" recursively examines the
through these interfaces. configurations of the candidate upstream interfaces (except the
disabled interface) and decides a new upstream interface from them.
Configured upstream interfaces MUST be manually set up by operation. Whether the upstream router is active or not would be decided by
An IGMP/MLD proxy device MUST NOT select multiple upstream interfaces checking a link condition or IGMP/MLD query message transmission.
for the same IGMP/MLD records, and hence the same IGMP/MLD records However, this document does not describe how an IGMP/MLD proxy can
MUST NOT be transmitted through different upstream interfaces. detect the upstream router's condition and when it takes that
interface over the different candidate upstream interface.
Regarding the case that a proxy device receives multicast packets on The take-over operation is enabled by default. When it is disabled
its downstream interface, it forwards the packets to each downstream (by operation), even if no data comes from the selected upstream
interface based on the downstream interface's subscriptions. A proxy interface, the IGMP/MLD proxy device keeps using that interface as
device forwards packets received on any downstream interface to the the upstream interface for the corresponding sessions/channels.
configured upstream interfaces, and to each downstream interface
other than the incoming interface based upon the downstream
interfaces' subscriptions.
3.2. Supported Address Prefix Per-channel load balancing does not implement duplicate packet
reception from redundant paths using multiple upstream interfaces to
improve data reception quality or robustness for a session/channel;
therefore IGMP/MLD report messages containing the same IGMP/MLD
records are not transmitted from different upstream interfaces
simultaneously.
The "supported address prefixes" MAY be configured for each 4. Candidate Upstream Interface Configuration
configured upstream interface by operation. The supported address
prefix is expressed by the following information:
(multicast address prefix, source address prefix) Candidate upstream interfaces are the interfaces from which an IGMP/
MLD proxy device selects as an upstream interface. They are manually
enabled. The upstream interface selection is done based on
"supported address prefix" and "interface priority" value.
An IGMP/MLD proxy device selects an upstream interface from its 4.1. Supported Address Prefix
configured upstream interfaces based on the configuration of the
supported address prefixes. When the proxy device transmits an IGMP/ An IGMP/MLD proxy device MAY configure the "supported address prefix"
MLD report message, it examines the source and multicast addresses in for each candidate upstream interface. A proxy selects an upstream
the IGMP/MLD records of the report message and transmits the interface from its candidate upstream interfaces based on the
appropriate IGMP/MLD report message(s) from the selected upstream configured supported address prefix. The supported address prefix is
interface(s) that are configured with the range of the supported manually configured. The supported address prefix consists of the
source and multicast address prefixes. following information:
(source address prefix, multicast address prefix)
When the proxy device transmits an IGMP/MLD report message, it
examines the source and multicast addresses in the IGMP/MLD records
of the report message and transmits the appropriate IGMP/MLD report
message(s) from the selected upstream interface(s) that are
configured with the range of the supported source and multicast
address prefixes.
The default values of both source and multicast address prefixes are The default values of both source and multicast address prefixes are
a wildcard. If no address prefix value is configured on a configured a wildcard. If no address prefix value is configured on a candidate
upstream interface, a wildcard value (i.e., default value) is upstream interface, the default value is implicitly set up for the
implicitly set up for the configured upstream interface. The candidate upstream interface. The wildcard multicast address prefix
wildcard multicast address prefix is represented by the entire is represented by the entire multicast address range (i.e.,
multicast address range (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8' '224.0.0.0/4' for IPv4 or 'ff00::/8' for IPv6). The wildcard source
for IPv6). The wildcard source address prefix is represented by any address prefix is represented by any host. If the default value is
host. If the default value is set up on a configured upstream set up on a candidate upstream interface, the decision whether the
interface, the decision whether the configured upstream interface is candidate upstream interface is selected as the upstream interface or
selected as the upstream interface or not is made by the "interface not is made by the "interface priority" value described in
priority" value defined in Section 3.3. Section 4.2.
There may be the case that one configured upstream interface is The same address prefix may be configured on different candidate
configured with specific multicast address prefixes (i.e., non upstream interfaces. As well as the above-mentioned default
wildcard value) and the other configured upstream interface is configuration, when the same address prefix is configured on
configured with specific source address prefixes. In this case, the different candidate upstream interfaces, an upstream interface for
proxy device may need to transmit an IGMP/MLD record whose source that address prefix is selected based on each interface priority
address, say S, is in the range of the supported source address value described in Section 4.2.
prefix of the configured upstream interface A, and whose multicast
address, say G, is in the range of the supported multicast address
prefix of the configured upstream interface B. For such case, the
proxy device selects the configured upstream interface A, which
supports the source address prefix, as the upstream interface, and
then the (S,G) record is transmitted via the interface A.
The same address prefix MUST NOT be configured on different For upstream interface selection, source address prefix takes
configured upstream interfaces. If the same address prefix is priority over multicast address prefix. This avoids conflict of
configured on different configured upstream interfaces, that address upstream interface selection. For example, consider the case that an
prefix configuration is ignored and warned the mis-configuration. 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.
3.3. Interface Priority Obviously, an IGMP/MLD proxy 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.
Each configured upstream interface SHOULD have the "interface 4.2. Interface Priority
priority" value. The priority value is configured by operation. The
configured upstream interface with the highest priority is chosen as
the upstream interface. If there is more than one configured
upstream interfaces and all of the priorities are identical, the
configured upstream interface having lower IP address is selected as
the upstream interface.
The default value of the interface priority is 0. An IGMP/MLD proxy device MAY 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.
4. IANA Considerations The interface priority value effects only when the following
conditions are satisfied.
This document has no actions for IANA. o None of the candidate upstream interfaces configure the supported
address prefix.
5. Security Considerations o Both source and multicast addresses are included in the supported
address prefixes configured by more than one candidate upstream
interface.
This document neither provides new functions nor modifies the o Neither source nor multicast address is included in the supported
standard functions defined in [1][2][3][4][5][6]. Therefore there is address prefixes configured by any of the candidate upstream
no additional security consideration provided. interfaces.
6. Normative References 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
configured by more than one candidate upstream interface.
[1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, In these conditions, the candidate upstream interface with the
August 1989. highest priority is chosen as the upstream interface.
[2] Fenner, W., "Internet Group Management Protocol, Version 2", 4.3. Default Interface
RFC 2236, July 1997.
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. In the following conditions, the candidate upstream interface whose
IPv4/v6 address is lowest is selected as the upstream interface for
that session/channel.
o None of the candidate upstream interfaces configure the supported
address prefix and interface priority value.
o Both source and multicast addresses are included in the supported
address prefixes configured by more than one candidate upstream
interfaces, and these candidate upstream interfaces' priorities
are identical.
o Neither source nor multicast address is included in the supported
address prefixes configured by 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 configured by more than
one candidate upstream interface, yet these candidate upstream
interfaces' priorities are identical.
5. IANA Considerations
This document has no actions for IANA.
6. Security Considerations
This document neither provides new functions nor modifies the
standard functions defined in [1][3][2]. Therefore there is no
additional security consideration provided for these protocols.
7. Normative References
[1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group [2] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
[5] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[6] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet [4] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006. RFC 4605, August 2006.
[8] Bradner, S., "Key words for use in RFCs to indicate requirement [5] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology (NICT)
Network Architecture Laboratory
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
Seil Jeon Seil Jeon
Institute de Telecomunicacoes Institute de Telecomunicacoes
Campus Universitario de Santiago Campus Universitario de Santiago
Aveiro 3810-193 Aveiro 3810-193
 End of changes. 43 change blocks. 
149 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/