< draft-ietf-pim-explicit-tracking-03.txt   draft-ietf-pim-explicit-tracking-04.txt >
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Informational December 11, 2012 Intended status: Standards Track January 29, 2013
Expires: June 14, 2013 Expires: August 2, 2013
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-03 draft-ietf-pim-explicit-tracking-04
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. The explicit tracking tracking function for multicast routers supporting IGMPv3/MLDv2. The
function contributes to saving network resources and fast leaves explicit tracking function contributes to saving network resources
(i.e. shortening leave latency). and fast leaves (i.e. shortening leave latency).
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 June 14, 2013. This Internet-Draft will expire on August 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4 3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4
3.1. Membership State Information . . . . . . . . . . . . . . . 4 3.1. Membership State Information . . . . . . . . . . . . . . . 4
3.2. Specific Query Suppression . . . . . . . . . . . . . . . . 5 3.2. Specific Query Suppression . . . . . . . . . . . . . . . . 5
3.3. Shortening Leave Latency . . . . . . . . . . . . . . . . . 6 3.3. Shortening Leave Latency . . . . . . . . . . . . . . . . . 6
4. Lowering the Possibility of Outdated Membership State . . . . . 7 4. Lowering the Possibility of Outdated Membership State . . . . 7
5. All-Zero and Unspecified Source Addresses . . . . . . . . . . . 8 5. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8
6. Compatibility with Older Version Protocols . . . . . . . . . . 8 6. Compatibility with Older Version Protocols . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [1] for IPv4 and the The Internet Group Management Protocol (IGMP) version 3 [1] for IPv4
Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the and the Multicast Listener Discovery Protocol (MLD) version 2 [2] for
standard protocols used by member hosts and multicast routers. When IPv6 are the standard protocols used by member hosts and multicast
a host starts/finishes listening to particular multicast channels, it routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and
LW-MLDv2) [3] 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 sends IGMP/MLD State-Change Report messages specifying the
corresponding channel information as the join/leave request to its corresponding channel information as the join/leave request to its
upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy
device [5]). The "unsolicited" report messages are sent only once device [5]). The "unsolicited" report messages are sent only when
upon reception/departure. the host joins/leaves the channels.
IGMP/MLD are non-reliable protocols; the unsolicited report messages IGMP/MLD are non-reliable protocols; the unsolicited report messages
may be lost or may not reached upstream routers. To resolve the may be lost or may not reach upstream routers. To alleviate the
problem, routers need to update membership information by problem, routers need to update membership information by
periodically sending IGMP/MLD General Query messages. Member hosts periodically sending IGMP/MLD General Query messages. Member hosts
then reply with "solicited" report messages whenever they receive the then reply with "solicited" report messages whenever they receive the
query messages. query messages.
Multicast routers are capable of periodically maintaining the Multicast routers are capable of periodically maintaining the
multicast membership state of downstream hosts attached to the same multicast membership state of downstream hosts attached to the same
link by acquiring unsolicited report messages and synchronizing the link by acquiring unsolicited report messages and synchronizing the
actual membership state within the General Query timer interval actual membership state within the General Query timer interval
(i.e., [Query Interval] value defined in [1][2].) However, this (i.e., [Query Interval] value defined in [1][2].) However, this
approach does not guarantee that the membership state is always approach does not guarantee that the membership state is always
perfectly synchronized. To minimize the possibility of having perfectly synchronized. To minimize the possibility of having
outdated membership information, routers may shorten the periodic outdated membership information, routers may shorten the periodic
General Query timer interval. Unfortunately, this increases the General Query timer interval. Unfortunately, this increases the
number of transmitted solicited report messages and induces network number of transmitted solicited report messages and induces network
congestion. And the greater the amount of network congestion, the congestion. And the greater the amount of network congestion, the
greater the potential for IGMP/MLD report messages being lost and the greater the potential for IGMP/MLD report messages being lost and the
membership state information being outdated in the router. membership state information being outdated in the router.
The IGMPv3 [1] and MLDv2 [2] protocols can provide the ability to The IGMPv3 [1] and MLDv2 [2] protocols and these lightweight
keep track of the downstream (adjacent) multicast membership state to protocols [3] can provide the ability to keep track of the downstream
multicast routers, yet the specifications are not clearly given. (adjacent) multicast membership state to multicast routers, yet the
This document describes the "IGMP/MLD-based explicit member tracking specifications are not clearly given. This document describes the
function" for multicast routers and details a way for routers to "IGMP/MLD-based explicit member tracking function" for multicast
implement the function. By enabling this explicit tracking function, routers and details a way for routers to implement the function. By
routers can keep track of the downstream multicast membership state. enabling this explicit tracking function, routers can keep track of
This function enables the following: the downstream multicast membership state. This function enables the
following:
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
o Per-host accounting o Per-host accounting
o Maintaining multicast channel characteristics (or statistics) o Maintaining multicast channel characteristics (or statistics)
In addition, the processing of IGMP membership or MLD listener In addition, the processing of IGMP membership or MLD listener
messages consumes CPU resources on individual IGMP/MLD querier and messages consumes CPU resources on individual IGMP/MLD querier and
report sender devices. The explicit tracking function therefore report sender devices. The explicit tracking function therefore
reduces not only the network load but also the CPU load on these reduces not only the network load but also the CPU load on these
devices. devices.
The explicit tracking function does not guarantee that the membership The explicit tracking function does not guarantee that the membership
state will always be perfectly synchronized; the list of tracked state will always be perfectly synchronized; the list of tracked
member hosts may be outdated in the router because of host departure member hosts may be outdated in the router because of host departure
from the network without sending State-Change Report messages or loss from the network without sending State-Change Report messages or loss
of such messages due to network congestion. Therefore, a router of such messages due to network congestion. Therefore, a router
enabling the function ought to send periodic IGMPv3/MLDv2 General enabling the function ought to send periodic IGMPv3/MLDv2 General
Query messages and inquire about solicited IGMPv3/MLDv2 report Query messages and solicit IGMPv3/MLDv2 report messages from
messages from downstream member hosts to maintain an up-to-date downstream member hosts to maintain an up-to-date membership state.
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 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 [1] and MLDv2 [2], and their lightweight by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight
skipping to change at page 5, line 21 skipping to change at page 5, line 24
where each receiver record is of the form: where each receiver record is of the form:
(IGMP/MLD membership/listener report sender's address) (IGMP/MLD membership/listener report sender's address)
This state information must work properly when a receiver (i.e., This state information must work properly when a receiver (i.e.,
report sender) sends the identical report messages multiple times. report sender) sends the identical report messages multiple times.
In the state information, each S and G indicates a single IPv4/IPv6 In the state information, each S and G indicates a single IPv4/IPv6
address. S is set to "Null" for Any-Source Multicast (ASM) address. S is set to "Null" for Any-Source Multicast (ASM)
communication (i.e., (*,G) join reception). In order to simplify the communication (i.e., (*,G) join reception). In order to simplify the
implementation, the explicit tracking function does not keep the implementation, the explicit tracking function MAY NOT keep the state
state of (S,G) joined with EXCLUDE filter mode. If a router receives of (S,G) joined with EXCLUDE filter mode. In that case, if a router
an (S,G) join/leave request with EXCLUDE filter mode from the receives an (S,G) join/leave request with EXCLUDE filter mode from
downstream hosts, it translates it to a (*,G) join state/leave the downstream hosts, the router translates the request to a (*,G)
request and records the state and the receivers' addresses in the join state/leave request and records the state and the receivers'
maintained membership state information. Note that this membership addresses in the maintained membership state information. Note that
state translation does not change the routing protocol behavior. The this membership state translation does not change the routing
routing protocol must deal with the original join/leave request and protocol behavior. The routing protocol must deal with the original
translate the request only for the membership state information. join/leave request and translate the request only for the membership
state information.
3.2. Specific Query Suppression 3.2. Specific Query Suppression
In accordance with [1] and [2], whenever a router receives the State- In accordance with [1] and [2], whenever a router receives the State-
Change Report, it sends the corresponding Group-Specific or Group- Change Report, it sends the corresponding Group-Specific or Group-
and-Source Specific Query messages to confirm whether or not the and-Source Specific Query messages to confirm whether or not the
report sender is the sole member host. All member hosts joining the report sender is the sole member host. All member hosts joining the
identical channel send their own Current-State Report messages after identical channel send their own Current-State Report messages after
acquiring these query messages. Transmitting a large number of acquiring these query messages. Transmitting a large number of
Current-State Report messages consumes network resources, and this Current-State Report messages consumes network resources, and this
skipping to change at page 6, line 35 skipping to change at page 6, line 39
there are other member hosts subscribing to the channel on the LAN. there are other member hosts subscribing to the channel on the LAN.
3.3. Shortening Leave Latency 3.3. 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 several timers and values to what it expects latencies by tuning several timers and values to what it expects
whether or not the State-Change Report sender is the channel's sole whether or not the State-Change Report sender is the channel's sole
member. member.
The [Last Member Query Interval] (LMQI) and [Last Listener Query The [Last Member Query Interval] (LMQI) and [Last Listener Query
Interval] (LLQI) values specify the maximum time allowed before Interval] (LLQI) values specify the maximum time allowed for a member
sending a responding Report. The [Last Member Query Count] (LMQC) host to send a responding Report before the router prunes the channel
and [Last Listener Query Count] (LLQC) are the number of Group- from the network. The [Last Member Query Count] (LMQC) and [Last
Specific Queries or Group-and-Source Specific Queries sent before the Listener Query Count] (LLQC) are the number of Group-Specific Queries
router assumes there are no local members. The [Last Member Query or Group-and-Source Specific Queries sent before the router assumes
Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the there are no local members. The [Last Member Query Time] (LMQT) and
total time the router should wait for a report after the Querier has [Last Listener Query Time] (LLQT) values are the total time the
sent the first query. router should wait for a report after the Querier has sent the first
query.
The default value for LMQI/LLQI defined in the standard The default value for LMQI/LLQI defined in the standard
specifications [1][2] is 1 second. For a router enabling the specifications [1][2] is 1 second. For a router enabling the
explicit tracking function, the LMQI/LLQI MAY be set to 1 second or explicit tracking function, the LMQI/LLQI MAY be set to 1 second or
shorter. The LMQC/LLQC values MAY be set to 1 for the router, shorter. The LMQC/LLQC values MAY be set to 1 for the router,
whereas their default values are the [Robustness Variable] value whereas their default values are the [Robustness Variable] value
whose default value is 2. Smaller LMQC/LLQC values give smaller whose default value is 2. Smaller LMQC/LLQC values give smaller
LMQT/LLQT, which shortens the leave latencies. On the other hand, LMQT/LLQT, which shortens the leave latencies. On the other hand,
setting smaller LMQC/LLQC values poses the risk described in setting smaller LMQC/LLQC values poses the risk described in
Section 4. Operators setting smaller LMQC/LLQC values must recognize Section 4. Operators setting smaller LMQC/LLQC values must recognize
this tradeoff. this tradeoff.
4. Lowering the Possibility of Outdated Membership State 4. Lowering the Possibility of Outdated Membership State
There are possibilities that the membership expectation performed by There are possibilities that a router enables the explicit tracking
a router enabling the explicit tracking function will be inconsistent function but its membership expectation will be inconsistent due to
due to an outdated membership state. For example, (1) a router an outdated membership state. For example, (1) a router expects that
expects that more than one corresponding member host exists on its more than one corresponding member host exists on its LAN, but in
LAN, but in fact no member host exists for that multicast channel, or fact no member host exists for that multicast channel, or (2) a
(2) a router expects that no corresponding member host exists on its router expects that no corresponding member host exists on its LAN,
LAN, but in fact more than one member host exists for that multicast but in fact more than one member host exists for that multicast
channel. These cases are particularly likely for a router that channel. These cases are particularly likely for a router that
enables specific query suppression (as in Section 3.2) and configures enables specific query suppression (as in Section 3.2) and configures
small LMQC/LLQC for shortening leave latency (as in Section 3.3). small LMQC/LLQC for shortening leave latency (as in Section 3.3).
The first of these cases may occur in an environment where the sole The first of these cases may occur in an environment where the sole
member host departs the network without sending a State-Change Report member host departs the network without sending a State-Change Report
message. This is because a router enabling specific query message. This is because a router enabling specific query
suppression does not send a specific query if it believes the report suppression does not send a specific query if it believes the report
sender is not the sole member host. The router later detects that sender is not the sole member host. The router later detects that
there is no member host for the corresponding channels when it does there is no member host for the corresponding channels when it does
 End of changes. 16 change blocks. 
67 lines changed or deleted 71 lines changed or added

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