Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Hitoshi Asaeda , Seil Jeon
Last updated 2012-10-15
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-asaeda-pim-mldproxy-multif-00
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]