--- 1/draft-ietf-pim-explicit-tracking-06.txt 2013-07-31 15:14:28.339438065 -0700 +++ 2/draft-ietf-pim-explicit-tracking-07.txt 2013-07-31 15:14:28.363438681 -0700 @@ -1,78 +1,76 @@ PIM Working Group H. Asaeda Internet-Draft NICT -Intended status: Standards Track July 15, 2013 -Expires: January 16, 2014 +Intended status: Standards Track July 31, 2013 +Expires: February 01, 2014 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers - draft-ietf-pim-explicit-tracking-06 + draft-ietf-pim-explicit-tracking-07 Abstract This document describes the IGMP/MLD-based explicit membership - tracking function for multicast routers supporting IGMPv3/MLDv2. The - explicit membership tracking function contributes to saving network - resources and shortening leave latency, and enables operators to see - which downstream routers(s) on a LAN are joined to which multicast - tree. + tracking function for multicast routers and IGMP/MLD proxy devices + supporting IGMPv3/MLDv2. The explicit membership tracking function + contributes to saving network resources and shortening leave latency. 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 January 16, 2014. + This Internet-Draft will expire on February 01, 2014. Copyright Notice Copyright (c) 2013 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Membership State Information . . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 - 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 5 + 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 - 8. Compatibility with Older Version Protocols . . . . . . . . . 7 + 8. Compatibility with Older Version Protocols . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for IPv6 are the standard protocols used by member hosts and multicast routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. When a host starts/finishes listening to particular multicast @@ -119,26 +117,24 @@ o Maintaining multicast channel characteristics (or statistics) where this document mainly focuses on the above first and second bullets in the following sections. Note that the explicit tracking function does not change the reliability of the message transmission. The list of tracked member hosts may be outdated in the router because of host departure from the network without sending State-Change Report messages or loss of - such messages due to network congestion. Therefore, a router even - enabling the function may need to send periodic IGMPv3/MLDv2 General - Query messages and solicit IGMPv3/MLDv2 report messages from - downstream member hosts to maintain an up-to-date membership state, - while the function contributes to saving network resources by tuning - query timers or values. + such messages due to network congestion. Therefore, a router + enabling the function may still need to send periodic IGMPv3/MLDv2 + General Query messages and solicit IGMPv3/MLDv2 report messages from + downstream member hosts to maintain an up-to-date membership state. The explicit tracking function potentially requires a large amount of memory so that routers keep all membership states. Particularly when a router needs to maintain a large number of member hosts, this resource requirement could have an impact. Operators may decide to disable this function when their routers have insufficient memory resources, despite the benefits mentioned above. The explicit tracking function does not change message formats used by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight @@ -152,72 +147,88 @@ this document are to be interpreted as described in RFC 2119 [1]. 3. Membership State Information A router enabling the explicit tracking function maintains the "membership state information". When a multicast router receives a Current-State or State-Change Report message, it creates or modifies this membership state information to maintain the membership state up to date. - The membership state information is also known as the following - "interface state" defined by the standard IGMPv3 and MLDv2 - specifications [2][3]. + The membership state information consists of the following + information: - (multicast address, filter mode, source list) + (S, G, number of receivers, (receiver records)) + + where each receiver record is of the form: + + (IGMP/MLD membership/listener report sender's address) + + In the state information, each S and G indicates a single IPv4/IPv6 + address. S is set to "Null" for Any-Source Multicast (ASM) + communication (i.e., (*,G) join reception). In order to simplify the + implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of + (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G) + join/leave request with EXCLUDE filter mode from the downstream + hosts, the router translates the request to a (*,G) join state/leave + request and records the state and the receivers' addresses in the + maintained membership state information. The membership state information must be identified properly even though a receiver (i.e., IGMP/MLD Report sender) sends the identical report messages multiple times. 4. Specific Query Suppression In accordance with [2] and [3], when a router receives the State- Change Report and needs to confirm whether any hosts are still interested in a channel or not, the router sends the corresponding - Group-Specific or Group-and-Source Specific Query messages along with - the definition of Section 6.4.2 of [2] and Section 7.4.2 of [3]. The - queries sent by actions defined in these sections need to be - transmitted [Last Member Query Count] (LMQC) or [Last Listener Query - Count] (LLQC) times, once every [Last Member Query Interval] (LMQI) - or [Last Listener Query Interval] (LLQI), in order to confirm the - sole member. (The default values for LMQI/LLQI defined in [2][3] are - 1 second. The default values for LMQC/LLQC are the [Robustness - Variable] value whose default value is 2.) All member hosts joining - the identical channel then reply their own states after acquiring - these query messages. However, transmitting a large number of IGMP/ - MLD Report messages consumes network resources, and this may pose a - particular problem especially when many hosts joining the identical - channel send these reports simultaneously. + Group-Specific or Group-and-Source Specific Query messages as defined + in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent + by actions defined in these sections need to be transmitted [Last + Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) + times, once every [Last Member Query Interval] (LMQI) or [Last + Listener Query Interval] (LLQI), in order to confirm the sole member. + (The default values for LMQI/LLQI defined in [2][3] are 1 second. + The default values for LMQC/LLQC are the [Robustness Variable] value + whose default value is 2.) All member hosts joining the identical + channel then reply their own states after acquiring these query + messages. However, transmitting a large number of IGMP/MLD Report + messages consumes network resources, and this may pose a particular + problem especially when many hosts joining the identical channel send + these reports simultaneously. The explicit tracking function provides a method called "specific query suppression" that reduces the number of Group-Specific or Group-and-Source Specific Query messages transmitted from a router. This in turn reduces the number of Current-State Report messages transmitted from member hosts. With the specific query suppression, regardless of the LMQC/LLQC values, if the router receives one or more replies from the downstream member(s), it can stop (i.e., cancel) retransmitting the - specific query message(s) and lower the corresponding source/group - timers. This contributes to saving network resources. + specific query message(s). This contributes to saving network + resources. - The specific query suppression in "hard state" may also be - implemented with the explicit tracking function; a router enabling - the specific query suppression in hard state does not send any - specific query message(s) and immediately leave the group or sources - when the sole member has left according to its membership state - information. The specific query suppression in hard state hence does - not rely on LMQC/LLQC and LMQI/LLQI values. This contributes to - shortening leave latency described in Section 5. However, this - behavior requires that the router perfectly tracks all member hosts. - (See a risk of wrong membership expectation described in Section 6.) + If the router is confident that the tracked membership state + information is perfectly synchronized with the current (actual) + member hosts, the specific query suppression in a "robust link state" + may also be implemented with the explicit tracking function. A + router enabling the specific query suppression in a robust link state + does not send any specific query message(s) and immediately leave the + group or sources when the sole member has left according to its + membership state information. The specific query suppression in a + robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI + values. This contributes to shortening leave latency described in + Section 5. However, this behavior requires that the router perfectly + tracks all member hosts. (See a risk of wrong membership expectation + described in Section 6.) Note that the default behavior of the router that supports the explicit tracking function SHOULD disable this specific query suppression, in order to avoid the risk caused by the wrong membership expectation or by the case in which multiple multicast routers exist on a LAN and the querier router is not the forwarder router. The former case is described in Section 6. For the latter case, when the querier suppresses the specific query message transmission, and expects that the State-Change Report sender is not the sole member of the channel, it does not send the specific query @@ -252,27 +263,27 @@ 2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/ LLQC values give shorter LMQT/LLQT, which shorten the leave latencies. Furthermore, if operators believe that their link is fairly robust or that they can configure the [Robustness Variable] value appropriately so that the chances of unsolicited messages being lost are sufficiently low, and if the querier router is always the forwarder router in their link, they will set smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query - suppression or enable the specific query suppression in hard state - (Section 4) for their routers. + suppression or enable the specific query suppression in a robust link + state (Section 4) for their routers. Note that setting smaller LMQC/LLQC values or adopting the specific - query suppression in hard state poses the risk of wrong membership - state described in Section 6. Operators setting smaller LMQC/LLQC - values must recognize this tradeoff. + query suppression in a robust link state poses the risk of wrong + membership state described in Section 6. Operators setting smaller + LMQC/LLQC values must recognize this tradeoff. 6. Risk of Wrong Membership State There are possibilities that a router's membership expectation is inconsistent due to an outdated membership state. For example, (1) a router expects that more than one corresponding member host exists on its LAN, but in fact no member host exists for that multicast channel, or (2) a router expects that no corresponding member host exists on its LAN, but in fact one or more than one member host exists for that multicast channel. @@ -414,18 +426,18 @@ [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [8] 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. Author's Address + Hitoshi Asaeda - National Institute of Information and Communications Technology (NICT) - Network Research Headquarters + National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp