Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Intended status: Standards Track                              Huawei USA
Expires: March 5, 2007                                    September 2006


                FMIPv6 extension for Multicast Handover
                draft-xia-mipshop-fmip-multicast-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 March 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).














Xia & Sarikaya            Expires March 5, 2007                 [Page 1]


Internet-Draft        FMIP extension for Multicast        September 2006


Abstract

   The document proposes an extension to FMIPv6 to enable fast multicast
   handover.  The mobile node in the foreign link being visited uses its
   care-of address(CoA) to join multicast groups via a local multicast
   router.  During handover, PAR sends MN's MLD state to NAR which helps
   NAR establish the multicast delivery trees in advance.  PAR also
   tunnels all multicast traffic to NAR which buffers them to be
   delivered after the handover is completed.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Operation of Multicast Fast Handover . . . . . . . . . . . . .  5
     3.1.  Predictive Fast Handover . . . . . . . . . . . . . . . . .  5
     3.2.  Reactive Fast Handover . . . . . . . . . . . . . . . . . .  7
     3.3.  Handover Latency Analysis  . . . . . . . . . . . . . . . .  7
   4.  New Options  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Multicast Group Information Option . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15























Xia & Sarikaya            Expires March 5, 2007                 [Page 2]


Internet-Draft        FMIP extension for Multicast        September 2006


1.  Introduction

   Fast Mobile IPv6 (FMIPv6) [FMIPv6] extends Mobile IPv6 for reducing
   handover delays.  However FMIPv6 does not have any provisions for
   multicast communication.  Mobile nodes are more and more involved in
   multicast communication due to the recent developments such as mobile
   IPTV.

   [MULTICASTPS] specifies the problem scope for a multicast mobility
   management.  The attempt is made to subdivide the various challenges
   according to their originating aspects and to present existing
   proposals for solution.  There are two general multicast mobility
   problems, that is, Multicast Source Mobility and Multicast Listener
   Mobility.  This draft only deals with the latter.

   [MHMIPV6] extends the Hierarchical Mobile IPv6 [HMIPv6] to introduce
   handover mechanisms for IPv6 mobile multicast listeners and mobile
   multicast senders.

   The mobility support for IPv6 protocol [MIP] has specified two basic
   methods for mobile multicast:

   1.  via a bi-directional tunnel from a MN to its Home Agent.  The MN
       uses its home address to send MLD(Multicast Listener Discovery)
       messages.  The MLD messages are tunneled to its Home Agent.

   2.  via a local multicast router on the foreign link being visited.
       the MN MUST use its care-of address when sending MLD packets

   [MDMA] addresses the problems of the above two methods when
   delivering IPv6 multicast traffic to MNs.  An approach named Mobile
   IPv6 Multicast with Dynamic Multicast Agent is proposed.

   This draft proposes an elaborate way only for the latter method, that
   is, using CoA to convey multicast control information.  This scenario
   can be deployed in mobile IPTV.

   In handover preparation, a previous access router informs a new
   access router to build related multicast deliver trees; during
   handover, the NAR buffers multicast traffic; after handover, The NAR
   sends the buffered traffic as soon as possible.  These benefits can
   be achieved through extension of Fast Handover for Mobile IPv6
   [FMIPv6]

   The document continues in Section 2 to define the terminology used
   and then Section 3 defines the protocol operation, Section 4
   introduces a new option, Section 5 discusses the security
   considerations.  Finally, Section 6 concludes the document.



Xia & Sarikaya            Expires March 5, 2007                 [Page 3]


Internet-Draft        FMIP extension for Multicast        September 2006


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 BCP 14 [STANDARDS].

   FMIPv6: Fast Handover for Mobile IPv6.

   DAD: Duplicate Address Detection.

   Mobile Node (MN): A Mobile IPv6 host.

   Access Router (AR): The MN's default router.

   Previous Access Router (PAR): The MN's default router prior to its
   handover.

   New Access Router (NAR): The MN's default router subsequent to its
   handover.

   Previous CoA (PCoA): The MN's Care of Address valid on PAR's subnet.

   New CoA (NCoA): The MN's Care of Address valid on NAR's subnet.

   Router Solicitation for Proxy Advertisement (RtSolPr): A message from
   the MN to the PAR requesting information for a potential handover.

   Proxy Router Advertisement (PrRtAdv): A message from the PAR to the
   MN that provides information about neighboring links facilitating
   expedited movement detection.  The message also acts as a trigger for
   network-initiated handover.

   Fast Binding Update (FBU): A message from the MN instructing its PAR
   to redirect its traffic (toward NAR).

   Fast Binding Acknowledgment (FBack): A message from the PAR in
   response to an FBU.

   Fast Neighbor Advertisement (FNA): A message from the MN to the NAR
   to announce attachment, and to confirm the use of NCoA when the MN
   has not received an FBACK.

   Handover Initiate (HI): A message from the PAR to the NAR regarding
   an MN's handover.

   Handover Acknowledge (HAck): A message from the NAR to the PAR as a
   response to HI.




