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]