Internet Draft                                     Thomas C. Schmidt
                                                     Matthias Waehlisch
   Expires: January 2004                                    FHTW Berlin
                                                              July 2003


                     Seamless Multicast Handover in a
              Hierarchical Mobile IPv6 Environment (M-HMIPv6)
                 <draft-schmidt-waehlisch-mhmipv6-00.txt>

Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 18, 2004.



Abstract

   This document introduces handover mechanisms for mobile IPv6
   multicast listeners and mobile multicast senders. Operations are
   based on a Mobile IPv6 environment with local mobility anchor points.
   These local anchor points are conformal with a Hierarchical Mobile
   IPv6 infrastructure.
   Handover latencies in the proposed scheme remain bound to local link
   switching delay and local IP address updates by means of latency
   hiding techniques. The mechanisms described in this document may also
   be used for simple seamless handovers in unicast communication.
   The M-HMIPv6 protocol operations utilize the existing HMIPv6 and
   MIPv6 messages, without defining any new control messages.




Schmidt, Waehlisch      Expires - January 2004                [Page 1]


                               M-HMIPv6                      July 2003



Table of Contents


   1. Terminology....................................................2

   2. Introduction...................................................3

   3. Overview of M-HMIPv6...........................................3
     3.1 Operations of a multicast listener..........................4
     3.2 Operations of a multicast sender............................4

   4. Multicast specific supplements.................................6
     4.1 M-HMIPv6 flag in MAP option message.........................6
     4.2 Use of Home Address option in mobile multicasts.............6
     4.3 Binding Cache processing....................................6
     4.4 Home Agent Multicast Membership control.....................7

   5. Protocol Details...............................................7
     5.1 Operations of all Mobile Nodes..............................7
     5.2 Mobile multicast listener...................................7
         5.2.1 Operations of the Mobile Node.........................8
         5.2.2 Operations of the MAP.................................8
     5.3 Mobile multicast sender.....................................9
         5.3.1 Operations of the Mobile Node.........................9
         5.3.2 Operations of the MAP.................................9
         5.3.3 Tree initialization procedure........................10
     5.4 Protocol Timer.............................................10

   6. Security Considerations.......................................10

   References.......................................................11

   Acknowledgments..................................................11

   Author's Addresses...............................................11

   A. A Note on Tunneling...........................................12


1. Terminology

   The terminology used in this document remains conformal to the
   definitions in MIPv6 [4] and HMIPv6 [5].

   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 [2].



Schmidt, Waehlisch      Expires - January 2004                [Page 2]


                               M-HMIPv6                      July 2003



2. Introduction

   Multicast-based packet distribution plays an important role in real-
   time applications as it provides the only efficient, scalable
   solution for group communication. However, multicasting itself
   conceals complex mechanisms for group membership management and
   routing, which both are of slow convergence. In conference scenarios
   such as voice or video over IP each member commonly operates as
   receiver and as sender for multicast based group communication. To
   achieve seamless mobility is one of the most challenging and demanded
   developments in IP networks today. Real-time scenarios place the
   requirement on mobility protocols to limit disruptions to less than
   100 ms and delay or jitter disturbances not to exceed 100 ms or 50 ms
   respectively. Note that 100 ms is about the duration of a spoken
   syllable in real-time audio traffic.

   The fundamental approach to deal with mobility in IPv6 [3] is the
   Mobile IPv6 Internet Draft [4]. MIPv6 operates address changes on the
   IP layer transparent to the transport layer as a device moves from
   one network to the other. MIPv6 involves roundtrip messages for
   location updates directly with the MNs Home Agent and the
   Correspondent Node. As these nodes can be far away, MIPv6 may exhibit
   slow handover performance. The Hierarchical Mobility Management
   (HMIPv6) Internet Draft [5] introduces a proxy architecture of
   Mobility Anchor Points (MAPs) to reduce communication delays with
   respect to the HA. In addition the Fast Handover for Mobile IPv6
   Internet Draft [6] proposes delay hiding techniques to further reduce
   handover times. Neither of the above thoroughly copes with
   requirements of multicast under mobility.

   This document addresses the issue of extending a HMIPv6 mobility
   infrastructure by mechanisms of sending and receiving multicast
   traffic for the MN. Local MAPs serve as temporary multicast relays to
   hide partly movement, partly handoff latency of the MN. Handover
   procedures are designed to limit any disruption or disturbance to the
   time scale needed to achieve link-local IP address configuration.
   Handover procedures between MAPs solely built on MIPv6 and HMIPv6
   signaling are described within this draft.