Xia & Sarikaya            Expires March 5, 2007                 [Page 4]


Internet-Draft        FMIP extension for Multicast        September 2006


3.  Operation of Multicast Fast Handover

   In Multicast Fast Handover (MFH), the mobile node joins multicast
   groups such as IPTV sessions using its care-of address (CoA).  MLD
   state consisting of the multicast group address and addresses of each
   sender resulting from MN's multicast communication is kept in AR.

   MFH extends FMIPv6 signalling as follows:

   1.  PAR sends MLD state to NAR during handover.

   2.  PAR tunnels all multicast packets to NAR.

   3.  NAR after receiving MLD state, establishes multicast delivery
       tree during handover.

   We explain MFH operation for the predictive and reactive fast
   handover modes of FMIPv6.

3.1.  Predictive Fast Handover

                 MN                    PAR                  NAR
                  |                     |                    |
                  |------RtSolPr------->|                    |
                  |<-----PrRtAdv--------|                    |
                  |                     |                    |
                  |------FBU----------->|--------HI--------->|
                  |                     |<------HAck---------|
                  |          <--FBack---|--FBack--->         |
                  |                     |                    |
               disconnect             forward                |
                  |                   packets===============>|
                  |                     |                    |
                  |                     |                    |
              connect                   |                    |
                  |                     |                    |
                  |--------- FNA --------------------------->|
                  |<=================================== deliver packets
                  |                                          |

                    Figure 1: Predictive Fast Handover

   Figure 1 is characterized as "predictive" mode of operation in which
   the MN receives an FBack on the previous link.

   1.  With interaction of RtSolPr and PrRtAdv, the MN formulates a
       prospective NCoA and learns some information about the NAR.




Xia & Sarikaya            Expires March 5, 2007                 [Page 5]


Internet-Draft        FMIP extension for Multicast        September 2006


   2.  The purpose of the FBU is to authorize PAR to bind PCoA to NCoA,
       so that arriving packets can be tunneled to the new location of
       MN.  Upon receiving FBU, PAR sends HI message.  PAR MUST include
       a new option called Multicast Group Information Option in HI
       message.  The option which is defined in Section 4.1 consists of
       the multicast groups MN is a member of and other related
       information needed in [MLDv2].

   3.  HI with Multicast Group Information Option (MGIO) triggers the
       NAR:

       1.  to inspect MGIO.  If NAR already has the state for the
           multicast group, no action is required.

       2.  to construct new multicast delivery trees for any new
           multicast group.  For example, in PIM-SM [PIM-SM], On
           receiving the MN's expression of interest, the AR then sends
           a PIM Join message towards a router which is the root of the
           non-source-specific distribution tree for a multicast group.
           The Join message travels hop-by-hop towards the root router
           for the group, and in each router it passes through,
           multicast tree state for the group is instantiated.

   4.  When HAck message is received, the PAR MUST deliver all the
       traffic to the NAR for buffering through an established tunnel,
       unicast and multicast traffic.

   5.  Once FNA is received, the NAR delivers all the buffered packets
       to the MN.

   6.  On finishing IPv6 network attachment on a NAR, the MN initiates
       multicast signaling procedure using its new CoA.  At the same
       time, the MN receives buffered multicast traffic from the NAR and
       tunneled traffic from the PAR.  When multicast delivery trees are
       constructed, the PAR stops delivering multicast traffic to MN
       while the NAR delivers multicast traffic directly.















Xia & Sarikaya            Expires March 5, 2007                 [Page 6]


Internet-Draft        FMIP extension for Multicast        September 2006


3.2.  Reactive Fast Handover

                 MN                    PAR                  NAR
                  |                     |                    |
                  |------RtSolPr------->|                    |
                  |<-----PrRtAdv--------|                    |
                  |                     |                    |
               disconnect               |                    |
                  |                     |                    |
                  |                     |                    |
               connect                  |                    |
                  |------FNA[FBU]-------|------------------->|
                  |                     |<-----FBU-----------|
                  |                     |------FBack-------->|
                  |                   forward                |
                  |                   packets===============>|
                  |                     |                    |
                  |<=================================== deliver packets
                  |                                          |

                     Figure 2: Reactive Fast Handover

   Figure 2 is characterized as "reactive" mode of operation.  In this
   mode, the MN does not receive the FBack on the previous link.  PAR
   MUST include Multicast Group Information Option in FBU which is
   encapsulated in FNA.  Once receiving FBU, the PAR establishes a
   tunnel to MN and delivers related multicast traffic to the MN.  At
   the same time, the MN initiates multicast signaling with NCoA in the
   visited network.  Once the NAR has constructed related multicast
   deliver trees the NAR delivers multicast traffic directly.

