draft-ietf-pim-explicit-tracking-06.txt   draft-ietf-pim-explicit-tracking-07.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track July 15, 2013 Intended status: Standards Track July 31, 2013
Expires: January 16, 2014 Expires: February 01, 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-06 draft-ietf-pim-explicit-tracking-07
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 supporting IGMPv3/MLDv2. The tracking function for multicast routers and IGMP/MLD proxy devices
explicit membership tracking function contributes to saving network supporting IGMPv3/MLDv2. The explicit membership tracking function
resources and shortening leave latency, and enables operators to see contributes to saving network resources and shortening leave latency.
which downstream routers(s) on a LAN are joined to which multicast
tree.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 16, 2014. This Internet-Draft will expire on February 01, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 5 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6
6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6
7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 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 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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.
When a host starts/finishes listening to particular multicast When a host starts/finishes listening to particular multicast
skipping to change at page 3, line 36 skipping to change at page 3, line 33
o Maintaining multicast channel characteristics (or statistics) o Maintaining multicast channel characteristics (or statistics)
where this document mainly focuses on the above first and second where this document mainly focuses on the above first and second
bullets in the following sections. bullets in the following sections.
Note that the explicit tracking function does not change the Note that the explicit tracking function does not change the
reliability of the message transmission. The list of tracked member reliability of the message transmission. The list of tracked member
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 even such messages due to network congestion. Therefore, a router
enabling the function may need to send periodic IGMPv3/MLDv2 General enabling the function may still need to send periodic IGMPv3/MLDv2
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.
while the function contributes to saving network resources by tuning
query timers or values.
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 could have an impact. 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
skipping to change at page 4, line 21 skipping to change at page 4, line 16
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
3. Membership State Information 3. Membership State Information
A router enabling the explicit tracking function maintains the A router enabling the explicit tracking function maintains the
"membership state information". When a multicast router receives a "membership state information". When a multicast router receives a
Current-State or State-Change Report message, it creates or modifies Current-State or State-Change Report message, it creates or modifies
this membership state information to maintain the membership state up this membership state information to maintain the membership state up
to date. to date.
The membership state information is also known as the following The membership state information consists of the following
"interface state" defined by the standard IGMPv3 and MLDv2 information:
specifications [2][3].
(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 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.
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 along with Group-Specific or Group-and-Source Specific Query messages as defined
the definition of Section 6.4.2 of [2] and Section 7.4.2 of [3]. The in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent
queries sent by actions defined in these sections need to be by actions defined in these sections need to be transmitted [Last
transmitted [Last Member Query Count] (LMQC) or [Last Listener Query Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC)
Count] (LLQC) times, once every [Last Member Query Interval] (LMQI) times, once every [Last Member Query Interval] (LMQI) or [Last
or [Last Listener Query Interval] (LLQI), in order to confirm the Listener Query Interval] (LLQI), in order to confirm the sole member.
sole member. (The default values for LMQI/LLQI defined in [2][3] are (The default values for LMQI/LLQI defined in [2][3] are 1 second.
1 second. The default values for LMQC/LLQC are the [Robustness The default values for LMQC/LLQC are the [Robustness Variable] value
Variable] value whose default value is 2.) All member hosts joining whose default value is 2.) All member hosts joining the identical
the identical channel then reply their own states after acquiring channel then reply their own states after acquiring these query
these query messages. However, transmitting a large number of IGMP/ messages. However, transmitting a large number of IGMP/MLD Report
MLD Report messages consumes network resources, and this may pose a messages consumes network resources, and this may pose a particular
particular problem especially when many hosts joining the identical problem especially when many hosts joining the identical channel send
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) and lower the corresponding source/group specific query message(s). This contributes to saving network
timers. This contributes to saving network resources. resources.
The specific query suppression in "hard state" may also be If the router is confident that the tracked membership state
implemented with the explicit tracking function; a router enabling information is perfectly synchronized with the current (actual)
the specific query suppression in hard state does not send any member hosts, the specific query suppression in a "robust link state"
specific query message(s) and immediately leave the group or sources may also be implemented with the explicit tracking function. A
when the sole member has left according to its membership state router enabling the specific query suppression in a robust link state
information. The specific query suppression in hard state hence does does not send any specific query message(s) and immediately leave the
not rely on LMQC/LLQC and LMQI/LLQI values. This contributes to group or sources when the sole member has left according to its
shortening leave latency described in Section 5. However, this membership state information. The specific query suppression in a
behavior requires that the router perfectly tracks all member hosts. robust link state hence does not rely on LMQC/LLQC and LMQI/LLQI
(See a risk of wrong membership expectation described in Section 6.) 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 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
skipping to change at page 6, line 26 skipping to change at page 6, line 38
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 believe that their link is fairly robust or
that they can configure the [Robustness Variable] value appropriately that they can configure the [Robustness Variable] value appropriately
so that the chances of unsolicited messages being lost are 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 is always the forwarder
router in their link, they will set smaller LMQC/LLQC and shorter router in their link, they will set smaller LMQC/LLQC and shorter
LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query
suppression or enable the specific query suppression in hard state suppression or enable the specific query suppression in a robust link
(Section 4) for their routers. 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 hard state poses the risk of wrong membership query suppression in a robust link state poses the risk of wrong
state described in Section 6. Operators setting smaller LMQC/LLQC membership state described in Section 6. Operators setting smaller
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
router expects that more than one corresponding member host exists on router expects that more than one corresponding member host exists on
its LAN, but in fact no member host exists for that multicast its LAN, but in fact no member host exists for that multicast
channel, or (2) a router expects that no corresponding member host 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 on its LAN, but in fact one or more than one member host
exists for that multicast channel. exists for that multicast channel.
skipping to change at page 10, line 4 skipping to change at page 10, line 8
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast [7] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[8] Fenner, B., He, H., Haberman, B., and H. Sandick, [8] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP
/MLD Proxying")", RFC 4605, August 2006. /MLD Proxying")", RFC 4605, August 2006.
Author's Address Author's Address
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology (NICT) National Institute of Information and Communications Technology
Network Research Headquarters
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
 End of changes. 19 change blocks. 
57 lines changed or deleted 69 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/