3. Overview of M-HMIPv6

   This multicast mobility scheme is built on a HMIPv6 environment.
   HMIPv6 introduces Mobility Anchor Points as proxy elements, which may
   be best viewed as functions on regional routers. For implementing
   multicast mobility it is advantageous, but not necessary, that these
   regional routers provide multicast routing functionality.


Schmidt, Waehlisch      Expires - January 2004                [Page 3]


                               M-HMIPv6                      July 2003



   In M-HMIPv6 a mobile multicast node uses its local MAP as anchor
   point for multicast communication. All multicast traffic is directed
   through this MAP using the RCoA as multicast subscriber or source
   address. Traffic forwarding between MN and its MAP is done using a
   bi-directional tunnel [7].

   If a MN changes location within its MAP domain it only registers its
   new LCoA with the MAP as defined in [5] without affecting multicast
   routing trees. When entering a new MAP domain a MN will learn of M-
   HMIPv6 support through router advertisements with MAP option
   messages. Multicast handover procedures will occur only if the MN
   changes into a new M-HMIPv6 enabled MAP domain and will then shift
   multicast traffic from the previous to the current MAP.

   A M-HMIPv6-aware MN SHOULD use the MAP for multicast communication.
   However, the MN MAY prefer to use its HA as a multicast anchor point,
   e.g. in visited networks within its home site. A mobile node, which
   is not M-HMIPv6 aware, will not use its MAP as a multicast anchor
   point, but will use the MIPv6 tunnel through the HA instead. In this
   sense M-HMIPv6 is simply a smooth extension of HMIPv6, which itself
   smoothly extends MIPv6.

3.1 Operations of a multicast listener

   To join a multicast group away from home the MN tunnels the MLD
   listener report to its current MAP using RCoA as source address. The
   MAP records the group address in its Binding Cache in order to
   forward multicast packets to the MN and to subscribe for and preserve
   MNs multicast group membership.

   When changing its MAP domain the MN submits a Binding Update with its
   new LCoA to the previous MAP in addition to regular HMIPv6 handover
   signaling. On its reception the previous MAP redirects forwarding
   multicast packets to the MN's new LCoA.

   If multicast support is advertised in the new domain the MN
   immediately SHOULD join the multicast group through the new MAP. Once
   multicast group traffic arrives the MN SHOULD send a Binding Update
   with zero lifetime to its previous MAP to eliminate its Binding Cache
   entry and end packet forwarding.

3.2 Operations of a multicast sender

   In a foreign MAP domain a MN initiates multicast-based communication
   by sending packets through its MAP using RCoA as its source address.
   As receivers are aware of source addresses and as the mobile RCoA
   address may change, a Home Address Destination Option MUST be
   included (s. section 4.2). By sending this way a multicast routing


Schmidt, Waehlisch      Expires - January 2004                [Page 4]


                               M-HMIPv6                      July 2003


   tree originating at the MAP will be constructed and local movement
   within a MAP domain of the MN remains transparent to multicast
   routing.


                           Sending MCast Traffic to receivers
   MAP-Domain1           /------------------------------------>
                +-------+
          /-----|  MAP1 |-----\
          |/----+-------+----\|
          ||                 ||
          ||                 ||
          ||                 ||
        +-----+              ||
        | AR1 |              ||
        +-----+              ||
          ||                 ||
          ||                 ||
          |\-----+-----+     ||    ||
          \------| MN  |     ||    ||
                 +-----+     ||    ||
                             ||    ||  Movement
                             ||    ||
   MAP-Domain2               ||    ||
                 +-----+-----/|    \/
          /------| MN  |------/
          |/-----+-----+
          ||
          ||
          ||
        +-----+
        | AR2 |
        +-----+
          ||
          ||
          ||
          |\----+-------+
          \-----|  MAP2 |
                +-------+  Sending MCast Traffic to receivers
                         \------------------------------------>

     Figure 1: Intra-MAP-domain Handover for mobile multicast senders

   Upon arrival in a new MAP domain the MN submits a Binding Update with
   its new LCoA to the previously established multicast-forwarding MAP
   and continues its multicast delivery via this previous MAP (s. figure
   1). If multicast support is advertised in the new domain the MN
   immediately initiates a new multicast routing tree with the new RCoA