3.3.  Handover Latency Analysis

   When an MN moves from one AR to another AR, the overall multicast
   handover consists of link layer(L2) delays, network layer(L3)
   attachment delays, and multicast signaling delays:

   HO time = L2 delay + L3 network attachment delays + multicast
   signaling delays.

   FMIPv6 reduces HO time especially in predictive mode.  L2 delay is
   unavoidable, while buffering related multicast traffic in an NAR can
   reduce the affect of a handover delay.  IPv6 network attachment
   commonly includes activities such as default router discovery, CoA
   configuration and its DAD.  Through RtSolPr and PrRtAdv interactions,
   an MN can finish the network attachment before link layer handover.
   Multicast signaling consists of joining multicast groups and
   constructing multicast delivery trees.  Through tunnel between a PAR



Xia & Sarikaya            Expires March 5, 2007                 [Page 7]


Internet-Draft        FMIP extension for Multicast        September 2006


   and a NAR, older delivery trees can be used before new delivery trees
   are constructed.

















































Xia & Sarikaya            Expires March 5, 2007                 [Page 8]


Internet-Draft        FMIP extension for Multicast        September 2006


4.  New Options

   This draft introduces one new option.

4.1.  Multicast Group Information Option

   One or more Multicast Group Information Options can be included in
   the message FBU and HI.

       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     | Record Type   | Reserved      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reserved                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                          Multicast Address                    +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                         Source Address [1]                    +
      |                                                               |
      .                               .                               .
      |                                                               |
      +                         Source Address [N]                    +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Multicast Group Information Option

   Type: TBD

   Length: The size of this option in 8 octets.  The option is variable

   Reserved: MUST be set to zero

   Record Type: refer to section 5.2.5 in [MLDv2].

   Multicast Address: the multicast group address



Xia & Sarikaya            Expires March 5, 2007                 [Page 9]


Internet-Draft        FMIP extension for Multicast        September 2006


   Source Address: a vector of N unicast addresses of the senders of
   this multicast group.

















































Xia & Sarikaya            Expires March 5, 2007                [Page 10]


Internet-Draft        FMIP extension for Multicast        September 2006


5.  Security Considerations

   This memo is based on FMIPv6, and no additional messages are defined.
   No additional threats are introduced.  For a more analysis, see
   related section. [FMIPv6]














































Xia & Sarikaya            Expires March 5, 2007                [Page 11]


Internet-Draft        FMIP extension for Multicast        September 2006


6.  Conclusions

   We presented a simple extension to FMIPv6 to transfer multicast state
   of a mobile node from the previous access router to the new access
   router during handover.  We also defined a new option to be used in
   FMIPv6 messages.













































Xia & Sarikaya            Expires March 5, 2007                [Page 12]


Internet-Draft        FMIP extension for Multicast        September 2006


7.  References

7.1.  Normative References

   [FMIPv6]   Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005, <ftp://ftp.isi.edu/in-notes/rfc4068>.

   [HMIPv6]   Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 Mobility Management
              (HMIPv6)", RFC 4140, August 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4140>.

   [MIP]      Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004,
              <ftp://ftp.isi.edu/in-notes/rfc3775>.

   [MLDv2]    Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
              <ftp://ftp.isi.edu/in-notes/rfc3810>.

   [PIM-SM]   Fenner, B., Handley, M., Holbrook, H., and I.  Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006,
              <ftp://ftp.isi.edu/in-notes/rfc4601>.

   [STANDARDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997,
              <ftp://ftp.isi.edu/in-notes/rfc2119>.

7.2.  Informative References

   [MDMA]     Zhang,  H-K.,  Shen,  B., Zhang, B-Y., Liu, E-H., and S.
              Dawkins, "Mobile IPv6 Multicast with Dynamic Multicast
              Agent", March 2006,
              <draft-zhang-mipshop-multicast-dma-02.txt>.

   [MHMIPV6]  Schmidt, Thomas C. and M. Waehlisch, "Seamless Multicast
              Handover in a Hierarchical Mobile IPv6 Environment
              (M-HMIPv6)", November 2005,
              <draft-schmidt-waehlisch-mhmipv6-04.txt>.

   [MULTICASTPS]
              Schmidt, Thomas C. and M. Waehlisch, "Multicast Mobility
              in MIPv6: Problem Statement", October 2005,
              <draft-schmidt-mobopts-mmcastv6-ps-00.txt>.





Xia & Sarikaya            Expires March 5, 2007                [Page 13]


Internet-Draft        FMIP extension for Multicast        September 2006


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: bsarikaya@huawei.com

































Xia & Sarikaya            Expires March 5, 2007                [Page 14]


Internet-Draft        FMIP extension for Multicast        September 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xia & Sarikaya            Expires March 5, 2007                [Page 15]