[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

MULTIMOB Group                                                 H. Asaeda
Internet-Draft                                           Keio University
Intended status: Standards Track                            T C. Schmidt
Expires: September 9, 2010                                   HAW Hamburg
                                                           March 8, 2010


             IGMP and MLD Protocol Extensions for Mobility
         draft-asaeda-multimob-igmp-mld-mobility-extensions-04

Abstract

   This document describes an explicit membership notification operation
   and 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.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Asaeda & Schmidt        Expires September 9, 2010               [Page 1]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   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.

































Asaeda & Schmidt        Expires September 9, 2010               [Page 2]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Explicit Membership Notification . . . . . . . . . . . . . . .  6
   4.  IGMP/MLD Hold and Release  . . . . . . . . . . . . . . . . . .  8
     4.1.  Action for IGMP/MLD Hold Request . . . . . . . . . . . . .  8
     4.2.  Action for IGMP/MLD Release Request  . . . . . . . . . . .  8
     4.3.  Action for IGMP/MLD Hold Reception . . . . . . . . . . . .  9
     4.4.  Action for IGMP/MLD Release Reception  . . . . . . . . . . 10
     4.5.  IGMP/MLD Hold Message Format . . . . . . . . . . . . . . . 10
   5.  Interoperability with Older Protocols  . . . . . . . . . . . . 14
   6.  Timers, Counters, and Their Default Values . . . . . . . . . . 15
     6.1.  Unicast Query Interval . . . . . . . . . . . . . . . . . . 15
     6.2.  Notification Interval  . . . . . . . . . . . . . . . . . . 15
     6.3.  IGMP/MLD Hold Interval Timer . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20





























Asaeda & Schmidt        Expires September 9, 2010               [Page 3]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


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 a "Notification operation" and "Hold and
   Release protocol extensions" for the IGMPv3 and MLDv2 protocols 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 September 9, 2010               [Page 4]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


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 September 9, 2010               [Page 5]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


3.  Explicit Membership Notification

   This document proposes an IGMP/MLD Notification operation, in which a
   mobile host *periodically* sends Current-State Record messages
   expressing which multicast sessions the host is joining, even the
   host is not requested to report the membership information by its
   upstream router (i.e., no reception of General Query message).

   The IGMP/MLD Notification operation enables the longer [Query
   Interval] value for IGMP/MLD General Query than the default [Query
   Interval].  If mobile hosts support the IGMP/MLD Notification
   operation, a multicast router can obtain downstream membership
   information without periodic and spontaneous membership solicitation
   by IGMP/MLD General Query.

   The IGMP/MLD Notification operation reduces the number of IGMP/MLD
   General Query messages.  Since a router only needs to refresh
   downstream membership information by solicited IGMP/MLD General Query
   to the hosts that do not support the IGMP/MLD Notification operation
   or leave from network without sending any message to the router, both
   [Query Interval] and [Unicast Query Interval] (described in
   Section 6.1) can be set to longer values.  This mechanism may
   conserve battery power of sleeping hosts, as these hosts do not pay
   attention to the General Query messages at short intervals.

   The [Notification Interval] value (described in Section 6.2) is the
   interval of Current-State Records periodically sent by a member host
   that joins one or more multicast sessions.  Since a mobile host
   periodically multicasts Current-State Record to all-router multicast
   address (224.0.0.2 or FF02::2) in the Notification operation, the
   [Notification Interval] value can be shorter than the regular [Query
   Interval] and [Unicast Query Interval].  When mobile hosts receive
   IGMP/MLD General Query, they reset their [Notification Interval]
   value and restart it.

   When a multicast router works with the Notification operation, it
   must maintain the following information for each multicast session to
   recognize receiver host's membership status;

   1      Receiver address - indicates an address of a receiver host
          sending the Current-State Report.

   2      Last membership report - indicates the time that the router
          receives the last Current-State Report.







Asaeda & Schmidt        Expires September 9, 2010               [Page 6]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


   3      Filter mode - indicates either INCLUDE or EXCLUDE as defined
          in [2][3].

   4      Source addresses and multicast address - indicates the address
          pair that the receiver joins.














































Asaeda & Schmidt        Expires September 9, 2010               [Page 7]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


4.  IGMP/MLD Hold and Release

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

4.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 September 9, 2010               [Page 8]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


   message is forwarded toward its upstream router.

4.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 6.3) 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 4.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 September 9, 2010               [Page 9]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