Schmidt, Waehlisch      Expires - January 2004                [Page 5]


                               M-HMIPv6                      July 2003


   as source address through its current MAP. On tree initiation see
   section 5.3.3.

   The handover procedure finishes after a predefined timeout is
   reached: The mobile multicast source continues to deliver data only
   via its new MAP and stops forwarding through its previous MAP.

4. Multicast specific supplements

4.1 M-HMIPv6 flag in MAP option message

   M-HMIPv6 support is advertised within the MAP option message as used
   for router advertisements according to HMIPv6 [5]. For this purpose
   an appropriate flag is added in the following way

     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      |    Length     |  Dist |  Pref |*|*|*|*|M| Res |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Valid Lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                  Global IP Address for MAP                    +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Flags:

       *            Used by HMIPv6
       M            When set indicates that M-HMIPv6 is supported by
                    the current MAP


4.2 Use of Home Address option in mobile multicasts

   Multicast applications normally are aware of source addresses, which
   MUST NOT change during ongoing communication. A mobile multicast
   sender therefore MUST include a home address destination option as
   defined in [4]. This requirement deviates from MIPv6 multicast
   scheme.

4.3 Binding Cache processing



Schmidt, Waehlisch      Expires - January 2004                [Page 6]


                               M-HMIPv6                      July 2003


   A Correspondent Node receiving multicast packets with Home Address
   Option in general need not have a Binding Cache Entry for the home
   address included. A CN therefore MUST NOT verify multicast packets
   with respect to its Binding Cache.

4.4 Home Agent Multicast Membership control

   To provide multicast connectivity to mobile multicast listener away
   from home a HA needs to take care of the local multicast group
   management. This essentially can be done by either supplying full
   multicast routing functionalities at the HA, or by a proxy agent
   function.

   In the first case it suffices for the HA to observe MNs group
   membership at the (tunnel) interface. For a multicast proxy function
   a HA must answer MLD queries according to group membership states of
   the MN. This is an extension of the specifications in [4].

5. Protocol Details

   This section describes M-HMIPv6 operations as are to be performed for
   multicast traffic in addition to the MIPv6 and HMIPv6 protocols. Two
   perspectives need a general distinction: Multicast handling for a
   mobile listener and for a mobile sender.

   Mobility Anchor Points as defined in [5] attain the role of multicast
   mobility anchor points (M-MAPs) for mobile group members in M-HMIPv6.
   All multicast traffic is directed through M-MAPs using RCoA
   consistently as identifier with respect to the multicast routing
   tree. As MAPs in the unicast case M-MAPs may be viewed as HA proxies
   with respect to multicasting.

5.1 Operations of all Mobile Nodes

   Being at home the MN may either use its Home Agent or, a possibly
   distinct, regional M-MAP as multicast anchor point. Away from home
   the MN will learn about regional M-MAPs through router advertisements
   (s. section 4.1). A MN SHOULD register with the regional M-MAP having
   the highest preference value. If M-HMIPv6 is not supported regionally
   the MN first SHOULD attempt to employ a previously established M-MAP
   relation, second register with its HA.

   M-MAP presence is advertised via router advertisements with MAP
   option message as described in section 4.1.

5.2 Mobile multicast listener

   Any node on a multicast enabled network may subscribe to multicast
   group membership by using its link-local address in MLD membership


Schmidt, Waehlisch      Expires - January 2004                [Page 7]


                               M-HMIPv6                      July 2003


   reports. In doing so a MN cannot expect to experience a smooth
   handover performance while changing from one network to another.

   A MN utilizing a HMIPv6 MAP infrastructure can be regarded as eager
   for decreased handover delays and therefore SHOULD use the M-HMIPv6
   M-MAP functionality for other than link locally scoped multicast
   reception.

