wdiff draft-asaeda-pim-mldproxy-multif-00.txt draft-asaeda-pim-mldproxy-multif-01.txt

PIM Working Group H. Asaeda
Internet-Draft NICT
Intended status: Standards Track S. Jeon
Expires: April 18, August 29, 2013 S. Jeon
Institute de Telecomunicacoes
October 15, 2012
February 25, 2013

Multiple Upstream Interfaces Interface Support for IGMP/MLD Proxy
draft-asaeda-pim-mldproxy-multif-00
draft-asaeda-pim-mldproxy-multif-01

Abstract

This document describes the way of supporting multiple upstream
interfaces for an IGMP/MLD proxy device. The proposed extension
enables that an IGMP/MLD proxy device receives multicast packets
through multiple upstream interfaces, so that it interfaces. The upstream interface is useful for
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

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 April 18, August 29, 2013.

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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
3. Upstream Interface Selection Per-Channel Load Balancing . . . . . . . . . . . . . . . . . . 4
3.1. Basic Operation
4. Candidate Upstream Interface Configuration . . . . . . . . . . 5
4.1. Supported Address Prefix . . . . . . . . . . . . 4
3.2. Supported Address Prefix . . . . . 5
4.2. Interface Priority . . . . . . . . . . . . 5
3.3. . . . . . . . . 7
4.3. Default Interface Priority . . . . . . . . . . . . . . . . . . . . 6
4. . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 8

1. Introduction

The Internet Group Management Protocol (IGMP) [1][2][3][4] [1][2] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [5][6][4] [3][2] for IPv6 are the
standard protocols for hosts to initiate joining or leaving of
multicast sessions. The IGMP/MLD A proxy [7] device performing IGMP/MLD-based
forwarding (as known as IGMP/MLD proxy) [4] maintains multicast
membership information by IGMP/MLD protocols on the downstream
interfaces and forwards sends IGMP/MLD membership report messages via the
upstream interface to the upstream multicast routers. 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
IGMP/MLD-based forwarding (as known as [4], an IGMP/MLD proxy) proxy has *a
single* 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
downstream interfaces, and the host portion of IGMP/MLD on its
upstream interface. The proxy device must not perform the router
portion of IGMP/MLD on its upstream interface.

On the other hand, there are requirements that is a scenario in which an IGMP/MLD proxy
device allows to use enables multiple upstream interfaces and receives multicast
packets through these interfaces. For example, a proxy device having
more than two interfaces one interface may want to access to different networks,
such as Internet and Intranet. 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 adds the way of supporting the scenario in which
an IGMP/MLD proxy device enables to manually configure "multiple candidate upstream
interfaces" and receives multicast packets through these interfaces.
An
interfaces for an IGMP/MLD proxy device selects a and select "one" single
upstream interface from
configured candidate upstream interfaces per IGMP/MLD records; same IGMP/MLD
records MUST NOT be transmitted from different session/
channel. When the selected upstream interface is down or disabled,
one of the other candidate upstream interfaces
simultaneously. takes over the
upstream interface (if configured). This enables "per-channel load
balancing".

Note that this document does not make any changes to the
IGMPv3 and MLDv2 protocols, and only adds specifies the functionality way to configure multiple per-
channel load balancing; it does not specify any intelligent
mechanism/algorithm (e.g., based on link or network condition/usage)
or threshold value to select an upstream interface from candidate
upstream interfaces on to improve data reception quality. Also, an
IGMP/MLD proxy device by
operation. Therefore, this document does not provide any mechanism
to "dynamically configure" select multiple upstream interfaces, and provides
a mechanism interfaces
for the same channels/sessions simultaneously; enabling redundant
paths to "manually configure" an receive duplicate packets via multiple upstream interface by
operation. interfaces
to improve data reception quality or robustness for a session/channel
is out of scope of this document.

2. Terminology

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

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

Upstream interface (or selected upstream interface):
A proxy device's interface in the direction of the root of the
multicast forwarding tree. An upstream interface is selected by
either manual or automatic configuration.

Downstream interface:
Each of a proxy device's interfaces that is not in the direction of
the root of the multicast forwarding tree.

Configured

Candidate upstream interface:
An interface that potentially becomes an upstream interface of the
proxy device.

3. Upstream Interface Selection

3.1. Basic Operation

An IGMP/MLD proxy device maintains a database consisting of the
merger of all subscriptions Candidate upstream interfaces are manually set up on any downstream interface. It sends
an IGMP/MLD membership report messages on proxy.

Supported address prefix:
The supported address prefix is the address prefix for which a
candidate upstream interface when
the database changes (e.g., by receiving solicited/unsolicited report
messages). supposes to be an upstream interface.
The supported source address prefix and the supported multicast
address prefix an IGMP/MLD proxy device then forwards appropriate can configure. The supported
address prefix in this document means both source and multicast
packets received on its
address prefixes, unless otherwise specified.

3. Per-Channel Load Balancing

An IGMP/MLD proxy device enables "per-channel load balancing" using
multiple upstream interface interfaces to each downstream receive different multicast sessions/
channel through the different upstream interfaces. Per-channel load
balancing makes an IGMP/MLD proxy device select "one" single upstream
interface from candidate upstream interfaces per session/channel,
based on the downstream interface's subscriptions.

The multicast forwarding tree must configurations, which will be manually configured by
designating upstream and downstream interfaces on described in Section 4.

If an IGMP/MLD IGMP proxy
device, and the root of the tree recognizes that an adjacent upstream router is expected not
working, the selected upstream interface attached to that router can
be connected taken over with the different candidate upstream interface. Or,
if the selected upstream interface is going down, the proxy would
switch from the inactive interface to a
wider multicast infrastructure. the other active upstream
interface. This document provides "take-over operation" recursively examines the way
configurations of
supporting the scenario in which candidate upstream interfaces (except the
disabled interface) and decides a new upstream interface from them.

Whether the upstream router is active or not would be decided by
checking a link condition or IGMP/MLD query message transmission.
However, this document does not describe how an IGMP/MLD proxy device enables to
configure multiple can
detect the upstream interfaces router's condition and receives multicast packets
through these interfaces.

Configured when it takes that
interface over the different candidate upstream interfaces MUST be manually set up interface.

The take-over operation is enabled by operation.
An default. When it is disabled
(by operation), even if no data comes from the selected upstream
interface, the IGMP/MLD proxy device MUST NOT select keeps using that interface as
the upstream interface for the corresponding sessions/channels.

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 the same a session/channel;
therefore IGMP/MLD records, and hence report messages containing the same IGMP/MLD
records
MUST NOT be are not transmitted through from different upstream interfaces.

Regarding interfaces
simultaneously.

4. Candidate Upstream Interface Configuration

Candidate upstream interfaces are the case that a interfaces from which an IGMP/
MLD proxy device receives multicast packets on
its downstream interface, it forwards the packets to each downstream selects as an upstream interface. They are manually
enabled. The upstream interface selection is done based on the downstream interface's subscriptions. A proxy
device forwards packets received on any downstream interface to the
configured upstream interfaces,
"supported address prefix" and to each downstream interface
other than the incoming interface based upon the downstream
interfaces' subscriptions.

3.2. "interface priority" value.

4.1. Supported Address Prefix

The

An IGMP/MLD proxy device MAY configure the "supported address prefixes" MAY be configured prefix"
for each
configured candidate upstream interface by operation. The supported address
prefix is expressed by the following information:

(multicast address prefix, source address prefix)

An IGMP/MLD interface. A proxy device selects an upstream
interface from its
configured candidate upstream interfaces based on the configuration
configured supported address prefix. The supported address prefix is
manually configured. The supported address prefix consists of the
supported
following information:

(source address prefixes. prefix, multicast address prefix)

When the proxy device transmits an IGMP/
MLD 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
a wildcard. If no address prefix value is configured on a configured candidate
upstream interface, a wildcard value (i.e., the default value) value is implicitly set up for the configured
candidate upstream interface. 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 configured candidate upstream interface, the decision whether the configured
candidate upstream interface is selected as the upstream interface or
not is made by the "interface priority" value defined described in
Section 3.3.

There 4.2.

The same address prefix may be configured on different candidate
upstream interfaces. As well as the case that one above-mentioned default
configuration, when the same address prefix is configured on
different candidate upstream interfaces, an upstream interface for
that address prefix is
configured with specific selected based on each interface priority
value described in Section 4.2.

For upstream interface selection, source address prefix takes
priority over multicast address prefixes (i.e., non
wildcard value) and the other configured prefix. This avoids conflict of
upstream interface is
configured selection. For example, consider the case that an
IGMP/MLD proxy device has a configuration with specific source address prefixes. In this case, prefix
S_p for the
proxy device may need to transmit 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 the supported source address
prefix of the configured upstream interface A, S_p, and whose multicast address, let's say G, is in the range of the supported multicast address
prefix of the configured upstream interface B. For such case,
G_p, the proxy device selects the configured candidate upstream interface A,
which supports the source address prefix, as the upstream interface,
and
then transmits the (S,G) record is transmitted via the interface A.

The same address prefix MUST NOT be configured on different
configured

Obviously, an IGMP/MLD proxy selects a candidate upstream interfaces. If the same interface
having supported source and multicast address prefix is
configured on different configured upstream interfaces, prefixes that address
prefix configuration is ignored include
both source and warned multicast address, rather than the mis-configuration.

3.3. other one whose
supported source and multicast address prefixes includes either
source or multicast address.

4.2. Interface Priority

Each configured upstream interface SHOULD have

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.

The interface priority value effects only when the following
conditions are 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 configured by more than one candidate upstream
interface.

o Neither source nor multicast address is included in the supported
address prefixes configured by operation. 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
configured by more than one candidate upstream interface.

In these conditions, the candidate upstream interface with the
highest priority is chosen as the upstream interface. If there

4.3. Default Interface

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 configured candidate upstream interfaces
interfaces, and all of the these candidate upstream interfaces' priorities
are identical, identical.

o Neither source nor multicast address is included in the supported
address prefixes configured by any of the candidate upstream interface having lower IP
interfaces, and all candidate upstream interfaces' priorities are
identical.

o The supported source address prefix is selected as not configured or does not
include the upstream interface.

The default value of source address, and the interface priority multicast address is 0.

4. 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][2][3][4][5][6]. [1][3][2]. Therefore there is no
additional security consideration provided.

6. provided for these protocols.

7. Normative References

[1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.

[2] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, July 1997.

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

[4]

[2] 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] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

[6]

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

[7]

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

[8]

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

Authors' Addresses

Hitoshi Asaeda
National Institute of Information and Communications Technology (NICT)
Network Architecture Laboratory
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan

Email: asaeda@nict.go.jp

Seil Jeon
Institute de Telecomunicacoes
Campus Universitario de Santiago
Aveiro 3810-193
Portugal

Email: seiljeon@av.it.pt