4.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 4.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 5.

4.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 September 9, 2010              [Page 10]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


      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 September 9, 2010              [Page 11]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Multicast Address                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Source Address [1]                      .
     .                                                               .
     |                                                               |
     +-                                                             -+
     .                               .                               .
     .                               .                               .
     .                               .                               .
     +-                                                             -+
     |                                                               |
     .                                                               .
     .                       Source Address [N]                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                         Auxiliary Data                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Value  Name and Meaning
   -----  ----------------

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

   2      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 September 9, 2010              [Page 12]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


          LW-IGMPv3/LW-MLDv2 ([9]), the Multicast Address Record does
          not contain the Source Address [i] field with HOLD_EXCLUDE
          type value.
















































Asaeda & Schmidt        Expires September 9, 2010              [Page 13]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


5.  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 lightweight version).  Therefore this document
   does not need to consider interoperability with older version
   protocols.

   An IGMP/MLD Notification operation is a simple optimization for
   mobile hosts to spontaneously send IGMP/MLD Current-State Report to
   their upstream multicast routers.  Since a multicast router solicits
   downstream membership information by IGMP/MLD General Query, non-
   upgraded mobile hosts can coexist in the network.  However, join and
   leave latency for non-upgraded mobile hosts may become longer due to
   the longer [Query Interval] timer configuration for multicast
   routers.  Note that the IGMP/MLD Notification operation does not
   require any modification to multicast routers.

   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 September 9, 2010              [Page 14]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


6.  Timers, Counters, and Their Default Values

6.1.  Unicast Query Interval

   IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST
   accept and process any Query whose IP Destination Address field
   contains any of the addresses (unicast or multicast) assigned to the
   interface on which the Query arrives.  According to the scenario,
   this document defines [Unicast Query Interval] value that is
   separately managed from [Query Interval] by a router and explicitly
   used for unicast General Query.  If a router keeps track of
   membership information, it can unicast General Query to tracked
   member hosts in [Unicast Query Interval].  Unicasting IGMP/MLD
   General Query would be effective especially when a wireless link is
   heavily loaded.

   [Unicast Query Interval] value has correlation with [Query Interval]
   value and the number of multicast member hosts.  The default value of
   [Query Interval] is 125 seconds [2][3], and the default value of
   [Unicast Query Interval] is 90 seconds.  [Unicast Query Interval]
   should be smaller than [Query Interval].  However, if a number of
   member hosts are active on a wireless link, a router disables unicast
   General Query (i.e. by setting [Unicast Query Interval] value 0) and
   multicasts General Query.

6.2.  Notification Interval

   The default [Notification Interval] value is 60 seconds.  The
   [Notification Interval] value MUST be shorter than both [Query
   Interval] and [Unicast Query Interval] values.

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




Asaeda & Schmidt        Expires September 9, 2010              [Page 15]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


7.  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 being robust from IP address
   spoofing.









































Asaeda & Schmidt        Expires September 9, 2010              [Page 16]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


8.  Acknowledgements

   Gorry Fairhurst, Dave Thaler, Matthias Waehlisch, and others provided
   many constructive and insightful comments.















































Asaeda & Schmidt        Expires September 9, 2010              [Page 17]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


9.  References

9.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 Internet Group
         Management Protocol Version 3 (IGMPv3) and Multicast Listener
         Discovery Version 2 (MLDv2) Protocols", RFC 5790,
         February 2010.

9.2.  Informative References

   [10]  Asaeda, H. and S. Venaas, "Tuning the Behavior of IGMP and MLD
         for Mobile Hosts and Routers",
         draft-asaeda-multimob-igmp-mld-optimization-02.txt (work in
         progress), March 2010.

   [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 September 9, 2010              [Page 18]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


         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 September 9, 2010              [Page 19]


Internet-Draft    IGMP and MLD Extensions for Mobility        March 2010


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 September 9, 2010              [Page 20]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/