5.2.1 Operations of the Mobile Node

   A mobile multicast listener is registered with its local M-MAP (or
   HA), where both communicate via a bi-directional tunnel. The MN
   submits its MLD group membership listener report through this tunnel
   and answers membership queries of the anchor point.

   When a Mobile Node changes its network, it performs a Binding Update
   with its previous M-MAP and re-establishes the tunnel at its new
   LCoA. Thereby it continues to receive multicast group traffic.

   On entering a new M-MAP domain a MN - in addition to the above BU -
   registers with the new M-MAP and establishes a bi-directional tunnel.
   It immediately sends a MLD listener report through the newly
   available connection. Once multicast group traffic arrives from the
   new M-MAP, the MN SHOULD submit a BU with zero lifetime to its
   previous M-MAP and terminate the corresponding tunnel.

   Note that a MN SHOULD preserve a previously established M-MAP
   relation until a new multicast forwarding is completely established.
   In the case of rapid movement this may lead to a previous multicast
   anchor point persisting through several hops.

5.2.2 Operations of the MAP

   M-MAP operations for multicast listener support are completely analog
   to Home Agent functions as described in [4] and section 4.4. A M-MAP
   receiving a HMIPv6 BU from a MN will establish a bi-directional
   tunnel. On reception of a tunneled MLD listener report it will

      o record multicast group membership in its Binding Cache;
      o observe and maintain multicast group membership on its specific
       tunnel interface;
      o inquire on MNs current group membership as described in
       [4];
      o forward multicast group traffic to the MN (s. [4] on
       multicast packet forwarding).

   The M-MAP may control multicast group membership either as a
   multicast router or as a multicast proxy agent (s. section 4.4).



Schmidt, Waehlisch      Expires - January 2004                [Page 8]


                               M-HMIPv6                      July 2003


5.3 Mobile multicast sender

   A multicast source sending with its link-local address is immobile
   with respect to multicast application persistence. A mobile multicast
   sender MAY tunnel multicast traffic through its HA, using its home
   address as source address [4]. Triangular routing and significant
   binding update times lead to expected large handover delays, in
   general.

   A MN utilizing a HMIPv6 MAP infrastructure therefore SHOULD use the
   M-HMIPv6 M-MAP functionality for other than link locally scoped
   multicast transmissions.

5.3.1 Operations of the Mobile Node

   A mobile multicast sender is registered with its local M-MAP, where
   both communicate via a bi-directional tunnel. The MN submits
   multicast packets through this tunnel with the RCoA as the source
   address and the home address included in a home address destination
   option as defined in [4].

   When a Mobile Node changes its network, it performs a Binding Update
   with its previous M-MAP and re-establishes the tunnel at its new
   LCoA. Thereby it continues to send its multicast group traffic.

   On entering a new M-MAP domain a MN - in addition to the above BU -
   registers with the new M-MAP and establishes a bi-directional tunnel.
   It immediately starts the tree initialization procedure as defined in
   section 5.3.3 for any of its multicast source streams and starts a
   timer. As soon as this timer exceeds MAX_MCASTTREEINIT_TIMEOUT the MN
   MUST complete the handover by terminating multicast group forwarding
   through its previous M-MAP.

   A MN, which moves to a new link within the same M-MAP domain before
   the timeout is reached, performs a BU with its current M-MAP and
   continues the handover procedure without resetting its timers.

   A MN, which moves into a new M-MAP domain before the timeout
   occurred, continues to forward multicast traffic through its
   previously established old M-MAP, discontinues to communicate via its
   previously not fully established intermediate M-MAP, resets its timer
   and restarts the tree initialization procedure for its current M-MAP.

   Thus in case of rapid movement the MN stays bound with its formerly
   fully established (or first) M-MAP, serving the last completely
   erected multicast routing tree.

5.3.2 Operations of the MAP



Schmidt, Waehlisch      Expires - January 2004                [Page 9]


                               M-HMIPv6                      July 2003


   M-MAP operations for multicast sender support are completely analog
   to MAP functions for unicast support as described in [5].

