MULTIMOB Group H. Asaeda
Internet-Draft Keio University
Intended status: Standards Track T C. Schmidt
Expires: January 14, 2010 HAW Hamburg
July 13, 2009
IGMP and MLD Hold and Release Extensions for Mobility
draft-asaeda-multimob-igmp-mld-mobility-extensions-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Asaeda & Schmidt Expires January 14, 2010 [Page 1]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Asaeda & Schmidt Expires January 14, 2010 [Page 2]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
Abstract
This document describes IGMP and MLD Hold and Release protocol
extensions for hosts and routers. The interoperability with the
standard IGMPv3/MLDv2 protocols and these previous versions is also
taken into account.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IGMP/MLD Hold and Release . . . . . . . . . . . . . . . . . . 6
3.1. Action for IGMP/MLD Hold Request . . . . . . . . . . . . . 6
3.2. Action for IGMP/MLD Release Request . . . . . . . . . . . 6
3.3. Action for IGMP/MLD Hold Reception . . . . . . . . . . . . 7
3.4. Action for IGMP/MLD Release Reception . . . . . . . . . . 8
3.5. IGMP/MLD Hold Message Format . . . . . . . . . . . . . . . 8
3.6. IGMP/MLD Hold Interval Timer . . . . . . . . . . . . . . . 11
3.7. Interoperability of IGMP/MLD Hold and Release . . . . . . 11
4. Interoperability with Older Protocols . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Asaeda & Schmidt Expires January 14, 2010 [Page 3]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
1. Introduction
The Internet Group Management Protocol (IGMP) [2] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the
standard protocols used by hosts and multicast routers. A mobile
host sends a join/leave request for particular multicast session or
channel to its upstream router (i.e., an adjacent router or IGMP/MLD
proxy [8]), and the router will maintain the multicast reception (or
membership) state of the host and serve multicast data to the host.
Conceptually, IGMP and MLD work for mobile communications such with
MIPv6 [11] or PMIPv6 [12]. However, wireless access technologies and
mobile communications need to preserve the limited resources of
mobile hosts and networks [10] and smooth handover. According to a
smooth handover scenario, a mobile host wants to accelerate multicast
service termination in the previous network before handoff and
immediately rejoin the session after the movement. As the router's
behavior, when the router remains part of the multicast delivery
tree, it keeps the session active without leaving from the session,
while the data transmission is paused until the host completes the
movement and resumed after the movement.
This document describes the IGMPv3 and MLDv2 Hold and Release
protocol extensions for mobile hosts and routers. The IGMP/MLD Hold
operation enables to keep the membership state for fast packet
forwarding, and the IGMP/MLD Release operation ressumes forwarding
the multicast data after the host movement. Originally, an idea of
MLD Hold was proposed in [13].
Note that discussing the procedure of context transfer (CT) for
mobility protocols and the message format for CT will be defined in
other documents. Discussing how a mobile host or a router detects
the movement and triggers to send an IGMP/MLD Hold message is depend
on mobility protocols, and hence out of scope of this document.
The proposed solution interoperates with the IGMPv3 and MLDv2
protocols and preserves compatibility with older versions of IGMP/
MLD.
Asaeda & Schmidt Expires January 14, 2010 [Page 4]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
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 [1].
IGMP/MLD Hold:
IGMP/MLD Hold is an operation in which a neighboring mobile host or
IGMP/MLD proxy requests a multicast router to suspend data forwarding
for temporal period (during mobile host movement).
IGMP/MLD Release:
IGMP/MLD Release is an operation in which a neighboring mobile host
or IGMP/MLD proxy requests a multicast router to resume data
forwarding that was suspended by the router.
Hold-Req Records:
Hold-Req Records are IGMP/MLD Multicast Address Records (group and
source address records with filter-mode) a mobile hosts requests to
suspend. Hold-Req Records are specified in an IGMP/MLD Hold message
and MAY correspond to the set of Current-State Records the mobile
host has joined.
Release-Req Records:
Release-Req Records are IGMP/MLD Multicast Address Records a mobile
hosts requests to resume. Release-Req Records are specified in an
IGMP/MLD Release message and MAY correspond to the Hold-Req Records
the mobile host has sent.
Hold Records:
Hold Records are the IGMP/MLD records for which a multicast router
decides to suspend data forwarding.
Asaeda & Schmidt Expires January 14, 2010 [Page 5]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
3. IGMP/MLD Hold and Release
3.1. Action for IGMP/MLD Hold Request
When a mobile host moves from a current network (i.e. a mobile host's
point of attachment) to a different network, an IGMP/MLD Hold message
is sent by either the mobile host itself or a neighboring IGMP/MLD
proxy to which the mobile host currently attached. The IGMP/MLD Hold
message will be sent by the mobile host or the proxy depending on
which mobile protocol is in use. For instance, in MIPv6 [11], a
mobile host detects its own movement and sends the IGMP/MLD Hold
message to its upstream router (or Home Agent). On the other hand,
in PMIPv6 [12], while a mobile host initiates multicast join/leave
requests by sending regular IGMP/MLD messages [2][3], it does not
send the IGMP/MLD Hold message. The reason is that a mobile host (or
Mobile Node (MN) in [12]) does not manage its movement but the mobile
access gateway (MAG) detects its movement. In this case, MAG sends
the corresponding IGMP/MLD Hold messages to its upstream router (in
case of local routing) or local mobility anchor (LMA) (in case of
bidirectional tunneling) upon the host movement.
An IGMP/MLD Hold message is received by either the adjacent upstream
router or an IGMP/MLD proxy that the mobile host attached. An IGMP/
MLD proxy performs a host portion of the IGMP/MLD protocol on the
upstream interface, and an IGMP/MLD Hold message will be finally
proceeded by a multicast router. Therefore if an IGMP/MLD proxy
receives an IGMP/MLD Hold message, it forwards the Hold message with
the link-local IPv6 source address of its upstream interface. (Note
that there is a case that an IGMP/MLD proxy does not forward the Hold
message. See Section 3.3.) If the upstream interface of the IGMP/
MLD proxy is attached to another (cascaded) IGMP/MLD proxy, then the
IGMP/MLD Hold message is forwarded to that cascaded proxy, and the
cascaded proxy forwards the Hold message toward its upstream router.
3.2. Action for IGMP/MLD Release Request
When a mobile host completes its movement and attaches a new network,
the host or the neighboring IGMP/MLD proxy immediately sends an IGMP/
MLD Release message. The Release-Req Records specified in the IGMP/
MLD Release message MAY be the same as that of the Hold-Req Records
the host sent (since the host does not know the Hold Records, and
only knows Hold-Req Records).
As well as an IGMP/MLD Hold message, an IGMP/MLD Release message MUST
also be finally proceeded by a multicast router. Hence if an IGMP/
MLD proxy receives an IGMP/MLD Release message, it forwards the
Release message with the link-local IPv6 source address of its
upstream interface. If proxies are cascaded, the IGMP/MLD Release
Asaeda & Schmidt Expires January 14, 2010 [Page 6]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
message is forwarded toward its upstream router.
3.3. Action for IGMP/MLD Hold Reception
When a multicast router receives an IGMP/MLD Hold message from a
neighboring mobile host or IGMP/MLD proxy, it records the following
information; 1) the source IP address of the IGMP/MLD Hold message,
and 2) the Hold-Req Records. After that, the router needs to decide
whether it suspends the data forwarding or not. Since the decision
has to be made whether to know the message sender is the last member
for notified sessions/channels, the router sends the Group-Specific
or Group-and-Source Specific Queries for all Hold-Req Records in the
Hold messages. If the router receives the inquired IGMP/MLD reports,
it eliminates the records from the Hold-Req Records and keeps
forwarding the data. If it does not receive the IGMP/MLD reports for
some of the Hold-Req Records, it recognizes that the Hold message
sender is the last member host joining the sessions or channels on
the interface, keeps them as the Hold Records, and suspends the data
forwarding.
The multicast router maintains Hold Records until it receives the
corresponding IGMP/MLD Release message (described in the next
section) or the IGMP/MLD Hold Interval timer (described in
Section 3.6) is expired. When either the Release message reception
or the timer expiration occurs, the router resume data forwarding for
the Hold Records and discards the Hold Records.
If a multicast router receives an IGMP/MLD Hold message whose
Multicast Address Records have already kept in the Hold Records, the
router restarts the IGMP/MLD Hold Interval timer for the
corresponding Multicast Address Records.
As described in [10], there is an advantage if a router has been
tracking multicast memberships of all downstream hosts, as it can
recognize whether the message sender host is the last member joining
the sessions/channels without sending the Group-Specific or Group-
and-Source Specific Queries.
When an IGMP/MLD proxy receives an IGMP/MLD Hold message from a
downstream mobile host, it forwards the message to its upstream
router as described in Section 3.1. Since the IGMP/MLD information
presented by the proxy to its upstream routers is the aggregation of
all its downstream group membership information, prior to forwarding
the Hold message, an IGMP/MLD proxy MUST inquire downstream
memberships and organize new Hold-Req Records. Then it forwards the
appropriate IGMP/MLD Hold message including the newly organized Hold-
Req Records to its upstream router.
Asaeda & Schmidt Expires January 14, 2010 [Page 7]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
3.4. Action for IGMP/MLD Release Reception
When a mobile host moves to a new network, the host or the
neighboring IGMP/MLD proxy immediately sends an IGMP/MLD Release
message to request its upstream router to release the hold request
previously sent. The format of the Release message is the same as
that of the standard IGMP/MLD Current-State Report message. (See
Section 3.5.)
When a multicast router receives an IGMP/MLD Release (i.e. Current-
State Report) message, the router examines the message sender and an
IGMP/MLD Hold Interval timer. If the router has the Hold Records
given from the Release message sender, it compares the Hold Records
with the notified Multicast Address Records specified in the IGMP/MLD
Current-State Report message. For the matched Multicast Address
Records, the router then removes the entries from the Hold Records
and resume data forwarding with restarting the group or source
timers. For the mismatched Multicast Address Records, the router
keeps untouched (then removed by timeout) or explicitly starts the
leave (or prune) procedures for the sessions/channels, while it
depends on the implementation.
If either the router does not have the corresponding Hold Records or
the IGMP/MLD Hold Interval timer has expired, then the router does
not take any action.
If a router that did not recognize an IGMP/MLD Hold message (e.g.,
due to packet loss or some troubles in its transmission) receives an
IGMP/MLD Current-State Report message, it will accept the message as
a regular Current-State Report IGMP/MLD message as specified in
Section 3.7.
3.5. IGMP/MLD Hold Message Format
The following figure is the Report message format defined in IGMPv3
[2] and MLDv2 [3]. Type field is either IGMP Version 3 Membership
Report (0x22) or Version 2 Multicast Listener Report (decimal 143);
it is not necessary to change IGMP/MLD Report message format to
support IGMP/MLD Hold messages.
Asaeda & Schmidt Expires January 14, 2010 [Page 8]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Multicast Address Record shown in the following figure defines
new Record Types that express an IGMP/MLD Hold message. For an IGMP/
MLD Release operation, the standard IGMP/MLD Current-State Report
message is used.
Asaeda & Schmidt Expires January 14, 2010 [Page 9]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Source Address [1] .
. .
| |
+- -+
. . .
. . .
. . .
+- -+
| |
. .
. Source Address [N] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value Name and Meaning
----- ----------------
7 HOLD_INCLUDE - indicates that the interface has a filter mode
of INCLUDE for the specified multicast address. The Source
Address [i] fields in this Multicast Address Record contain
the interface's source list for the specified multicast
address. A HOLD_INCLUDE Record is never sent with an empty
source list.
8 HOLD_EXCLUDE - indicates that the interface has a filter mode
of EXCLUDE for the specified multicast address. The Source
Address [i] fields in this Multicast Address Record contain
the interface's source list for the specified multicast
address, if it is non-empty. When a mobile host works with
Asaeda & Schmidt Expires January 14, 2010 [Page 10]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
LW-IGMPv3/LW-MLDv2 ([9]), the Multicast Address Record does
not contain the Source Address [i] field with HOLD_EXCLUDE
type value.
3.6. IGMP/MLD Hold Interval Timer
After a multicast router receiving an IGMP/MLD Hold message will
identify the corresponding multicast sessions/channels, it suspends
data forwarding and keeps the Hold Records until the given amount of
timer value is expired. This timer is named the "IGMP/MLD Hold
Interval timer", which is a configurable value.
The Hold Interval is used to allow a multicast router to resume the
multicast session. Therefore, if the multicast router does not
receive the corresponding IGMP/MLD Release (or Current-State Record)
message for the IGMP/MLD Release operation within the Hold Interval,
it leaves the sessions/channels recorded in the Hold Records and
discards the Hold Records. Note that the router does not send any
IGMP/MLD Query message for the timeout sessions/channels and
immediately leave them.
[TODO: We will provide the default Hold Interval value based on some
experimental results in the revised version. Note that this value
will depend on each mobile protocol; hence the default value will be
adjusted by operators.]
3.7. Interoperability of IGMP/MLD Hold and Release
If a multicast router does not support an IGMP/MLD Hold operation, it
will ignore the IGMP/MLD Hold message. In this case, an IGMP/MLD
Current-State Report message sent by a mobile host that previously
requested an IGMP/MLD Hold operation to stop forwarding data is dealt
with as a new join request for the specified multicast sessions (when
the corresponding group or source timer is expired) or simply updates
the corresponding group and/or source timer (when these timers are
not expired and the membership status has been still active).
Asaeda & Schmidt Expires January 14, 2010 [Page 11]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
4. Interoperability with Older Protocols
This document assumes multicast routers that deal with mobile hosts
MUST be IGMPv3/MLDv2 capable (regardless whether the protocols are
the full version or not). Therefore this document does not need to
consider interoperability with older version protocols.
Asaeda & Schmidt Expires January 14, 2010 [Page 12]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
5. Security Considerations
TBD.
For the use of IGMP/MLD Hold message, it may be required to confirm
that the IGMP/MLD Hold messages sender is the IGMP/MLD Release
sender. This document assumes the use of the simplest way of
comparing the sender's IP address of each message, while it may
require a more secure mechanism which is robust for IP address
spoofing.
Asaeda & Schmidt Expires January 14, 2010 [Page 13]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
6. Acknowledgements
Gorry Fairhurst, Dave Thaler, Matthias Waehlisch, and others provided
many constructive and insightful comments.
Asaeda & Schmidt Expires January 14, 2010 [Page 14]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
7. References
7.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.
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2373, July 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[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.
[9] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
Protocols",
draft-ietf-mboned-lightweight-igmpv3-mldv2-05.txt (work in
progress), May 2009.
7.2. Informative References
[10] Asaeda, H., "IGMP and MLD Optimization for Mobile Hosts and
Routers",
draft-asaeda-multimob-igmp-mld-optimization-00.txt (work in
progress), July 2009.
[11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[12] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
Asaeda & Schmidt Expires January 14, 2010 [Page 15]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[13] Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP
Networks: Progress and Challenges", IEEE Wireless
Comm. pp.58-64, October 2002.
Asaeda & Schmidt Expires January 14, 2010 [Page 16]
Internet-Draft IGMP and MLD Hold and Release Extensions July 2009
Authors' Addresses
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
Thomas C. Schmidt
HAW Hamburg
Dept. Informatik
Berliner Tor 7
Hamburg, D-20099
Germany
Email: Schmidt@informatik.haw-hamburg.de
Asaeda & Schmidt Expires January 14, 2010 [Page 17]