draft-ietf-pim-explicit-tracking-07.txt   draft-ietf-pim-explicit-tracking-08.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track July 31, 2013 Intended status: Standards Track October 07, 2013
Expires: February 01, 2014 Expires: April 10, 2014
IGMP/MLD-Based Explicit Membership Tracking Function for Multicast IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
Routers Routers
draft-ietf-pim-explicit-tracking-07 draft-ietf-pim-explicit-tracking-08
Abstract Abstract
This document describes the IGMP/MLD-based explicit membership This document describes the IGMP/MLD-based explicit membership
tracking function for multicast routers and IGMP/MLD proxy devices tracking function for multicast routers and IGMP/MLD proxy devices
supporting IGMPv3/MLDv2. The explicit membership tracking function supporting IGMPv3/MLDv2. The explicit membership tracking function
contributes to saving network resources and shortening leave latency. contributes to saving network resources and shortening leave latency.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 01, 2014. This Internet-Draft will expire on April 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Membership State Information . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4
5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6
6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7
7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7
8. Compatibility with Older Version Protocols . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4
and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for
IPv6 are the standard protocols used by member hosts and multicast IPv6 are the standard protocols used by member hosts and multicast
routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and
LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
the corresponding channel information as the join/leave request to the corresponding channel information as the join/leave request to
its upstream router (i.e., an adjacent multicast router or IGMP/MLD its upstream router (i.e., an adjacent multicast router or IGMP/MLD
proxy device [8]). The "unsolicited" report messages are sent only proxy device [8]). The "unsolicited" report messages are sent only
when the host joins/leaves the channels. Since IGMP/MLD are non- when the host joins/leaves the channels. Since IGMP/MLD are non-
reliable protocols, unsolicited report messages may be lost or may reliable protocols, unsolicited report messages may be lost or may
not reach upstream routers. To alleviate the problem, unsolicited not reach upstream routers. To alleviate the problem, unsolicited
report messages are transmitted the [Robustness Variable] times report messages are transmitted the [Robustness Variable] times
(defined in [2][3]). (defined in [2][3]).
Also, a querier router periodically sends IGMP/MLD General Query Also, a querier router periodically sends IGMP/MLD General Query
messages within the General Query timer interval (i.e. [Query messages every General Query timer interval (i.e. [Query Interval]
Interval] value defined in [2][3]). Upon receiving the query value defined in [2][3]). Upon receiving the query messages, the
messages, the member hosts reply with "solicited" report messages. member hosts reply with "solicited" report messages. Routers then
Routers then keep their membership state information up to date. keep their membership state information up to date. However, this
However, this approach still does not guarantee that the membership approach still does not guarantee that the membership state is always
state is always perfectly synchronized. To minimize the possibility perfectly synchronized. To minimize the possibility of having
of having outdated membership information, routers may shorten the outdated membership information, routers may shorten the periodic
periodic General Query timer interval. Unfortunately, this increases General Query timer interval. Unfortunately, this increases the
the number of transmitted solicited report messages and induces number of transmitted solicited report messages and induces network
network congestion. And the greater the amount of network congestion. And the greater the amount of network congestion, the
congestion, the greater the potential for IGMP/MLD report messages greater the potential for IGMP/MLD report messages being lost and the
being lost and the membership state information being outdated in the membership state information being outdated in the router.
router.
IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
provide the ability to keep track of the downstream (adjacent) provide the ability to keep track of the downstream (adjacent)
multicast membership state to multicast routers, yet the multicast membership state in multicast routers, yet the
specifications are not clearly given. This document describes the specifications are not clearly given. This document describes the
"IGMP/MLD-based explicit member tracking function" for multicast "IGMP/MLD-based explicit member tracking function" for multicast
routers and a way for routers to implement the function. By enabling routers and a way for routers to implement the function. By enabling
this explicit tracking function, routers can keep track of the this explicit tracking function, routers can keep track of the
downstream multicast membership state. This function enables the downstream multicast membership state. This function enables the
following things: following things:
o Reducing the number of transmitted query and report messages o Reducing the number of transmitted query and report messages
o Shortening leave latencies o Shortening leave latencies
skipping to change at page 3, line 41 skipping to change at page 3, line 40
hosts may be outdated in the router because of host departure from hosts may be outdated in the router because of host departure from
the network without sending State-Change Report messages or loss of the network without sending State-Change Report messages or loss of
such messages due to network congestion. Therefore, a router such messages due to network congestion. Therefore, a router
enabling the function may still need to send periodic IGMPv3/MLDv2 enabling the function may still need to send periodic IGMPv3/MLDv2
General Query messages and solicit IGMPv3/MLDv2 report messages from General Query messages and solicit IGMPv3/MLDv2 report messages from
downstream member hosts to maintain an up-to-date membership state. downstream member hosts to maintain an up-to-date membership state.
The explicit tracking function potentially requires a large amount of The explicit tracking function potentially requires a large amount of
memory so that routers keep all membership states. Particularly when memory so that routers keep all membership states. Particularly when
a router needs to maintain a large number of member hosts, this a router needs to maintain a large number of member hosts, this
resource requirement could have an impact. Operators may decide to resource requirement might be sensitive. Operators may decide to
disable this function when their routers have insufficient memory disable this function when their routers have insufficient memory
resources, despite the benefits mentioned above. resources, despite the benefits mentioned above.
The explicit tracking function does not change message formats used The explicit tracking function does not change message formats used
by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight
version protocols [4]; nor does it change a multicast data sender's version protocols [4]; nor does it change a multicast data sender's
and receiver's behavior. and receiver's behavior.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
skipping to change at page 4, line 37 skipping to change at page 4, line 37
communication (i.e., (*,G) join reception). In order to simplify the communication (i.e., (*,G) join reception). In order to simplify the
implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of 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) (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G)
join/leave request with EXCLUDE filter mode from the downstream join/leave request with EXCLUDE filter mode from the downstream
hosts, the router translates the request to a (*,G) join state/leave hosts, the router translates the request to a (*,G) join state/leave
request and records the state and the receivers' addresses in the request and records the state and the receivers' addresses in the
maintained membership state information. maintained membership state information.
The membership state information must be identified properly even The membership state information must be identified properly even
though a receiver (i.e., IGMP/MLD Report sender) sends the identical though a receiver (i.e., IGMP/MLD Report sender) sends the identical
report messages multiple times. report messages multiple times. And the maintained membership state
information will be flushed when the router reboots or restarts the
multicast routing processes.
4. Specific Query Suppression 4. Specific Query Suppression
In accordance with [2] and [3], when a router receives the State- In accordance with [2] and [3], when a router receives the State-
Change Report and needs to confirm whether any hosts are still Change Report and needs to confirm whether any hosts are still
interested in a channel or not, the router sends the corresponding interested in a channel or not, the router sends the corresponding
Group-Specific or Group-and-Source Specific Query messages as defined 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 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 by actions defined in these sections need to be transmitted [Last
Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC)
skipping to change at page 4, line 50 skipping to change at page 5, line 4
In accordance with [2] and [3], when a router receives the State- In accordance with [2] and [3], when a router receives the State-
Change Report and needs to confirm whether any hosts are still Change Report and needs to confirm whether any hosts are still
interested in a channel or not, the router sends the corresponding interested in a channel or not, the router sends the corresponding
Group-Specific or Group-and-Source Specific Query messages as defined 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 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 by actions defined in these sections need to be transmitted [Last
Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC)
times, once every [Last Member Query Interval] (LMQI) or [Last times, once every [Last Member Query Interval] (LMQI) or [Last
Listener Query Interval] (LLQI), in order to confirm the sole member. 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 LMQI/LLQI defined in [2][3] are 1 second.
The default values for LMQC/LLQC are the [Robustness Variable] value The default values for LMQC/LLQC are the [Robustness Variable] value
whose default value is 2.) All member hosts joining the identical whose default value is 2.) All member hosts joining the identical
channel then reply their own states after acquiring these query channel then reply with their own states after acquiring these query
messages. However, transmitting a large number of IGMP/MLD Report messages. However, transmitting a large number of IGMP/MLD Report
messages consumes network resources, and this may pose a particular messages consumes network resources, and this may pose a particular
problem especially when many hosts joining the identical channel send problem especially when many hosts joining the identical channel send
these reports simultaneously. these reports simultaneously.
The explicit tracking function provides a method called "specific The explicit tracking function provides a method called "specific
query suppression" that reduces the number of Group-Specific or query suppression" that reduces the number of Group-Specific or
Group-and-Source Specific Query messages transmitted from a router. Group-and-Source Specific Query messages transmitted from a router.
This in turn reduces the number of Current-State Report messages This in turn reduces the number of Current-State Report messages
transmitted from member hosts. transmitted from member hosts.
With the specific query suppression, regardless of the LMQC/LLQC With the specific query suppression, regardless of the LMQC/LLQC
values, if the router receives one or more replies from the values, if the router receives one or more replies from the
downstream member(s), it can stop (i.e., cancel) retransmitting the downstream member(s), it can stop (i.e., cancel) retransmitting the
specific query message(s). This contributes to saving network specific query message(s) for the specified source and/or group.
resources. This contributes to saving network resources.
If the router is confident that the tracked membership state If the router is confident that the tracked membership state
information is perfectly synchronized with the current (actual) information is perfectly synchronized with the current (actual)
member hosts, the specific query suppression in a "robust link state" member hosts, the specific query suppression in a "robust link state"
may also be implemented with the explicit tracking function. A may also be implemented with the explicit tracking function. A
router enabling the specific query suppression in a robust link state router enabling the specific query suppression in a robust link state
does not send any specific query message(s) and immediately leave the does not send any specific query message(s) and immediately leave the
group or sources when the sole member has left according to its group or sources when the sole member has left according to its
membership state information. The specific query suppression in a membership state information. The specific query suppression in a
robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI
skipping to change at page 5, line 36 skipping to change at page 6, line 4
may also be implemented with the explicit tracking function. A may also be implemented with the explicit tracking function. A
router enabling the specific query suppression in a robust link state router enabling the specific query suppression in a robust link state
does not send any specific query message(s) and immediately leave the does not send any specific query message(s) and immediately leave the
group or sources when the sole member has left according to its group or sources when the sole member has left according to its
membership state information. The specific query suppression in a membership state information. The specific query suppression in a
robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI
values. This contributes to shortening leave latency described in values. This contributes to shortening leave latency described in
Section 5. However, this behavior requires that the router perfectly Section 5. However, this behavior requires that the router perfectly
tracks all member hosts. (See a risk of wrong membership expectation tracks all member hosts. (See a risk of wrong membership expectation
described in Section 6.) described in Section 6.)
Note that the default behavior of the router that supports the Note that the default behavior of the router that supports the
explicit tracking function SHOULD disable this specific query explicit tracking function SHOULD disable this specific query
suppression, in order to avoid the risk caused by the wrong suppression, in order to avoid the risk caused by the wrong
membership expectation or by the case in which multiple multicast membership expectation or by the case in which multiple multicast
routers exist on a LAN and the querier router is not the forwarder 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 router. The former case is described in Section 6. For the latter
case, when the querier suppresses the specific query message case, when the querier suppresses the specific query message
transmission, and expects that the State-Change Report sender is not transmission, and expects that the State-Change Report sender is not
the sole member of the channel, it does not send the specific query 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 Then the routers (including the forwarder) on the same LAN do not
Report message from the corresponding member hosts. The forwarder in receive a Current-State Report message from the corresponding member
this case may prune the routing path though there are other member hosts. The forwarder in this case may prune the routing path,
hosts subscribing to the channel on the LAN. although there are other member hosts subscribing to the channel on
the LAN.
5. Shortening Leave Latency 5. Shortening Leave Latency
A router enabling the explicit tracking function can shorten leave A router enabling the explicit tracking function can shorten leave
latencies by tuning the following values; [Last Member Query Count] latencies by tuning the following values; [Last Member Query Count]
(LMQC), [Last Listener Query Count] (LLQC), [Last Member Query (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query
Interval] (LMQI), [Last Listener Query Interval] (LLQI), and Interval] (LMQI), [Last Listener Query Interval] (LLQI), and
[Robustness Variable] values. [Robustness Variable] values.
The [Last Member Query Interval] (LMQI) and [Last Listener Query The [Last Member Query Interval] (LMQI) and [Last Listener Query
skipping to change at page 6, line 32 skipping to change at page 6, line 46
query. query.
The default values for LMQI/LLQI defined in [2][3] are 1 second, yet, The default values for LMQI/LLQI defined in [2][3] are 1 second, yet,
for a router enabling the explicit tracking function, the LMQI/LLQI for a router enabling the explicit tracking function, the LMQI/LLQI
may be set to 1 second or shorter. As well, the default values for may be set to 1 second or shorter. As well, the default values for
LMQC/LLQC are the [Robustness Variable] value whose default value is LMQC/LLQC are the [Robustness Variable] value whose default value is
2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/ 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 LLQC values give shorter LMQT/LLQT, which shorten the leave
latencies. latencies.
Furthermore, if operators believe that their link is fairly robust or Furthermore, if operators are confident that their link is fairly
that they can configure the [Robustness Variable] value appropriately robust (e.g., the [Robustness Variable] value is appropriately
so that the chances of unsolicited messages being lost are configured so that the chances of unsolicited messages being lost are
sufficiently low, and if the querier router is always the forwarder sufficiently low), and if the querier router always acts as the
router in their link, they will set smaller LMQC/LLQC and shorter forwarder router for all multicast channels in the LAN, they will set
LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT)
suppression or enable the specific query suppression in a robust link with the specific query suppression, or enable the specific query
state (Section 4) for their routers. suppression in a robust link state (Section 4) for their routers.
Note that setting smaller LMQC/LLQC values or adopting the specific Note that setting smaller LMQC/LLQC values or adopting the specific
query suppression in a robust link state poses the risk of wrong query suppression in a robust link state poses the risk of wrong
membership state described in Section 6. Operators setting smaller membership state described in Section 6. Operators setting smaller
LMQC/LLQC values must recognize this tradeoff. LMQC/LLQC values must recognize this tradeoff.
6. Risk of Wrong Membership State 6. Risk of Wrong Membership State
There are possibilities that a router's membership expectation is There are possibilities that a router's membership expectation is
inconsistent due to an outdated membership state. For example, (1) a inconsistent due to an outdated membership state. For example, (1) a
 End of changes. 16 change blocks. 
40 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/