5.3.3 Tree initialization procedure

   In preparation for a seamless handover of a multicast sender a shared
   tree needs to be constructed by the routers originating at the new M-
   MAP. In general routing trees will be initiated by submitting packets
   into the appropriate multicast group. Depending on the routing
   protocol this can be a tardy procedure. The tree initialization
   procedure provides dedicated instructions for the MN to efficiently
   bridge the multicast routing convergence gap.

   In performing this procedure the source starts to send every 10
   seconds two subsequent packets addressed to the multicast group in
   use with the complete IPv6 header but without payload in the first
   phase. Subsequence of packets is generated with a random interval
   between zero and 30 milliseconds. This first phase ends at the
   timeout
   MAX( (MAX_MCASTTREEINIT_TIMEOUT - MAX_MCASTTREEFLOW_PERIOD ), 0 ).

   Following the first phase the multicast sender submits the complete
   multicast traffic for an initialization period of
   MAX_MCASTTREEFLOW_PERIOD. The tree initialization procedure ends
   after MAX_MCASTTREEINIT_TIMEOUT is reached with continuous submission
   of regular traffic.

5.4 Protocol Timer

   MAX_MCASTTREEINIT_TIMEOUT           180 seconds (Default)
                                       160 seconds (For DVMRP regimes)
                                       0.5 seconds (For PIM-SM regimes)


   MAX_MCASTTREEFLOW_PERIOD            0.1 seconds (Default)

   Mobile nodes must allow these variables to be configured by system
   management.

6. Security Considerations

   This specification uses the concepts of Mobile IPv6 and Hierarchical
   Mobile IPv6 mobility management. All security provisions regarding
   the relation between the Mobile Node and the Home Agents and between
   the Mobile Node and the Mobility Anchor Points apply equally to this
   M-HMIPv6 concept.





Schmidt, Waehlisch      Expires - January 2004               [Page 10]


                               M-HMIPv6                      July 2003



References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   3  Hinden, R. and Deering, S. "Internet Protocol Version 6
      Specification", RFC 2460, December 1998.

   4  Johnson, D.B., Perkins, C., Arkko, J. "Mobility Support in IPv6",
      draft-ietf-mobileip-ipv6-24 (work in progress), July 2003.

   5  Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L.
      "Hierarchical Mobile IPv6 mobility management", draft-ietf-
      mobileip-hmipv6-08 (work in progress), July 2003.

   6  Koodli, R. "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-
      fast-mipv6-06 (work in progress), March 2003.

   7  Conta, A., Deering, S. "Generic Packet Tunneling in IPv6
      Specification", RFC 2473, December 1998.



Acknowledgments

   The authors would like to thank Stefan Zech (FHTW Berlin), Mark
   Palkow (DaViKo GmbH) and Hans L. Cycon (FHTW Berlin) for valuable
   discussions and a joyful collaboration.



Author's Addresses

   Thomas C. Schmidt
   FHTW Berlin
   Treskowallee 8
   Phone: +49-30-5019-2739
   Email: Schmidt@fhtw-berlin.de

   Matthias Waehlisch
   FHTW Berlin
   Treskowallee 8
   Email: mw@fhtw-berlin.de



Schmidt, Waehlisch      Expires - January 2004               [Page 11]


                               M-HMIPv6                      July 2003



A. A Note on Tunneling

   Following the concepts of MIPv6 and HMIPv6 the packet forwarding to
   and from the Mobile Node is organized by means of a tunnel section
   spanned to a static anchor component such as a MAP or a Home Agent.
   Through this technique a MN can hide its movement to CNs or to the
   routing infrastructure.

   However, keeping in mind real-time data requirements it is highly
   desirable to avoid packet encapsulation. Besides the unwanted
   overhead, a tunnel may hide QoS information of the original packet
   headers and may require load and jitter generating packet
   fragmentation, if the tunnel entry point is distinguished from the
   sender.

   Tunnelling can be avoided by a direct packet forwarding of the static
   anchor components. Such forwarding requires a change of packet's
   source or destination address at the forwarder, which usually
   conflicts with checksums covering IPv6 pseudo headers. In M-MIPv6
   multicast communication from a Mobile Node though carries a MIPv6
   extension header, the home address destination option header. This
   header denotes an alternate source address which enters the pseudo
   header instead of the original IPv6 header address.

   Multicast packets sent from the MN therefore could be forwarded by
   the MAP to the network by replacing source addresses without
   recalculation of header checksums. Employing such direct packet
   forwarding would allow a MN to distribute multicast streams without a
   tunnel.





















Schmidt, Waehlisch      Expires - January 2004               [Page 12]