PIM Working Group                                              H. Asaeda
Internet-Draft                                           Keio University                                                      NICT
Intended status: Informational                                N. Leymann
Expires: October 12, 2012 April 19, 2013                              Deutsche Telekom AG
                                                          April 10,
                                                        October 16, 2012

   IGMP/MLD-Based Explicit Membership Tracking Function for Multicast


   This document describes the IGMP/MLD-based explicit membership
   tracking function for multicast routers.  The explicit tracking
   function is useful for accounting and contributes to saving network
   resource and fast leaves (i.e. shortened 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 October 12, 2012. April 19, 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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Explicit Tracking Function  . . . . . . . . . . . . . . . . . . 4
     2.1.  Reducing the Number of  Specific Queries Query Surpression Mechanism  . . . . . . . . . . . 4
     2.2.  Shortening Leave Latencies  . . . . . . . . . . . . . . . . 5
     2.3.  Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Membership State Information  . . . . . . . . . . . . . . . . . 6
   4.  Multicast Router Behavior . . . . . . . . . . . . . . . . . . . 7
   5.  Interoperability and  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Security  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

1.  Introduction

   The Internet Group Management Protocol (IGMP) [1] for IPv4 and the
   Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the
   standard protocols used by listener hosts and multicast routers.
   When a host starts listening particular multicast channels, it sends
   IGMP/MLD State-Change Report messages specifying the corresponding
   channel information as the join/leave request to its upstream router
   (i.e., an adjacent multicast router or IGMP/MLD proxy [4]).  This
   "unsolicited" Report is sent only once upon reception.

   IGMP/MLD are non-reliable protocols; the unsolicited Report messages
   may be lost or not be reached to upstream routers.  To recover the
   problem, the routers need to update membership information by sending
   IGMP/MLD General Query messages periodically.  Member hosts then
   reply with "solicited" Report messages whenever they receive the
   Query messages.

   Multicast routers are able to periodically maintain the multicast
   listener (or membership) state of downstream hosts attached on the
   same link by getting unsolicited Report messages and synchronize the
   actual membership state within the General Query timer interval
   (i.e., [Query Interval] value defined in [1][2].)  However, this
   approach does not guarantee that the membership state is always
   perfectly synchronized.  To minimize the possibility of having the
   outdated membership information, routers may shorten the periodic
   General Query timer interval.  Unfortunately, this would increase the
   number of transmitted solicited Report messages and induce network
   congestion.  And the more the network congestion is occured, occurred, the
   more IGMP/MLD Report messages may be lost and the membership state
   information may be outdated in the router.

   The IGMPv3 [1] and MLDv2 [2] protocols can provide the capability of
   keeping track of downstream (adjacent) multicast listener state to
   multicast routers.  This document describes the "IGMP/MLD-based
   explicit member tracking function" for multicast routers and details
   the way for routers to implement the function.  By enabling the
   explicit tracking function, routers can keep track of the downstream
   multicast membership state.  This function implements the following

   o  Per-host accounting

   o  Reducing the number of transmitted Query and Report messages

   o  Shortening leave latencies
   o  Maintaining multicast channel characteristics (or statistics)

   where this document mainly focuses on the above second and third
   bullets in the following sections.

   The explicit tracking function does not change message formats used
   by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight
   version protocols [3].  It does not change a multicast data sender's
   and receiver's behavior as well.

2.  Explicit Tracking Function

2.1.  Reducing the Number of  Specific Queries Query Surpression Mechanism

   The explicit tracking function reduces can reduce the number of Group-Specific Group-
   Specific or Group-and-Source Specific Query messages transmitted from
   a router, and then the number of Current-State Report messages
   transmitted from member hosts.  As the result, network resources used
   for IGMP/MLD query-and-reply communications between a router and
   member hosts can be saved.  This mechanism is called "specific query
   surpression mechanism".

   According to [1] and [2], whenever a router receives the State-Change
   Report, it sends the corresponding Group-Specific or Group-and-Source
   Specific Query messages to confirm whether the Report sender is the
   last member host or not.  After getting these Query messages, all
   member hosts joining the corresponding channel reply with own
   Current-State Report messages.  This condition requires transmitting
   a number of Current-State Report messages and consumes network
   resources especially when many hosts have been joining the same

   On the other hand, if a router enables the explicit tracking
   function, it does not need to always ask Current-State Report message
   transmission to the member hosts whenever it receives the State-
   Change Report.  This is because the explicit tracking function works
   with the expectation that the State-Change Report sender is the last
   remaining member of the channel.  Even if this expectation is wrong
   (i.e., the State-Change Report sender was not the sole member), other
   members remaining in the same channel will reply with identical
   Report messages, so the end result is the same and no problem occurs.
   (Section 3 details the point.)

   In addition, the processing of IGMP membership or MLD listener
   messages consumes CPU ressources resources on the each IGMP/MLD querier and report
   sender devices
   itself. themselves.  Therefore, the explicit tracking function
   reduces not only the network load but also the CPU load on the querier these
   devices as well.

   snooping switch [5].  If

   Note that the timer default behavior of the router that supports the
   explicit tracking function disables this specific query surpression
   mechanism, in order to refresh membership record avoid the risk caused by the situation in
   which multiple multicast routers exist on
   snooping switch a LAN and the querier
   router is shorter than not the General Query timer interval
   (i.e.  [Query Interval]), forwarder router.  When the querier surpresses the
   specific query message transmission, if it recognizes that the State-
   Change Report sender is not the sole member of the channel, it does
   not send the specific query and all routers on the same LAN do not
   receive Current-State Report message from the member hosts.  The
   forwarder in this case may prune the routing path, although there are
   other member hosts subscribing the channel on the LAN.

2.2.  Shortening Leave Latencies

   The explicit tracking function works with the expectation that the
   State-Change Report sender is the last remaining member of the
   channel.  Thanks to this functionality, a router can tune timers and
   values related to decide that the State-Change Report sender was the
   sole member.

   The [Last Member Query Interval] (LMQI) and [Last Listener Query
   Interval] (LLQI) values specify the maximum time allowed before
   sending a responding Report.  The [Last Member Query Count] (LMQC)
   and [Last Listener Query Count] (LLQC) are the number of Group-
   Specific Queries or Group-and-Source Specific Queries sent before the
   router assumes there are no local members.  The [Last Member Query
   Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the
   total time the router should wait for a report, after the Querier has
   sent the first query.

   The default values for LMQI/LLQI defined in the standard
   specifications [1][2] are 1 second.  For the router enabling the
   explicit tracking function, LMQI/LLQI would be set to 1 second or
   shorter.  The LMQC/LLQC may be set to "1" for the router, whereas
   their default values are the [Robustness Variable] value whose
   default value is "2".  Smaller LMQC/LLQC give smaller LMQT/LLQT; this
   condition shortens the leave latencies.

2.3.  Considerations

   As with the basic concepts of IGMP and MLD, the explicit tracking
   function does not guarantee the membership state is always perfectly
   synchronized; routers enabling the explicit tracking function still
   need to send IGMPv3/MLDv2 Query messages and inquire solicited
   IGMPv3/MLDv2 Report messages from downstream members to maintain
   downstream membership state.

   o  IGMP/MLD messages are non-reliable and may be lost in the
      transmission, therefore routers need to confirm the membership by
      sending Query messages.

   o  To preserve compatibility with older versions of IGMP/MLD, routers
      need to support downstream hosts that are not upgraded to the
      latest versions of IGMP/MLD and run the report suppression

   o  It is impossible to identify hosts when hosts send IGMP reports
      with a source address of

   Regarding the last bullet, the IGMPv3 specification [1] mentions that
   an IGMPv3 Report is usually sent with a valid IP source address,
   although it permits that a host uses the source address (as
   it happens that the host has not yet acquired an IP address), and
   routers MUST accept a report with a source address of  The
   MLDv2 specification [2] mentions that an MLDv2 Report MUST be sent
   with a valid IPv6 link-local source address, although an MLDv2 Report
   can be sent with the unspecified address (::), if the sending
   interface has not acquired a valid link-local address yet. [2] also
   mentions that routers silently discard a message that is not sent
   with a valid link-local address or sent with the unspecified address,
   without taking any action, because of the security consideration.

   Another concern is that the explicit tracking function requires
   additional processing capability and a possibly large memory for
   routers to keep all membership states.  Especially when a router
   needs to maintain a large number of member hosts, this resource
   requirement may be potentially-impacted.  Operators may decide to
   disable this function when their routers do not have enough memory

3.  Membership State Information

   The explicit tracking function is implemented with the following
   membership state information:

      (S, G, number of receivers, (receiver records))

   where each receiver record is of the form:

      (IGMP/MLD Membership/Listener Report sender's address)

   This state information must work properly when a receiver (i.e.,
   Report sender) sends the same Report messages multiple times.

   In the state information, each "S" and "G" indicates a single IPv4/
   IPv6 address.  "S" is set to "Null" for an Any-Source Multicast (ASM)
   communication (i.e., (*,G) join reception).  In order to simplify the
   implementation, the explicit tracking function does not keep the
   state of (S,G) join with EXCLUDE filter mode.  If a router receives
   (S,G) join/leave request with EXCLUDE filter mode from the downstream
   hosts, it translates the join/leave request to (*,G) join state/leave
   request and records the state and the receivers' addresses into the
   maintained membership state information.  Note that this membership
   state translation does not change the routing protocol behavior; the
   routing protocol must deal with the original join/leave request and
   translate the request only for the membership state information.

4.  Multicast Router Behavior

   The explicit tracking function makes routers expect whether the
   State-Change Report sender is the last remaining member of the
   channel.  Therefore the router transmits a corresponding Current-
   State Report message only when the router thinks that the State-
   Change Report sender is the last remaining member of the channel.
   This contributes to saving the network resources and also shortening
   leave latency.

   To synchronize the membership state information, when a multicast
   router receives a Current-State or State-Change Report message, it
   adds the receiver IP address to or delete from the receiver records
   or creates the corresponding membership state information.  If there
   are no more receiver records left, the membership state information
   is deleted from the router.

   However, the membership state information may be still outdated in
   the router.  It may be happened especially in a mobile multicast
   environment that some member hosts have joined to or left from the
   network without sending State-Change Report messages.  Or, some
   State-Change Report messages are lost due to network congestion.
   Therefore, the router enabling the explicit tracking function ought
   to send the periodic General Query regularly.

   Regarding the leave latency, as specified in Section 2.2, the
   explicit tracking function contributes to the fast leave by setting
   LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1".  However, if
   LMQC/LLQC is configured "2" or bigger value, then the router's
   behavior may be changed from the standard specification.  According
   to [1] and [2], a router sends a Group- (and-Source) Specific Query
   [LMQC - 1] or [LLQC - 1] times when it receives State Change Report
   message (e.g. leave request) from a member host, in order to confirm
   whether or not the host is the only remaining member.  However, this
   document RECOMMENDS that if the router enabling the explicit tracking
   function receives the corresponding Current State Report before the
   Specific Query retransmission, it cancels sending the same Specific
   Query for other [LMQC - 1] or [LLQC - 1] times.

   Note that there is some risk that a router misses or looses Report
   messages sent from remaining members if the router adopts small LMQC/
   LLQC; however the wrong expectation would be lower happened for the
   router enabling the explicit tracking function.  And to avoid the
   problem, a router can start sending a Group- (and-Source) Specific
   Query message when it expects the number of the remaining members is
   small, such as 5, but not 0.

5.  Interoperability and  Compatibility

   The explicit tracking function does not work with the older versions
   of IGMP or MLD, IGMPv1 [6], [5], IGMPv2 [7] [6] or MLDv1 [8], [7], because a member
   host using these protocols adopts a report suppression mechanism by
   which a host would cancel sending a pending membership Reports if a
   similar Report was observed from another member on the network.

   If a multicast router enabling the explicit tracking function changes
   its compatibility mode to the older versions of IGMP or MLD, the
   router should turn off the explicit tracking function but should not
   flush the maintained membership state information (i.e., keep the
   current membership state information as is).  When the router changes
   back to IGMPv3 or MLDv2 mode, it would resume the function with the
   kept membership state information, even if the state information is
   outdated.  This manner would give "smooth state transition" that does
   not initiate the membership state from scratch and synchronizes the
   actual membership state smoothly.

   There are several points TBD in the further discussions regarding the
   interoperability and compatibility issues.  At first, it is necessary
   whether a multicast router enabling the explicit tracking function
   needs to detect adjacent routers that do not support the explicit
   tracking function on the link or not.  After the clarification, this

6.  IANA Considerations

   This document will describe the method how to detect them.  It would be
   done by a new signaling message, but the new message leads
   compatibility problems has no actions for older routers or other routing protocols
   such as PIM-DM.  All of these discussions are TBD.

6. IANA.

7.  Security Considerations

   There is no additional security considerations.


8.  Acknowledgements

   Toerless Eckert, Stig Venaas, and others provided many constructive
   and insightful comments.


9.  References

9.1.  Normative References

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

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

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


9.2.  Informative References

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

   [5]  Christensen, M., Kimball, K., and F. Solensky, "Considerations
        for Internet Group Management Protocol (IGMP) and Multicast
        Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.

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


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


   [7]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, October 1999.

Authors' Addresses

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-0882
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795

   Email: asaeda@wide.ad.jp
   URI:   http://web.sfc.wide.ad.jp/~asaeda/ asaeda@nict.go.jp
   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781

   Email: n.leymann@telekom.de