PIM Working Group H. Asaeda
Internet-Draft NICT
Intended status: Standards Track S. Jeon
Expires: April 18, 2013 Institute de Telecomunicacoes
October 15, 2012
Multiple Upstream Interfaces Support for IGMP/MLD Proxy
draft-asaeda-pim-mldproxy-multif-00
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 is useful for
multihoming support.
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, 2013.
Copyright Notice
Copyright (c) 2012 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
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Asaeda & Jeon Expires April 18, 2013 [Page 1]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Upstream Interface Selection . . . . . . . . . . . . . . . . . 4
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Supported Address Prefix . . . . . . . . . . . . . . . . . 5
3.3. Interface Priority . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Asaeda & Jeon Expires April 18, 2013 [Page 2]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
1. Introduction
The Internet Group Management Protocol (IGMP) [1][2][3][4] for IPv4
and the Multicast Listener Discovery Protocol (MLD) [5][6][4] for
IPv6 are the standard protocols for hosts to initiate joining or
leaving of multicast sessions. The IGMP/MLD proxy [7] maintains
multicast membership information by IGMP/MLD protocols on the
downstream interfaces and forwards IGMP/MLD report via the upstream
interface to the upstream multicast routers.
According to the specification of [7], a proxy device performing
IGMP/MLD-based forwarding (as known as IGMP/MLD proxy) has *a single*
upstream interface and one or more downstream interfaces. It
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 an IGMP/MLD proxy
device allows to use multiple upstream interfaces. For example, a
proxy device having more than two interfaces 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 the way of supporting the scenario in which
an IGMP/MLD proxy device enables to configure "multiple upstream
interfaces" and receives multicast packets through these interfaces.
An IGMP/MLD proxy device selects a single upstream interface from
configured upstream interfaces per IGMP/MLD records; same IGMP/MLD
records MUST NOT be transmitted from different upstream interfaces
simultaneously. This document does not make any changes to the
IGMPv3 and MLDv2 protocols, and only adds the functionality to
configure multiple upstream interfaces on an IGMP/MLD proxy device by
operation. Therefore, this document does not provide any mechanism
to "dynamically configure" multiple upstream interfaces, and provides
a mechanism to "manually configure" an upstream interface by
operation.
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].
Asaeda & Jeon Expires April 18, 2013 [Page 3]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
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.
Downstream interface:
Each of a proxy device's interfaces that is not in the direction of
the root of the multicast forwarding tree.
Configured 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 on any downstream interface. It sends
IGMP/MLD membership report messages on the upstream interface when
the database changes (e.g., by receiving solicited/unsolicited report
messages). The proxy device then forwards appropriate multicast
packets received on its upstream interface to each downstream
interface based on the downstream interface's subscriptions.
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. This document provides the way of
supporting the scenario in which an IGMP/MLD proxy device enables to
configure multiple upstream interfaces and receives multicast packets
through these interfaces.
Configured upstream interfaces MUST be manually set up by operation.
An IGMP/MLD proxy device MUST NOT select multiple upstream interfaces
for the same IGMP/MLD records, and hence the same IGMP/MLD records
MUST NOT be transmitted through different upstream interfaces.
Regarding the case that a proxy device receives multicast packets on
its downstream interface, it forwards the packets to each downstream
interface based on the downstream interface's subscriptions. A proxy
device forwards packets received on any downstream interface to the
configured upstream interfaces, and to each downstream interface
other than the incoming interface based upon the downstream
interfaces' subscriptions.
Asaeda & Jeon Expires April 18, 2013 [Page 4]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
3.2. Supported Address Prefix
The "supported address prefixes" MAY be configured for each
configured upstream interface by operation. The supported address
prefix is expressed by the following information:
(multicast address prefix, source address prefix)
An IGMP/MLD proxy device selects an upstream interface from its
configured upstream interfaces based on the configuration of the
supported address prefixes. 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
a wildcard. If no address prefix value is configured on a configured
upstream interface, a wildcard value (i.e., default value) is
implicitly set up for the configured 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 upstream
interface, the decision whether the configured upstream interface is
selected as the upstream interface or not is made by the "interface
priority" value defined in Section 3.3.
There may be the case that one configured upstream interface is
configured with specific multicast address prefixes (i.e., non
wildcard value) and the other configured upstream interface is
configured with specific source address prefixes. In this case, the
proxy device may need to transmit an IGMP/MLD record whose source
address, say S, is in the range of the supported source address
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
configured upstream interfaces. If the same address prefix is
configured on different configured upstream interfaces, that address
prefix configuration is ignored and warned the mis-configuration.
Asaeda & Jeon Expires April 18, 2013 [Page 5]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
3.3. Interface Priority
Each configured upstream interface SHOULD have the "interface
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.
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This document neither provides new functions nor modifies the
standard functions defined in [1][2][3][4][5][6]. Therefore there is
no additional security consideration provided.
6. 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] 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] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Asaeda & Jeon Expires April 18, 2013 [Page 6]
Internet-Draft Multiple Upstream IFs for IGMP/MLD Proxy October 2012
Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006.
[8] 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
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
Asaeda & Jeon Expires April 18, 2013 [Page 7]