PIM Working Group                                              H. Asaeda
Internet-Draft                                                      NICT
Intended status: Standards Track                       February 25,                           July 15, 2013
Expires: August 29, 2013 January 16, 2014

   IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
                                Routers
                  draft-ietf-pim-explicit-tracking-05
                  draft-ietf-pim-explicit-tracking-06

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 fast leaves (i.e. shortening leave latency). latency, and enables operators to see
   which downstream routers(s) on a LAN are joined to which multicast
   tree.

Status of this 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 August 29, 2013. January 16, 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Explicit Tracking Function  Membership State Information  . . . . . . . . . . . . . . . .   4
   4.  Specific Query Suppression  . .  4
     3.1.  Membership State Information . . . . . . . . . . . . . . .   4
     3.2.  Specific Query Suppression
   5.  Shortening Leave Latency  . . . . . . . . . . . . . . . .  5
     3.3.  Shortening Leave Latency . .   5
   6.  Risk of Wrong Membership State  . . . . . . . . . . . . . . .   6
   4.  Lowering the Possibility of Outdated Membership State  . . . .  7
   5.
   7.  All-Zero and Unspecified Source Addresses . . . . . . . . . .  8
   6.   7
   8.  Compatibility with Older Version Protocols  . . . . . . . . . .  8
   7.   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  9
   8.   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  9
   9.   8
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  9
   10.   8
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.
     12.1.  Normative References . . . . . . . . . . . . . . . . . . .   9
     10.2.
     12.2.  Informative References . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 10   9

1.  Introduction

   The Internet Group Management Protocol (IGMP) version 3 [1] [2] for IPv4
   and the Multicast Listener Discovery Protocol (MLD) version 2 [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) [3] [4] are subsets of the standard IGMPv3 and MLDv2.

   When a host starts/finishes listening to 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 device [5]). [8]).  The "unsolicited" report messages are sent only
   when the host joins/leaves the channels.  Since IGMP/MLD are non-reliable protocols; the non-
   reliable protocols, unsolicited report messages may be lost or may
   not reach upstream routers.  To alleviate the problem, routers need to update membership information by
   periodically sending IGMP/MLD General Query messages.  Member hosts
   then reply with "solicited" unsolicited
   report messages whenever they receive the
   query messages.

   Multicast routers are capable of periodically maintaining the
   multicast membership state of downstream hosts attached to transmitted the same
   link by acquiring unsolicited report [Robustness Variable] times
   (defined in [2][3]).

   Also, a querier router periodically sends IGMP/MLD General Query
   messages and synchronizing the
   actual membership state within the General Query timer interval
   (i.e., (i.e. [Query
   Interval] value defined in [1][2].) [2][3]).  Upon receiving the query
   messages, the member hosts reply with "solicited" report messages.
   Routers then keep their membership state information up to date.
   However, this approach still does not guarantee that the membership
   state is always perfectly synchronized.  To minimize the possibility
   of having outdated membership information, routers may shorten the
   periodic General Query timer interval.  Unfortunately, this increases
   the number of transmitted solicited report messages and induces
   network congestion.  And the greater the amount of network
   congestion, the greater the potential for IGMP/MLD report messages
   being lost and the membership state information being outdated in the
   router.

   The

   IGMPv3 [1] and [2], MLDv2 [2] protocols [3], and these lightweight protocols [3] [4] can
   provide the ability to keep track of the downstream (adjacent)
   multicast membership state to multicast routers, yet the
   specifications are not clearly given.  This document describes the
   "IGMP/MLD-based explicit member tracking function" for multicast
   routers and details a way for routers to implement the function.  By enabling
   this explicit tracking function, routers can keep track of the
   downstream multicast membership state.  This function enables the
   following:
   following things:

   o  Reducing the number of transmitted query and report messages

   o  Shortening leave latencies

   o  Per-host accounting

   o  Maintaining multicast channel characteristics (or statistics)

   In addition, the processing of IGMP membership or MLD listener
   messages consumes CPU resources

   where this document mainly focuses on individual IGMP/MLD querier the above first and
   report sender devices.  The explicit tracking function therefore
   reduces not only second
   bullets in the network load but also following sections.

   Note that the CPU load on these
   devices.

   The explicit tracking function does not guarantee that change the membership
   state will always be perfectly synchronized;
   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 ought 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.

   The explicit tracking state,
   while the function potentially requires a large amount of
   memory contributes to saving network resources by tuning
   query timers or values.

   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 [1] [2] and MLDv2 [2], [3], and their lightweight
   version protocols [3]; [4]; nor does it change a multicast data sender's
   and receiver's behavior.

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 [4]. [1].

3.  Explicit Tracking Function

3.1.  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 or adds or deletes the receiver IP
   address to or from it.  If there are no more receivers maintained,
   the router may keep maintain the membership state information with an empty
   receiver list. up
   to date.

   The membership state information consists of is also known as the following
   information:

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

   where each receiver record is of
   "interface state" defined by the form:

      (IGMP/MLD membership/listener report sender's address)

   This standard IGMPv3 and MLDv2
   specifications [2][3].

      (multicast address, filter mode, source list)

   The membership state information must work be identified properly when even
   though a receiver (i.e.,
   report IGMP/MLD Report sender) sends the identical
   report messages multiple times.

   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, the explicit tracking function MAY NOT keep the state
   of (S,G) joined with EXCLUDE filter mode.  In that case, 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.  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.

3.2.

4.  Specific Query Suppression

   In accordance with [1] [2] and [2], whenever [3], when a router receives the State-
   Change Report, it 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 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 confirm whether be
   transmitted [Last Member Query Count] (LMQC) or not the
   report sender is [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 host.  All 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 send then reply their own Current-State Report messages states after acquiring
   these query messages.  Transmitting  However, transmitting a large number of
   Current-State 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 can reduce provides a method called "specific
   query suppression" that reduces the number of Group-
   Specific Group-Specific or
   Group-and-Source Specific Query messages transmitted from a router, and reduce router.
   This in turn reduces the number of Current-State Report messages
   transmitted from member hosts.  If a router enables

   With the explicit
   tracking function with "specific query suppression", it suppresses specific query transmission and transmits specific query messages
   only when the router expects that the State-Change Report sender is
   the sole member suppression, regardless of the channel, based on its membership state
   information (expressed in Section 3.1).

   As standard behavior for [1] and [2], a LMQC/LLQC
   values, if the router also sends a Group-
   Specific or Group-and-Source Specific Query multiple times when it receives a State Change Report message (e.g., leave request) from a
   member host.  This is in order to confirm whether one or not more replies from the host is
   downstream member(s), it can stop (i.e., cancel) retransmitting the sole member.  However, if
   specific query message(s) and lower the router enabling corresponding source/group
   timers.  This contributes to saving network resources.

   The specific query suppression in "hard state" may also be
   implemented with the explicit tracking function runs function; a router enabling
   the specific query suppression in hard state does not send any
   specific query message(s) and receives one immediately leave the group or
   more replies for sources
   when the sole member has left according to its membership state
   information.  The specific query retransmission from the
   downstream member(s), 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 can cancel resending perfectly tracks all member hosts.
   (See a risk of the
   identical specific query message(s). 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
   suppression, in order to avoid the risk caused by the situation 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.  When  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 State-Change Report sender is not
   the sole member of the channel, it does not send the specific query
   and none of the routers on the same LAN receive a Current-State
   Report message from the corresponding member hosts.  The forwarder in
   this case may prune the routing path though there are other member
   hosts subscribing to the channel on the LAN.

3.3.

5.  Shortening Leave Latency

   A router enabling the explicit tracking function can shorten leave
   latencies by tuning several timers and values to what it expects
   whether or not the State-Change Report sender is the channel's sole
   member. following values; [Last Member Query Count]
   (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query
   Interval] (LMQI), [Last Listener Query Interval] (LLQI), and
   [Robustness Variable] values.

   The [Last Member Query Interval] (LMQI) and [Last Listener Query
   Interval] (LLQI) values defined in the standard specifications [2][3]
   specify the maximum time allowed for a member host to send a
   responding Report before the router prunes the channel
   from the network. 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 value values for LMQI/LLQI defined in the standard
   specifications [1][2] is [2][3] are 1 second.  For second, yet,
   for a router enabling the explicit tracking function, the LMQI/LLQI MAY
   may be set to 1 second or shorter.  The LMQC/LLQC values MAY be set to 1 for  As well, the router,
   whereas their default values for
   LMQC/LLQC are the [Robustness Variable] value
   whose default value is 2. [Robustness Variable] value whose default value is
   2, yet the LMQC/LLQC may be set to 1 for the router.  Smaller LMQC/LLQC LMQC/
   LLQC values give smaller shorter LMQT/LLQT, which shortens shorten the leave
   latencies.  On

   Furthermore, if operators believe that their link is fairly robust or
   that they can configure the other hand, [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.

   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 4. 6.  Operators setting smaller LMQC/LLQC
   values must recognize this tradeoff.

4.  Lowering the Possibility

6.  Risk of Outdated Wrong Membership State

   There are possibilities that a router enables the explicit tracking
   function but its router's membership expectation will be 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.  These cases are particularly likely for a router that
   enables specific query suppression (as in Section 3.2) and configures
   small LMQC/LLQC for shortening leave latency (as in Section 3.3).

   The first of these cases case may occur in an environment where the sole member host
   departs the network without sending a State-Change Report message.  This is because a router enabling specific query
   suppression does not send a specific query if it believes the report
   sender is not the sole member host.
   The router later detects that there is no member host for the
   corresponding channels when it does not receive a Current-State
   Report within the timeout of the response for the periodic General Query.
   Query (and then the group or source timers are expired).  However,
   this situation prolongs leave latency and wastes network resources
   since the router forwards unneeded traffic until that point. for a while.

   The second case occurs when a router sends a specific query but does
   not receive a State-Change Current-State Report from a downstream host within an
   LMQT or LLQT period.  It recognizes that no member host exists on the
   LAN and might prune the routing path.  The router reestablishes the
   routing path when it receives the solicited report message for the
   channels.  However, the downstream hosts may loose the data packets
   until the routing path is reestablished and the data forwarding is
   restarted.

   In order to reduce the possibility of the incorrect membership
   expectation and keep the up-to-date membership state information,
   when a router enabling the explicit tracking function enables
   specific query suppression,

   If operators do not believe that their link is fairly robust or that
   they can configure the router SHOULD [Robustness Variable] value appropriately,
   they may configure the LMQC/LLQC value to 2 (the default value of the
   [Robustness Variable] value) or
   higher; or, when a router enabling bigger value for their routers.  In
   this case, the routers would enable the explicit tracking function
   configures a small LMQC/LLQC,
   but may want to disable the router SHOULD NOT enable specific query suppression.

5. suppression specified in
   Section 4.  Such configurations will not contribute to saving network
   resources, but reduce the risk of the incorrect membership
   expectation.

7.  All-Zero and Unspecified Source Addresses

   The IGMPv3 specification [1] [2] mentions that an IGMPv3 report is
   usually sent with a valid IP source address, yet it permits a host to
   use the 0.0.0.0 source address (since the host has not yet acquired
   an IP address), and routers must accept a report with this source
   address.  The MLDv2 specification [2] mentions that an MLDv2 report
   must be sent with a valid IPv6 link-local source address, yet an
   MLDv2 report may be sent with the unspecified address (::) if the
   sending interface has not acquired a valid link-local address. [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 security
   considerations.

   When a router enabling the explicit tracking function receives IGMP/
   MLD IGMP
   report messages with an all-zero or unspecified source address, it deals with the IGMP/MLD
   IGMP report messages correctly as defined in
   [1][2] [2] and continuously
   keeps track of the membership state, but state.  However, the router SHOULD NOT
   maintain the host specifying all-zero or an unspecified source address in its
   membership state information.

6.  The router will maintain its
   membership state information by checking Current-State reports as
   ordinary routers do.

   On the other hand, the MLDv2 specification [3] mentions that routers
   silently discard a message that is sent with an invalid link-local
   address or sent with the unspecified address (::), without taking any
   action, because of security considerations.  According to this
   specification, whether the explicit tracking function is used or not,
   a router does not deal with a member hosts sending an MLD report
   message with the unspecified source address.

8.  Compatibility with Older Version Protocols

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

   To preserve compatibility with older versions of IGMP/MLD, routers
   need to
   supporting IGMPv3/MLDv2 enable the host compatibility mode defined in
   [2][3].  The host compatibility mode of an interface changes the
   operational protocol version on the LAN whenever an older version
   query (than the current compatibility mode) is heard or when certain
   timer conditions occur.  The routers can hence support downstream
   hosts that are not upgraded to the latest versions and run membership
   report suppression.

   Therefore, if a multicast router enabling the explicit tracking function changes its
   compatibility mode to the older versions, the router SHOULD disable
   the explicit tracking function.  On the other hand, the router MAY
   NOT flush the maintained membership state information.  When supporting IGMPv3/MLDv2 and enabling
   the
   router explicit tracking function changes back its compatibility mode to IGMPv3 or MLDv2 mode, it resumes the function
   with the old membership state information even if
   older versions, the state
   information is outdated.  This provides "smooth state transition"
   that does not initiate router SHOULD disable the membership state information from scratch
   and synchronizes explicit tracking
   function while it acts as the actual membership state smoothly.

7. older version router.

9.  IANA Considerations

   This document has no actions for IANA.

8.

10.  Security Considerations

   The explicit tracking function potentially requires a large amount of
   memory so that routers keep all membership states.  Especially when  It gives some
   impact in the cases where (1) a router attaches to a link or an IGMP/
   MLD proxy device [8] that has a large number of member hosts, and a
   router has insufficient memory resources to maintain a large number
   of member hosts, or (2) a malicious hosts send host sends a large number of
   invalid IGMP/MLD report
   messages, messages.

   For the first case, operators may disable the explicit tracking
   function, despite the benefits mentioned above.  For the second case,
   some serious threats may be induced.  In order to prevent abuse, a
   router enabling the explicit tracking function MAY may need to
   rate-limit limit a
   total amount of membership information the router can store and an
   amount of membership information the router can store per host.

   A router may rate-limit State-Change Report messages per host.  When
   the router enables rate-limiting per host, the router MAY ignore the
   received State-Change Report messages to minimize the processing
   overhead or prevent DoS attacks.  The rate limit is left to the
   router's implementation.

9.

11.  Acknowledgements
   Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi,
   Nicolai Leymann, Stig Venaas, and others provided many constructive
   and insightful comments.

10.

12.  References

10.1.

12.1.  Normative References

   [1]        Bradner, S., "Key words for use in RFCs to indicate
              requirement levels", RFC 2119, March 1997.

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

   [2]

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

   [3]

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

   [4]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

10.2.

12.2.  Informative References

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

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

   [7]

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

   [8]

   [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 Architecture Laboratory Research Headquarters
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: asaeda@nict.go.jp