Network Working Group                                            Sun. Yi
Internet-Draft                                                       ICT
Intended status: Standards Track                               Feng. Bin
Expires: August 12, 2007                                            BUPT
                                                          Zhang. Yucheng
                                                                    UEST
                                                           Zheng. Rusong
                                                                     ICT
                                                            Dong. Wenxia
                                                                   SWJTU
                                                            Shi. Jinglin
                                                                     ICT
                                                        Dutkiewicz. Eryk
                                                University of Wollongong
                                                        February 8, 2007


   Extensions to Resource Reservation Protocol (RSVP) for Mobile IPv6
                      draft-sunyi-fast-rsvp-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 August 12, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).



Yi, et al.               Expires August 12, 2007                [Page 1]

Internet-Draft                  Fast RSVP                  February 2007


Abstract

   RSVP [1] is designed as a signaling protocol that provides end-to-end
   QoS guarantee for real-time services in the fixed hardwired network.
   However, when used in the mobile environment, the protocol doesn't
   work well due to the mobility of the endpoints.  Immediately after a
   handover occurs, because of the lack of resource reservation in the
   handoff target subnet, QoS of the session degrades notably.  Another
   problem is that when route optimization is implemented, the protocol
   will be invalidated due to certain features of the route optimization
   mechanism.

   This document proposes extensions to RSVP.  The extensions enable
   RSVP to operate in the mobile IPv6 network while providing advanced
   resource reservation before handover and resource reservation on the
   optimized route after handover.  With these features, QoS of the
   sessions can be guaranteed and the utilization of network resources
   can be enhanced resulting in the improvement of overall network
   performance.
































Yi, et al.               Expires August 12, 2007                [Page 2]

Internet-Draft                  Fast RSVP                  February 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview of RSVP Extensions  . . . . . . . . . . . . . . . . .  9
     3.1.  Addressing the QoS Guarantee during Handover . . . . . . .  9
     3.2.  Cooperation between the RSVP Module and the Mobile IP
           Module . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  RSVP Extensions Operation  . . . . . . . . . . . . . . . . 11
   4.  Details of RSVP Extensions . . . . . . . . . . . . . . . . . . 23
     4.1.  MN is the Receiver of the Session  . . . . . . . . . . . . 23
     4.2.  MN is the Sender of the Session  . . . . . . . . . . . . . 28
     4.3.  MN is both the Sender and the Receiver of the Session  . . 33
   5.  Miscellaneous  . . . . . . . . . . . . . . . . . . . . . . . . 42
     5.1.  RSVP Extensions Capability Exchange  . . . . . . . . . . . 42
     5.2.  Distinguishing Handover Sessions and New Sessions  . . . . 42
     5.3.  Bidirectional Reservation  . . . . . . . . . . . . . . . . 42
     5.4.  Utilization of Advanced Reservation before Handover  . . . 43
   6.  New Messages and Objects . . . . . . . . . . . . . . . . . . . 44
     6.1.  Modified Common Header . . . . . . . . . . . . . . . . . . 44
     6.2.  New Objects  . . . . . . . . . . . . . . . . . . . . . . . 45
       6.2.1.  New MSESSION Object  . . . . . . . . . . . . . . . . . 45
       6.2.2.  New Router_Notify Object . . . . . . . . . . . . . . . 46
       6.2.3.  New Tunnel_Info Object . . . . . . . . . . . . . . . . 47
     6.3.  New Messages . . . . . . . . . . . . . . . . . . . . . . . 48
       6.3.1.  HandoverForecast Message . . . . . . . . . . . . . . . 48
       6.3.2.  HandoverForecastResponse Message . . . . . . . . . . . 49
       6.3.3.  HandoverForecastConfirm Message  . . . . . . . . . . . 49
       6.3.4.  TunnelStateChange Message  . . . . . . . . . . . . . . 49
       6.3.5.  HandoverForecastError Message  . . . . . . . . . . . . 50
       6.3.6.  HandoverForecastTear . . . . . . . . . . . . . . . . . 50
       6.3.7.  TunnelPath Message . . . . . . . . . . . . . . . . . . 51
       6.3.8.  TunnelResv Message . . . . . . . . . . . . . . . . . . 51
       6.3.9.  TunnelPathTear Message . . . . . . . . . . . . . . . . 51
       6.3.10. TunnelResvTear Message . . . . . . . . . . . . . . . . 52
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 53
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 54
     8.1.  RSVP Common Header Flags . . . . . . . . . . . . . . . . . 54
     8.2.  RSVP Objects . . . . . . . . . . . . . . . . . . . . . . . 54
     8.3.  RSVP Messages  . . . . . . . . . . . . . . . . . . . . . . 54
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 56
     10.2. Informative References . . . . . . . . . . . . . . . . . . 56
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
   Intellectual Property and Copyright Statements . . . . . . . . . . 59





Yi, et al.               Expires August 12, 2007                [Page 3]

Internet-Draft                  Fast RSVP                  February 2007


1.  Introduction

   RSVP [1]is designed as a signaling protocol that provides end-to-end
   QoS guarantee for real-time services in the fixed hardwired network.
   However, when used in the mobile environment, the protocol doesn't
   work well due to the mobility of the endpoints.  Immediately after a
   handover occurs, because of the lack of resource reservation in the
   handoff target subnet, QoS of the sessions degrade notably.  Another
   problem is that when route optimization is implemented (which is a
   compelling strategy in Mobile IPv6 network [2]), the protocol will be
   invalidated due to certain features of the route optimization
   mechanism.  This document proposed extensions to RSVP.  The
   extensions enable RSVP to operate in the mobile IPv6 network while
   providing advanced resource reservation before handover and resource
   reservation on the optimized route after handover.  With these
   features QoS of the sessions can be guaranteed and the utilization of
   network resources can be enhanced resulting in the improvement of
   overall network performance.

   The extensions proposed in this document address the following
   problems: (1) How to make the mobile node realize fast handover with
   QoS guarantees and (2) How to establish resource reservation on the
   optimized route after Mobile IPv6 route optimization.

   The extensions proposed in this document divide a handover process
   with QoS guarantees into 2 stages:

   1.  Setup of the resource reservation neighbor tunnel before
       handover.

   2.  Resource reservation on the optimized route after handover.

   In the first stage, based on the handover prediction result that the
   mobile IP module makes, the extensions proposed in this document
   establish a QoS guaranteed tunnel in advance before the handover
   occurs.  In the second stage, in co-operation with the route
   optimization mechanism used in Mobile IPv6 protocol, the extensions
   proposed in this document establish resource reservation on the
   optimized route after handover.  The reference handover scenario is
   illustrated in Figure 1.

   To support the basic functions, some new messages are defined and
   some new objects are added to the messages in traditional RSVP.  In
   addition, some primitives are also defined for exchanging information
   between the mobile IP module and the RSVP module within the same
   node.  With the modifications of the RSVP module, most of the
   functions in this document can be met.  However, some modifications
   of the mobile IP module are also required to fulfill the objectives



Yi, et al.               Expires August 12, 2007                [Page 4]

Internet-Draft                  Fast RSVP                  February 2007


   of this document.


                                   +---------------+
                                   | Correspondent |
                                   | Node (CN)     |
                                   +---------------+
                                           |
                                           |
                                   +---------------+
                           /-------| IPv6 network  |-------\
                          /        +---------------+        \
                         /                                   \
                 +---------------+                   +---------------+
                 |    Previous   |                   |      New      |
                 | Access Router |                   | Access Router |
                 |     (PAR)     |                   |     (NAR)     |
                 +---------------+                   +---------------+

                  +-------------+                     +-------------+
                  | Mobile Node |-------------------->| Mobile Node |
                  |    (MN)     |                     |    (MN)     |
                  +-------------+                     +-------------+


                 Figure 1: Reference Scenario for Handover

























Yi, et al.               Expires August 12, 2007                [Page 5]

Internet-Draft                  Fast RSVP                  February 2007


2.  Terminologies

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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.  The use of
   the term, "silently ignore" and "silently discard" is not defined in
   RFC 2119.  However, the terms are used in this document and can be
   similarly construed.

   The following terminology and abbreviations are used in this
   document.


         Mobile Node (MN)
               A mobile host supporting Mobile IPv6.

         Correspondent Node (CN)
               The peer host with which MN is communicating.

         Previous Access Router (PAR)
               The MN's default router before its handover event.

         New Access Router (NAR)
               The MN's default router after its handover event.

         Care-of Address (CoA)
               A unicast routable address associated with a MN
               while visiting a foreign link.

         Previous CoA (PCoA)
               The MN's care-of address used in PAR's subnet.

         New CoA (NCoA)
               The MN's care-of address used in NAR's subnet.

         Handover
               A procedure of terminating the IP connectivity to
               one subnet and obtaining a new IP connectivity to
               another subnet.

         RSVP Proxy
               The module on a access router which can initiate
               RSVP procedures or respond to RSVP requests on
               behalf of MN.

         Advanced Reservation
               Resource reservation which is established before



Yi, et al.               Expires August 12, 2007                [Page 6]

Internet-Draft                  Fast RSVP                  February 2007


               the handover event occurs.

         HandoverForecast.ind (HF.ind)
               A primitive from MN's mobile IP module to its RSVP
               module indicating a predicted handover.

         HandoverForecastConfirm.ind (HFConfirm.ind)
               A primitive from MN's mobile IP module to its RSVP
               module indicating a prediction is successful.

         HandoverForecastError.ind (HFError.ind)
               A primitive from MN's mobile IP module to its RSVP
               module indicating a prediction fails.

         SessionHandover.req (SH.req)
               A primitive from CN's (MN's) mobile IP module to
               its RSVP module requesting whether the session data
               to MN (CN) can be switched to the optimized route.

         SessionHandover.ind (SH.ind)
               A primitive from CN's (MN's) RSVP module to its
               mobile IP module indicating the session data to MN(CN)
               can be switched the optimized route.

         AddrNotify.ind (AN.ind)
               A primitive from router's RSVP module to its mobile IP
               module indicating the home address and care-of address
               of MN so that mobile IP module can rebuild the "Type 2
               routing header" or "Home address option" accordingly.

         HandoverForecast (HF)
               A message from MN's RSVP module to PAR's (NAR's) RSVP
               module providing information about the predicted
               handover.  The message acts as a trigger to establish
               the resource reservation tunnel.

         HandoverForecastResponse (HFRsp)
               A message from PAR's (NAR's) RSVP module to MN's RSVP
               module indicating whether the resource reservation
               tunnel has been established successfully.

         HandoverForecastConfirm (HFConfirm)
               A message from MN's RSVP module to PAR's RSVP module
               indicating the handover prediction is successful.

         TunnelStateChange (TSChange)
               A message from PAR (NAR) to NAR (PAR) to indicate the
               intermediate routers to change the reservation type



Yi, et al.               Expires August 12, 2007                [Page 7]

Internet-Draft                  Fast RSVP                  February 2007


               (see section 5.4).

         HandoverForecastError (HFError)
               A message from MN's RSVP module to PAR's (NAR's) RSVP
               module indicating the handover prediction fails, so
               that the resource reservation tunnel can be rebuilt
               in time.

         HandoverForecstTear (HFTear)
               A message from MN's RSVP module to PAR's RSVP module
               to indicate PAR tearing down the resource reservation
               tunnel which is mistakenly built by the false
               handover prediction.

         TunnelPath (TPath)
               A message exchanged between RSVP routers to establish
               PATH state over the resource reservation tunnel.

         TunnelResv (TResv)
               A message exchanged between RSVP routers to establish
               RESV state over the resource reservation tunnel.

         TunnelPathTear (TPathTear)
               A message exchanged between RSVP routers to release
               the resources reserved in advance on the falsely built
               resource reservation tunnel.

         TunnelResvTear (TResvTear)
               A message exchanged between RSVP routers to release
               the resources reserved in advance on the falsely built
               resource reservation tunnel.




















Yi, et al.               Expires August 12, 2007                [Page 8]

Internet-Draft                  Fast RSVP                  February 2007


3.  Overview of RSVP Extensions

3.1.  Addressing the QoS Guarantee during Handover

   In traditional RSVP, the SESSION object is used to label a session.
   Unfortunately, in mobile environment, the content of the SESSION
   object may change after a handover because the "IPv6 DestAddress"
   field changes.  However, the resource reservation along the path
   still corresponds to the old SESSION object and therefore, the QoS of
   the service flow is no longer guaranteed.  The extensions proposed in
   this document introduce a new MSESSION (see section 6.2.) object to
   replace the SESSION object in the traditional RSVP protocol.
   Compared with the SESSION object, MSESSION adds an "IPv6 HomeAddress"
   field in the object.  The "IPv6 HomeAddress" field is filled with the
   MN's home address and its value is constant during handover, so we
   can utilize it to label the session.  In mobile environment, the RSVP
   router MUST label a session based on the content of the MSESSION and
   set up the corresponding Path State and Resv State accordingly.

   The key factor affecting the QoS of the session during handover is
   how fast resource reservation can be re-established after MN hands
   over to a new subnet.

   To reduce the resource reservation re-establishment latency, the
   extensions proposed in this document enable the RSVP module to make
   advanced resource reservation on the neighbor tunnel when MN is still
   connected to PAR.  Based on the handover prediction result made by
   MN's mobile IP module, the RSVP module of MN would send a
   HandoverForecast message to PAR (NAR) to inform it about the handover
   event.  Then PAR (NAR) utilizes this information to make advanced
   resource reservation on the tunnel before the handover occurs.  So
   when MN moves to NAR's subnet, the session between MN and CN can use
   this advanced resource reservation neighbor tunnel to transmit the
   session data and QoS of the session can be guaranteed.

   The extensions proposed in this document specify a resource
   reservation tunnel between PAR and MN's NCoA, via NAR.  As
   illustrated in Figure 2, PAR and MN are the two endpoints of the
   resource reservation neighbor tunnel.  However, the reservation
   should be established before the handover occurs, and MN is not
   within NAR's subnet at that time.  Therefore, the extensions proposed
   in this document introduce a new entity named RSVP proxy, which can
   make advanced resource reservation on behalf of MN.  In Figure 2, NAR
   acts as an RSVP proxy, sending or receiving RSVP messages on behalf
   of MN before MN hands over to its subnet.






Yi, et al.               Expires August 12, 2007                [Page 9]

Internet-Draft                  Fast RSVP                  February 2007


            +---------+    RSVP TUNNEL    +---------+    +--------+
            |   PAR   |-------------------|   NAR   |----|   MN   |
            |         |-------------------|         |----|        |
            +---------+                   +---------+    +--------+
                                          (RSVP Proxy)


                   Figure 2: RSVP TUNNEL and RSVP Proxy

   By setting up a resource reservation tunnel between two neighbor
   subnets in advance, the mobile node could realize handover with QoS
   guarantee.  However, the use of tunnel induces the triangular route
   problem, thus causing network resource waste.  In Mobile IPv6 [2],
   route optimization becomes a compelling strategy, and the reservation
   process on the optimized route should be considered.  However, in
   order to guarantee the QoS of the session, communication between MN
   and CN must keep utilizing the tunnel until resources have been
   successfully reserved on the optimized route.

3.2.  Cooperation between the RSVP Module and the Mobile IP Module

   With the extensions of the RSVP module, most of the functions can be
   met.  However, some modifications to the mobile IP module and some
   information exchanging between RSVP module and mobile IP module are
   also required.  The mobile IP module MUST have the following
   functions.

   1.  When predicting that a handover is imminent, the mobile IP module
       of MN MUST send a HandoverForecast.ind to the RSVP module.  The
       HandoverForecast.ind MUST include the information such as the
       predicted NAR's IP address and the corresponding NCoA.

   2.  After MN hands over to the new subnet, the mobile IP module MUST
       check whether the current subnet is the same as the predicted
       handover target subnet and send certain indication to the RSVP
       module depending on the checking result.  If the handover
       prediction is successful, a HandoverForecastConfirm.ind MUST be
       sent.  Otherwise, a HandoverForecastError.ind MUST be sent
       immediately.  The HandoverForecastError.ind MUST contain the
       current in use CoA and MAY contain the formerly falsely predicted
       CoA of MN.

   3.  When MN is stable in the new subnet, the mobile IP module MUST
       start the route optimization process.  If the mobile IP module of
       the CN receives a BU message from MN, it MUST send a
       SessionHandover.req to the RSVP module and MUST NOT redirect the
       session data to the optimized route until receiving the
       SessionHandover.ind from the RSVP module.  The



Yi, et al.               Expires August 12, 2007               [Page 10]

Internet-Draft                  Fast RSVP                  February 2007


       SessionHandover.req MUST contain the session's home address and
       NCoA.

   4.  If intermediate routers on the optimized route receive a PATH or
       RESV message with "Type 2 routing header" or "Home address
       option" in IP header fields, the mobile IP module of the router
       MUST utilize the AddrNotify.ind acquired from the RSVP module to
       rebuild the "Type 2 routing header" or "Home address option"
       before delivering the message to the next hop.

3.3.  RSVP Extensions Operation

   The extensions proposed in this document begin when the mobile IP
   module on MN sends a HandoverForecast.ind to the RSVP module on the
   same node and then the RSVP module sends a HandoverForecast message
   (see section 6.3.1.) to PAR or NAR depending on whether MN is the
   sender or the receiver of the session.  If MN is the session
   receiver, the HandoverForecast message will be sent to PAR.
   Otherwise, the HandoverForecast message will be sent to NAR.  The
   mobile IP module MAY send a HandoverForecast.ind at any convenient
   time, for instance as a response to some link-specific event (a
   "trigger") or simply after a handover prediction by GPS.  However,
   the expectation is that prior to sending the HandoverForecast
   message, the mobile IP module on MN MUST have discovered the
   predicted handover target subnet (i.e., NAR in Figure 1) and acquired
   a NCoA that can be used in that subnet.

   With the information provided in the HandoverForecast message, PAR
   (NAR) formulates a TunnelPath message (see section 6.3.7) and NAR
   (PAR) replies a TunnelResv message (see section 6.3.8).  Finally,
   through the message exchange between PAR and NAR, a resource
   reservation tunnel is established in advance and MN can use this QoS-
   guaranteed path immediately after the handover event if the handover
   prediction is successful.

   When PAR (NAR) receives the TunnelResv message, it sends a
   HandoverForecastResponse message (see section 6.3.2) to MN to
   indicate the completion of the resource reservation tunnel
   establishment.  However, if the reservation on the tunnel fails, the
   router also sends a HandoverForecastResponse message to MN to
   indicate the failure, and then MN will stop the following process.

   After MN moves to the new subnet, it checks whether the current
   subnet is the same as the predicted handover target subnet (e.g.
   comparing the IP address of the current access router and the
   predicted access router).  Depending on whether the handover
   prediction is correct, there are two modes of the operation.




Yi, et al.               Expires August 12, 2007               [Page 11]

Internet-Draft                  Fast RSVP                  February 2007


   1.  The prediction is successful.  The mobile IP module of MN starts
       the binding update process with PAR.  After that, it sends a
       HandoverForecastConfirm.ind to the RSVP module in the same node
       and the latter sends a HandoverForecastConfirm message (see
       section 6.3.3.) to PAR or NAR depending on whether MN is the
       receiver or the sender of the session.  On receiving the
       HandoverForecastConfirm message, PAR (NAR) sends a
       TunnelStateChange (see section 6.3.4) message to NAR (PAR) to
       indicate to the intermediate routers to change the reservation
       type (see section 5.4).

   2.  The prediction fails.  The mobile IP module of MN locates the
       correct NAR and then starts the binding update process with PAR.
       After that, it sends a HandoverForecastError.ind to the RSVP
       module on the same node so that the RSVP module SHALL take the
       following actions:

   If MN is the session receiver, it sends a HandoverForecastError
   message (see section 6.3.5.) to PAR to indicate that the handover
   prediction fails.  After receiving the HandoverForecastError message,
   PAR sends a TunnelPath message to the current NAR of MN to establish
   the resource reservation tunnel.  In addition, MN sends a
   HandoverForcastTear message (see section 6.3.6) to PAR and on
   receiving this message PAR sends a TunnelPathTear message (see
   section 6.3.9.) to the formerly predicted NAR to release the
   previously mistakenly built reservation tunnel.

   If MN is the session sender, it sends a HandoverForecastError message
   to the current NAR to indicate the handover prediction fails.  After
   receiving the HandoverForecastError message, NAR sends a TunnelPath
   message to PAR of MN to establish the resource reservation tunnel.
   In addition, MN sends a HandoverForcastTear message to PAR and on
   receiving this message, PAR sends a TunnelResvTear message (see
   section 6.3.10) to the formerly predicted NAR to release the
   previously mistakenly built reservation tunnel.

   The scenarios with successful handover predictions are illustrated in
   Figure 3, Figure 4 and Figure 5, considering MN act as the session
   receiver only, the session sender only, and both the session receiver
   and session sender respectively.  For convenience, these scenarios
   are characterized as a "prediction success" mode of operation.  The
   scenarios with failed handover predictions are illustrated in Figure
   6, Figure 7 and Figure 8, considering MN act as the session receiver
   only, the session sender only, and both the session receiver and
   session sender respectively.  For convenience, these scenarios are
   characterized as a "failure recovery" mode of operation.





Yi, et al.               Expires August 12, 2007               [Page 12]

Internet-Draft                  Fast RSVP                  February 2007


                        MN                    PAR           NAR
          |----------------------------|       |             |
          | Mobile IP            RSVP  |       |             |
          |  Module             Module |       |             |
          |----------------------------|       |             |
               |                  |            |             |
            predict               |            |             |
            handover              |            |             |
               |------HF.ind----->|            |             |
               |                  |-----HF---->|             |
               |                  |            |----TPath--->|
               |                  |            |<---TResv----|
               |                  |<---HFRsp---|             |
               |                  |            |             |
          disconnect              |            |             |
               |                  |            |             |
            connect               |            |             |
               |                  |            |             |
               |------------------------BU------------------>|
               |                  |            |<-----BU-----|
               |                  |            |-----BAck--->|
               |<----------------------BAck------------------|
               |--HFConfirm.ind-->|            |             |
               |                  |-HFConfirm->|             |
               |                  |            |--TSChange-->|
               |                  |            |             |

                     Figure 3: "Prediction Success" Mode
                          (MN is the session receiver)






















Yi, et al.               Expires August 12, 2007               [Page 13]

Internet-Draft                  Fast RSVP                  February 2007


                        MN                    PAR           NAR
          |----------------------------|       |             |
          | Mobile IP            RSVP  |       |             |
          |  Module             Module |       |             |
          |----------------------------|       |             |
               |                  |            |             |
            predict               |            |             |
            handover              |            |             |
               |------HF.ind----->|            |             |
               |                  |------------HF----------->|
               |                  |            |<---TPath----|
               |                  |            |----TResv--->|
               |                  |<----------HFRsp----------|
               |                  |            |             |
          disconnect              |            |             |
               |                  |            |             |
            connect               |            |             |
               |                  |            |             |
               |------------------------BU------------------>|
               |                  |            |<-----BU-----|
               |                  |            |-----BAck--->|
               |<----------------------BAck------------------|
               |--HFConfirm.ind-->|            |             |
               |                  |---------HFConfirm------->|
               |                  |            |<--TSChange--|
               |                  |            |             |

                     Figure 4: "Prediction Success" Mode
                          (MN is the session sender)






















Yi, et al.               Expires August 12, 2007               [Page 14]

Internet-Draft                  Fast RSVP                  February 2007


                        MN                         PAR              NAR
          |----------------------------|            |                |
          | Mobile IP            RSVP  |            |                |
          |  Module             Module |            |                |
          |----------------------------|            |                |
               |                  |                 |                |
            predict               |                 |                |
            handover              |                 |                |
               |------HF.ind----->|                 |                |
               |                  |-----HF(B=1)---->|                |
               |                  |                 |---TPath(B=1)-->|
               |                  |                 |<-----TResv-----|
               |                  |                 |<-----TPath-----|
               |                  |                 |------TResv---->|
               |                  |                 |<---ResvConf----|
               |                  |<-----HFRsp------|                |
          disconnect              |                 |                |
               |                  |                 |                |
            connect               |                 |                |
               |                  |                 |                |
               |---------------------------BU----------------------->|
               |                  |                 |<------BU-------|
               |                  |                 |------BAck----->|
               |<-------------------------BAck-----------------------|
               |--HFConfirm.ind-->|                 |                |
               |                  |-HFConfirm(B=1)->|                |
               |                  |                 |-TSChange(B=1)->|
               |                  |                 |<---TSChange----|
               |                  |                 |                |

                      Figure 5: "Prediction Success" Mode
              (MN is both the receiver and the sender of the session)



















Yi, et al.               Expires August 12, 2007               [Page 15]

Internet-Draft                  Fast RSVP                  February 2007


                      MN                    PAR          Error   Correct
        |----------------------------|       |            NAR      NAR
        | Mobile IP            RSVP  |       |             |        |
        |  Module             Module |       |             |        |
        |----------------------------|       |             |        |
             |                  |            |             |        |
          predict               |            |             |        |
          handover              |            |             |        |
             |------HF.ind----->|            |             |        |
             |                  |-----HF---->|             |        |
             |                  |            |----TPath--->|        |
             |                  |            |<---TResv----|        |
             |                  |<---HFRsp---|             |        |
        disconnect              |            |             |        |
             |                  |            |             |        |
          connect               |            |             |        |
             |--------------------------BU------------------------->|
             |                  |            |<---------BU----------|
             |                  |            |---------BAck-------->|
             |<------------------------BAck-------------------------|
             |----HFError.ind-->|            |             |        |
             |                  |---------------------HFError------>|
             |                  |            |<-------HFError-------|
             |                  |            |--------TPath-------->|
             |                  |            |<-------TResv---------|
             |                  |---------------------HFTear------->|
             |                  |            |<-------HFTear--------|
             |                  |            |--TPathTear->|        |
             |                  |            |             |        |

                     Figure 6: "Failure Recovery" Mode
                        (MN is the session receiver)



















Yi, et al.               Expires August 12, 2007               [Page 16]

Internet-Draft                  Fast RSVP                  February 2007


                      MN                    PAR          Error   Correct
        |----------------------------|       |            NAR      NAR
        | Mobile IP            RSVP  |       |             |        |
        |  Module             Module |       |             |        |
        |----------------------------|       |             |        |
             |                  |            |             |        |
          predict               |            |             |        |
          handover              |            |             |        |
             |------HF.ind----->|            |             |        |
             |                  |------------HF----------->|        |
             |                  |            |<---TPath----|        |
             |                  |            |----TResv--->|        |
             |                  |<----------HFRsp----------|        |
        disconnect              |            |             |        |
             |                  |            |             |        |
          connect               |            |             |        |
             |--------------------------BU------------------------->|
             |                  |            |<---------BU----------|
             |                  |            |---------BAck-------->|
             |<------------------------BAck-------------------------|
             |----HFError.ind-->|            |             |        |
             |                  |---------------------HFError------>|
             |                  |            |<-------TPath---------|
             |                  |            |--------TResv-------->|
             |                  |---------------------HFTear------->|
             |                  |            |<-------HFTear--------|
             |                  |            |--TResvTear->|        |
             |                  |            |             |        |

                     Figure 7: "Failure Recovery" Mode
                         (MN is the session sender)




















Yi, et al.               Expires August 12, 2007               [Page 17]

Internet-Draft                  Fast RSVP                  February 2007


                   MN                  PAR              Error   Correct
        |-------------------------|     |                NAR      NAR
        | Mobile IP         RSVP  |     |                 |        |
        |  Module          Module |     |                 |        |
        |-------------------------|     |                 |        |
            |                |          |                 |        |
          predict            |          |                 |        |
          handover           |          |                 |        |
            |-----HF.ind---->|          |                 |        |
            |                |-HF(B=1)->|                 |        |
            |                |          |---TPath(B=1)--->|        |
            |                |          |<-----TResv------|        |
            |                |          |<-----TPath------|        |
            |                |          |------TResv----->|        |
            |                |          |<-----ResvConf---|        |
            |                |<--HFRsp--|                 |        |
       disconnect            |          |                 |        |
            |                |          |                 |        |
         connect             |          |                 |        |
            |-----------------------BU---------------------------->|
            |                |          |<------------BU-----------|
            |                |          |-------------BAck-------->|
            |<---------------------BAck----------------------------|
            |--HFError.ind-->|          |                 |        |
            |                |---------------HFError(B=1)--------->|
            |                |          |<-----HFError(B=1)--------|
            |                |          |---------TPath(B=1)------>|
            |                |          |<--------TResv------------|
            |                |          |<--------TPath------------|
            |                |          |---------TResv----------->|
            |                |          |<--------ResvConf---------|
            |                |----------------HFTear(B=1)--------->|
            |                |          |<------HFTear(B=1)--------|
            |                |          |-TPathTear(B=1)->|        |
            |                |          |<---TPathTear----|        |
            |                |          |                 |        |

                     Figure 8: "Failure Recovery" Mode
             (MN is both the receiver and the sender of the session)


   After MN becomes stable in the new subnet, the route optimization
   process would start.

   In the case that MN is the session receiver, CN is responsible for
   initiating the reservation process on the optimized route.  The
   extensions proposed in this document introduce a new cache named
   Pending Cache.  In addition to maintaining a Binding Cache, the



Yi, et al.               Expires August 12, 2007               [Page 18]

Internet-Draft                  Fast RSVP                  February 2007


   mobile IP module of CN also maintains a Pending Cache.  Every entry
   in the Pending Cache contains a (home address, care-of address) pair.
   When the mobile IP module of CN receives a BU message from MN, it
   simply updates the corresponding entry of MN in the Pending Cache
   (without updating the corresponding entry of MN in the Binding Cache)
   and sends a SessionHandover.req to its RSVP module.  Since the IP
   layer of CN only checks the Binding Cache to decide the destination
   addresses of the packets after it receives session data from the
   upper layer, thus when to redirect session data to the new optimized
   route is controlled entirely by the RSVP module.  On receiving the
   SessionHandover.req message, the RSVP module of CN checks whether the
   mobile node (indicated in the SessionHandover.req message) has
   multimedia sessions requiring resource reservation.  If MN has no
   such sessions, the RSVP module of CN immediately sends a
   SessionHandover.ind message to the mobile IP module.  If MN does have
   sessions with resource reservation requirements, the RSVP module of
   CN MUST start the resource reservation process on the optimized
   route.  Before the resource reservation process on the optimized
   route completes, Binding Cache remains unchanged, so sessions between
   CN and MN are still transmitted along the old route and the resource
   reservation neighbor tunnel.  Only after the RSVP module completes
   the resource reservation on the optimized route and sends a
   SessionHandover.ind message to the mobile IP module SHOULD the mobile
   IP module update the corresponding entry of MN in the Binding Cache.
   Then the session data is switched to the new optimized route and
   seamless handover between the two routes without QoS degradation can
   be achieved.

   The reservation process on the optimized route when MN is the
   receiver of the session is illustrated in Figure 9.





















Yi, et al.               Expires August 12, 2007               [Page 19]

Internet-Draft                  Fast RSVP                  February 2007


                    MN                router              CN
          |--------------------|        |       |--------------------|
          | Mobile IP    RSVP  |        |       |  RSVP    Mobile IP |
          |  Module     Module |        |       | Module     Module  |
          |--------------------|        |       |--------------------|
               |          |             |            |          |
           MN is stable   |             |            |          |
           in new subnet  |             |            |          |
               |-----------------------BU---------------------->|
               |<---------------------BAck----------------------|
               |          |             |            |<-SH.req--|
               |          |<---Path-----|<---Path----|          |
               |          |----Resv---->|----Resv--->|          |
               |          |             |            |--SH.ind->|
               |          |             |            |     redirect
               |          |             |            |     session data
               |          |             |            |          |

                   Figure 9: Reservation on the Optimized Route
                            (MN is session receiver)


   In the case when MN is the session sender, MN itself is responsible
   for initiating the reservation process on the optimized route.  When
   the mobile IP module of MN receives a BA message from CN, it sends a
   SessionHandover.req to its RSVP module.  When to redirect session
   data to the new optimized route is then controlled entirely by the
   RSVP module.  On receiving the SessionHandover.req message, the RSVP
   module of MN checks whether it has multimedia sessions requiring
   resource reservation.  If MN has no such sessions, its RSVP module
   immediately sends a SessionHandover.ind message to the mobile IP
   module.  If MN does have sessions with resource reservation
   requirements, its RSVP module MUST start the resource reservation
   process on the optimized route.  Before the resource reservation
   process completes, sessions between MN and CN are still transmitted
   along the old route and the resource reservation neighbor tunnel.
   Only after the RSVP module completes resource reservation on the
   optimized route and sends a SessionHandover.ind message to the mobile
   IP module SHOULD the mobile IP module redirect the session data to
   the new optimized route.  Thus seamless handover between the two
   routes without QoS degradation can be achieved.

   The reservation process on the optimized route when MN is the sender
   of the session is illustrated in Figure 10.







Yi, et al.               Expires August 12, 2007               [Page 20]

Internet-Draft                  Fast RSVP                  February 2007


                    MN                router              CN
          |--------------------|        |       |--------------------|
          | Mobile IP    RSVP  |        |       |  RSVP    Mobile IP |
          |  Module     Module |        |       | Module     Module  |
          |--------------------|        |       |--------------------|
               |          |             |            |          |
           MN is stable   |             |            |          |
           in new subnet  |             |            |          |
               |-----------------------BU---------------------->|
               |<---------------------BAck----------------------|
               |--SH.req->|             |            |          |
               |          |----Path---->|----Path--->|          |
               |          |<---Resv-----|<---Resv----|          |
               |<-SH.ind--|             |            |          |
           redirect       |             |            |          |
           session data   |             |            |          |
               |          |             |            |          |

                   Figure 10: Reservation on the Optimized Route
                            (MN is session sender)


   By exchanging Path and Resv messages between MN and CN, the resource
   reservation process on the optimized route can be achieved.  When the
   mobile IP module of the intermediate router on the optimized route
   receives a Path message, it sends the message to the RSVP module for
   processing.  After the RSVP module receives the Path message, it
   checks whether it already has the corresponding Path State of the
   session according to the "IPv6 HomeAddress" "DstPort" and "Protocol
   Id" in the MSESSION object.  If the corresponding Path State is
   found, the RSVP module on the router only needs to update this state;
   otherwise, it sets up the corresponding Path State for the session.
   When the RSVP module completes processing the Path message, it would
   send the message back to the mobile IP module.  In addition, the RSVP
   module on the router should notify the mobile IP module of MN's home
   address by sending a AddrNotify.ind, so that the mobile IP module
   could fill this address in "Type 2 Routing Header" (if MN is the
   session receiver) or "Home address option" (if MN is the session
   sender) when re-encapsulating the Path message.  The scenario about
   the process of the Path message on the intermediate router is
   illustrated in the Figure 11.










Yi, et al.               Expires August 12, 2007               [Page 21]

Internet-Draft                  Fast RSVP                  February 2007


      |
      |
      |Path         MN                          CN
      |   |--------------------| PATH  |--------------------|
      V-->|                    |------>|                    |
          |     Mobile IP      | PATH  |       RSVP         |
          |       Module       |<------|      Module        |
          |                    | AN.ind|                    |
      |<--|                    |<------|                    |
      |   |--------------------|       |--------------------|
      |Path
      V
             Figure 11: Process of the Path Message on the
                      Intermediate Router





































Yi, et al.               Expires August 12, 2007               [Page 22]

Internet-Draft                  Fast RSVP                  February 2007


4.  Details of RSVP Extensions

4.1.  MN is the Receiver of the Session

   When the mobile IP module of MN predicts that a handover event from
   PAR to NAR is imminent, it sends an indication message
   HandoverForecast.ind to the RSVP module.  The HandoverForecast.ind
   MUST contain the NCoA that will be used by MN in NAR's subnet.  Then
   the RSVP module:

   1.  extracts the NCoA and the home address from the
       HandoverForecast.ind and then uses this information to form the
       Router_Notify object (see section 6.2.2).  The Router_Notify
       object MUST contain the NCoA and Code 0 (see section 6.3.1.).

   2.  extracts the MSESSION object from the corresponding Path or Resv
       State on MN and fills the "IPv6 DestAddress" field with NCoA to
       form a new MSESSION object.  Note that this new MSESSION object
       corresponds to the tunnel reservation and MUST NOT affect the
       MSESSION object in the Path or Resv State on MN.

   3.  uses the Router_Notify object formed in step 1 and the new
       MSESSION formed in step 2 to construct a HandoverForecast message
       with 'B' flag unset (see section 5.3) and sends it to the current
       access router PAR.

   When PAR receives the HandoverForecast message, it SHALL check the
   'B' flag in Common Header to make sure it is unset, then the RSVP
   module of it:

   1.  extracts the MN's NCoA and the Code in the Router_Notify object
       and confirms that the Code is 0 (it means that the router acts as
       PAR for MN).

   2.  looks up the matching Path State of the session according to the
       "IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION
       object that can be found in the HandoverForecast message and
       extracts the SENDER_TSPEC (defines the traffic characteristics of
       a sender's data flow) [3] contained in the matching Path State.

   3.  uses the SENDER_TSPEC and the MSESSION (copied from the
       HandoverForecast message) to construct the TunnelPath message
       with the 'B' flag unset.  The TunnelPath message shares the same
       format with the Path message, except that it has a different "Msg
       Type" field value (see section 6.3.6.) in Common Header to
       indicate that it corresponds to the tunnel resource reservation
       and not to the usual resource reservation between the session
       endpoints.



Yi, et al.               Expires August 12, 2007               [Page 23]

Internet-Draft                  Fast RSVP                  February 2007


   4.  sets up the Path State according to the TunnelPath message and
       sends it to MN's NCoA to establish the resource reservation
       tunnel.

   When intermediate routers receive the TunnelPath message, they set up
   the Path State for the session according to the content of the
   message and forward the message to the next hop.  Finally, when the
   router of the handover target subnet (NAR) receives the TunnelPath
   message, it SHALL check the 'B' flag in Common Header to make sure it
   is unset, then its RSVP module:

   1.  sets up the Path State according to the content of the TunnelPath
       message.

   2.  acts as a RSVP proxy for MN, constructing a TunnelResv message
       with 'B' flag unset and then sending it out on the reverse
       direction to PAR.  The TunnelResv message shares the same format
       with the Resv message, except that it has a different "Msg Type"
       (see section 6.3.7) field value in Common Header to indicate that
       it corresponds to the tunnel resource reservation and not to the
       usual resource reservation between the session endpoints.

   3.  sets up the Resv State according to the content of the TunnelResv
       message.

   When intermediate routers receive the TunnelResv message, they make
   an advanced resource reservation for the session locally, set up the
   corresponding Resv State and forward the TunnelResv message to the
   previous hop.

   Finally, when PAR receives the TunnelResv message, it sets up the
   Resv State, and a resource reservation tunnel between PAR and NAR is
   successfully built.

   As a response to HandoverForecast message, PAR SHALL send a
   HandoverForecastResponse message to MN indicating one of the
   following possible conditions:

   1.  If the resource reservation tunnel establishment is successful,
       PAR MUST construct a HandoverForecastResponse message with Code 0
       in the Tunnel_Info object (see section 6.2.3) and send it to MN
       indicating the successful establishment of the resource
       reservation tunnel.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State.

   2.  If the resource reservation tunnel establishment fails, PAR
       SHOULD use a certain algorithm (e.g., the binary exponential
       backoff algorithm) to retry the reservation procedure.  Choosing



Yi, et al.               Expires August 12, 2007               [Page 24]

Internet-Draft                  Fast RSVP                  February 2007


       the appropriate algorithm is outside the scope of this document.
       If the resource reservation on the tunnel fails even after
       TPATH_RETRIES, PAR MUST assume that not enough resources are
       available on the neighbor tunnel and then PAR SHALL construct a
       HandoverForecastResponse message with Code 1 in the Tunnel_Info
       object and send it to MN indicating the failure in building the
       tunnel.  The MSESSION object in this message is copied from the
       corresponding Path or Resv State.

   If MN receives a HandoverForecastResponse message with Code 1 or even
   if it doesn't receive the HandoverForecastResponse message until the
   handover occurs, it MUST skip the step of resource reservation on the
   tunnel and process the optimized route resource reservation step
   described below.

   After MN hands over to a new subnet, its mobile IP module sends a BU
   message to PAR, so PAR can redirect the session data to MN's new
   position.  In addition, the mobile IP module of MN MUST check whether
   the current subnet is the same as the predicted handover target
   subnet.  Then depending on the result of this check, MN MUST take one
   of the following actions:

   1.  If the handover prediction is successful, the mobile IP module of
       MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
       When the RSVP module of MN receives this indication, it MUST
       construct a HandoverForecastConfirm message with the 'B' flag
       unset and send it to PAR.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State but with the
       "IPv6 DestAddress" field changed to MN's NCoA.

   2.  If the handover prediction fails, the mobile IP module of MN MUST
       send a HandoverForecastError.ind to the RSVP module.  This
       indication message MUST contain the current in use CoA and the
       formerly falsely predicted CoA of MN.  When the RSVP module of MN
       receives this indication message, it MUST construct a
       HandoverForecastError message with the Router_Notify object
       including the current in use CoA as well as Code 0 and then send
       the message to PAR directly.  The 'B' flag in this message MUST
       be unset.  The MSESSION object in this message is copied from the
       corresponding Path or Resv State but with the "IPv6 DestAddress"
       field changed to MN's NCoA.  MN MUST also construct a
       HandoverForecastTear message containing the formerly falsely
       predicted CoA and send the message to PAR directly.  The 'B' flag
       in this message MUST be unset.  The MSESSION object in this
       message is copied from the corresponding Path or Resv State but
       with the "IPv6 DestAddress" field changed to MN's NCoA.

   If the handover event doesn't occur within a certain time, the mobile



Yi, et al.               Expires August 12, 2007               [Page 25]

Internet-Draft                  Fast RSVP                  February 2007


   IP module of MN MUST also construct a HandoverForecastTear message
   containing the formerly falsely predicted CoA and send the message to
   PAR directly.  The 'B' flag in this message MUST be unset.  The
   MSESSION object in this message is copied from the corresponding Path
   or Resv State but with the "IPv6 DestAddress" field changed to MN's
   NCoA.

   When receiving the HandoverForecastConfirm message, PAR SHALL check
   the 'B' flag in Common Header to make sure it is unset, then it MUST
   send a TunnelStateChange message with 'B' flag unset and send the
   message to NAR.  The MSESSION object in this message is copied from
   the HandoverForecastConfirm message so the intermediate routers can
   change the reservation type (see section 5.4).

   When receiving the HandoverForecastError message, PAR SHALL check to
   make sure that the 'B' flag in Common Header is unset and the Code in
   Router_Notify object is filled with 0.  Then it MUST extract MN's
   current in use CoA and send a new TunnelPath message with 'B' flag
   unset to MN's current subnet (e.g.  Correct NAR in Figure 6).  The
   MSESSION object in this message is copied from the
   HandoverForecastError message.  When receiving this TunnelPath
   message, NAR MUST reply with a TunnelResv message with the 'B' flag
   unset so that resource reservation on the correct tunnel can be
   established.

   When receiving the HandoverForecastTear message, PAR SHALL check the
   'B' flag in Common Header to make sure it is unset, then it MUST
   extract the MN's formerly falsely predicted CoA and send a
   TunnelPathTear message with the 'B' flag unset to MN's falsely
   predicted subnet (e.g.  Error NAR in Figure 6).  The MSESSION object
   in this message is copied from the HandoverForecastTear message.
   When receiving this message, intermediate routers MUST remove the
   corresponding Path State and Resv State so that the resources
   reserved in advance on the falsely built tunnel can be released.

   When MN gets stable in the handover target subnet, it sends a BU
   message to CN.  After the mobile IP module of CN receives this BU
   message, in addition to replying with a BA message to MN, the mobile
   IP module of CN also takes the following actions:

   1.  extracts MN's home address and NCoA (included in the BU message)
       and updates the corresponding entry of MN in the Pending Cache
       (see section 3.1.) to record the (home address, NCoA) pair.

   2.  sends a SessionHandover.req to the RSVP module inquiring whether
       or not to redirect the session data to the new optimized route.
       The SessionHandover.req MUST contain the (home address, NCoA)
       pair of MN.



Yi, et al.               Expires August 12, 2007               [Page 26]

Internet-Draft                  Fast RSVP                  February 2007


   On receiving the SessionHandover.req, the RSVP module of CN MUST try
   to lookup the matching Path or Resv State according to the home
   address of MN.  Then:

   1.  If matching Path or Resv State is not found, it means that MN
       doesn't have any multimedia sessions requiring resource
       reservation.  Then the RSVP module MUST immediately send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       the MN.

   2.  If matching Path or Resv State is found, it means that MN does
       have multimedia sessions requiring resource reservation.  Then
       the RSVP module of CN MUST initiate the resource reservation
       process on the optimized route.  The RSVP module of CN generates
       the Path message with the 'B' flag unset and sends it to MN.  In
       addition, the RSVP module updates the corresponding Path state
       (especially updating the IPv6 DestAddr field of the MSESSION with
       MN's NCoA).  The MSESSION object in the Path message MUST contain
       the NCoA as well as the home address of MN.  The SENDER_TSPEC in
       the Path message MUST be extracted from the corresponding Path
       State of MN.  After an intermediate RSVP router on the
       transmission path receives the Path message, it MUST check
       whether it already has the corresponding Path State of the
       session according to the "IPv6 HomeAddress" "DstPort" and
       "Protocol Id" in the MSESSION object.  If the corresponding Path
       State is found, the RSVP module on the router only needs to
       update this state (especially updating the IPv6 DestAddr field of
       the MSESSION with MN's NCoA); otherwise, it MUST set up the
       corresponding Path State for the session.  In addition, the RSVP
       module on the router MUST send an AddrNotify.ind to the mobile IP
       module to indicate MN's home address and NCoA, so that the mobile
       IP module could fill these addresses in "Type 2 Routing Header"
       and the IP header when re-encapsulating the Path message.  After
       the Path message corresponding to the optimized route finally
       reaches MN, MN SHALL check the 'B' flag in Common Header to make
       sure it is unset, then the RSVP module of MN replies with the
       proper Resv message with the 'B' flag unset and updates the
       corresponding Path and Resv state (especially updating the IPv6
       DestAddr field of the MSESSION with MN's NCoA).  After an
       intermediate RSVP router on the transmission path receives the
       Resv message, it checks whether it already has the corresponding
       Resv State of the session according to the "IPv6 HomeAddress"
       "DstPort" and "Protocol Id" in the MSESSION object.  If the
       corresponding Resv State is found, the RSVP module on the router
       only needs to update this state (especially updating the IPv6
       DestAddr field of the MSESSION with MN's NCoA); otherwise, it
       tries to reserve resources for the session locally and set up the



Yi, et al.               Expires August 12, 2007               [Page 27]

Internet-Draft                  Fast RSVP                  February 2007


       corresponding Resv State.  Finally, when the RSVP module of CN
       receives the Resv message and updates the corresponding Resv
       state (especially updating the IPv6 DestAddr field of the
       MSESSION with MN's NCoA), the resource reservation process on the
       optimized route successfully completes.  Then the RSVP module
       MUST send a SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       MN.  If the reservation on the optimizated route fails, CN SHOULD
       use a certain algorithm (e.g., the binary exponential backoff
       algorithm) to retry the reservation process.  The choice of the
       appropriate algorithm is outside the scope of this document.  If
       the resource reservation on the optimized route fails even after
       the ROPATH_RETRIES, CN MUST assume that resources are not
       available on the optimized route.  Then session data from CN to
       MN SHALL be kept transmitting along the old resource reservation
       path and the resource reservation neighbor tunnel.

   On receiving the SessionHandover.ind, the mobile IP module of CN MUST
   update the proper entry in the Bindng Cache according to the (home
   address, NCoA) pair of MN which can be extracted from the
   SessionHandover.ind, thus session data is redirected to the optimized
   route from then on.

4.2.  MN is the Sender of the Session

   When the mobile IP module of MN predicts that a handover event from
   PAR to NAR is imminent, it sends an indication message
   HandoverForecast.ind to the RSVP module.  The HandoverForecast.ind
   MUST contain the PAR's IP address.  Then the RSVP module:

   1.  extracts the NCoA and the home address from the
       HandoverForecast.ind and then uses this information to form the
       Router_Notify object (see secton 6.2.2).  The Router_Notify
       object MUST contain the PAR's IP address and Code 1 (see section
       6.3.1.),

   2.  extracts the MSESSION object from the corresponding Path or Resv
       State on MN and fills the "IPv6 DestAddress" field with PAR's IP
       address to form a new MSESSION object.  Note that this new
       MSESSION object corresponds to the tunnel reservation and MUST
       NOT affect the MSESSION object in the Path or Resv State on MN.

   3.  uses the Router_Notify object formed in step 1 and the new
       MSESSION formed in step 2 to construct a HandoverForecast message
       with 'B' flag unset (see section 5.3) and sends it to the
       predicted access router NAR.  The SENDER_TSPEC object in this
       message is copied from the corresponding Path state.




Yi, et al.               Expires August 12, 2007               [Page 28]

Internet-Draft                  Fast RSVP                  February 2007


   When NAR receives the HandoverForecast message, it SHALL check the
   'B' flag in Common Header to make sure it is unset, then the RSVP
   module of it:

   1.  extracts the PAR's IP address and the Code in the Router_Notify
       object that can be found in the HandoverForecast message and
       confirms that the Code is 1 (it means that the router acts as NAR
       for MN),

   2.  extracts the SENDER_TSPEC object and the MSESSION object both of
       which are included in the HandoverForecast message.

   3.  acts as an RSVP proxy of MN and uses the SENDER_TSPEC object as
       well as the MSESSION object to construct the TunnelPath message
       with the 'B' flag unset.  The TunnelPath message shares the same
       format with the Path message, except that it has a different "Msg
       Type" field value in Common Header to indicate that it
       corresponds to the tunnel resource reservation and not to the
       usual resource reservation between the session endpoints.

   4.  sets up the Path State of the session accordingly and sends the
       TunnelPath message to PAR.

   When intermediate routers receive the TunnelPath message, they set up
   the Path State for the session according to the content of the
   message and forward the message to the next hop.  Finally, when PAR
   receives the TunnelPath message, it SHALL check the 'B' flag in
   Common Header to make sure it is unset, then its RSVP module:

   1.  sets up the Path State according to the content of the TunnelPath
       message.

   2.  constructs a TunnelResv message with the 'B' flag unset and then
       sends it out on the reverse direction to NAR.  The TunnelResv
       message shares the same format with the Resv message, except that
       it has a different "Msg Type" (see section 6.3.7) field value in
       Common Header to indicate that it corresponds to the tunnel
       resource reservation and not to the usual resource reservation
       between the session endpoints.

   3.  sets up the Resv State according to the content of the TunnelResv
       message.

   When intermediate routers receive the TunnelResv message, they make
   an advanced resource reservation for the session locally, set up the
   corresponding Resv State and forward the TunnelResv message to the
   previous hop.




Yi, et al.               Expires August 12, 2007               [Page 29]

Internet-Draft                  Fast RSVP                  February 2007


   Finally, when NAR receives the TunnelResv message, it sets up the
   Resv State, and a resource reservation tunnel between NAR and PAR is
   successfully built.

   As a response to HandoverForecast message, NAR SHALL send a
   HandoverForecastResponse message to MN indicating one of the
   following possible conditions:

   1.  If the resource reservation tunnel establishment is successful,
       NAR MUST construct a HandoverForecastResponse message with Code 0
       in the Tunnel_Info object (see section 6.2.3) and send it to MN
       indicating the successful establishment of the resource
       reservation tunnel.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State.

   2.  If the resource reservation tunnel establishment fails, NAR
       SHOULD use a certain algorithm (e.g., the binary exponential
       backoff algorithm) to retry the reservation procedure.  The
       choice of the appropriate algorithm is outside the scope of this
       document.  If the resource reservation on the tunnel fails even
       after TPATH_RETRIES, NAR MUST assume that not enough resources
       are available on the neighbor tunnel and then NAR SHOULD
       construct a HandoverForecastResponse message with Code 1 in the
       Tunnel_Info object and send it to MN indicating the failure in
       building the tunnel.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State.

   If MN receives a HandoverForecastResponse message with Code 1 or even
   if it doesn't receive the HandoverForecastResponse message until the
   handover occurs, it MUST skip the step of resource reservation on the
   tunnel and process the optimized route resource reservation step
   described below.

   After MN hands over to a new subnet, its mobile IP module sends a BU
   message to PAR, so PAR can redirect the session data to MN's new
   position.  In addition, the mobile IP module of MN MUST check whether
   the current subnet is the same as the predicted handover target
   subnet.  Then depending on the result of this check, MN MUST take one
   of the following actions:

   1.  If the handover prediction is successful, the mobile IP module of
       MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
       When the RSVP module of MN receives this indication, it MUST
       construct a HandoverForecastConfirm message with the 'B' flag
       unset and send it to NAR.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State but with the
       "IPv6 DestAddress" field changed to PAR's IP address.




Yi, et al.               Expires August 12, 2007               [Page 30]

Internet-Draft                  Fast RSVP                  February 2007


   2.  If the handover prediction fails, the mobile IP module of MN MUST
       send a HandoverForecastError.ind to the RSVP module.  This
       indication message MUST contain the current in use CoA and the
       formerly falsely predicted CoA of MN.  When the RSVP module of MN
       receives this indication message, it MUST construct a
       HandoverForecastError message with the Router_Notify object
       including the IP address of MN's previous access router (PAR) as
       well as Code 1 and then send the message to NAR directly.  The
       'B' flag in this message MUST be unset.  The MSESSION object in
       this message is copied from the corresponding Path or Resv State
       but with the "IPv6 DestAddress" field changed to PAR's IP
       address.  The SENDER_TSPEC object in this message is copied form
       the corresponding Path state.  MN MUST also construct a
       HandoverForecastTear message containing the formerly falsely
       predicted CoA and send the message to PAR directly.  The 'B' flag
       in this message MUST be unset.  The MSESSION object in this
       message is copied from the corresponding Path or Resv State but
       with the "IPv6 DestAddress" field changed to PAR's IP address.

   If the handover event doesn't occur within a certain time, the mobile
   IP module of MN MUST also construct a HandoverForecastTear message
   containing the formerly falsely predicted CoA and send the message to
   PAR directly.  The 'B' flag in this message MUST be unset.  The
   MSESSION object in this message is copied from the corresponding Path
   or Resv State but with the "IPv6 DestAddress" field changed to PAR's
   IP address.

   When receiving the HandoverForecastConfirm message, NAR SHALL check
   the 'B' flag in Common Header to make sure it is unset, then it MUST
   send a TunnelStateChange message with the 'B' flag unset to PAR, the
   MSESSION object in this message is copied from the
   HandoverForecastConfirm message so that the intermediate routers can
   change the reservation type (see section 5.4).

   When receiving the HandoverForecastError message, NAR SHALL check to
   make sure that the 'B' flag in Common Header is unset and the Code in
   Router_Notify object is filled with 1, then it MUST extract PAR's IP
   address and send a new TunnelPath message with the 'B' flag unset to
   PAR.  The MSESSION object and the SENDER_TSPEC object in this message
   are copied from the HandoverForecastError message.  When receiving
   this TunnelPath message, PAR MUST reply with a TunnelResv message
   with the 'B' flag unset so that the resource reservation on the
   correct tunnel can be established.

   When receiving the HandoverForecastTear message, PAR SHALL check the
   'B' flag in Common Header to make sure it is unset, then it MUST
   extract the MN's formerly falsely predicted CoA and send a
   TunnelResvTear message with the 'B' flag unset to MN's falsely



Yi, et al.               Expires August 12, 2007               [Page 31]

Internet-Draft                  Fast RSVP                  February 2007


   predicted subnet (e.g.  Error NAR in Figure 7).  The MSESSION object
   in this message is copied from the HandoverForecastTear message.
   When receiving this message, intermediate routers MUST remove the
   corresponding Resv State so that the resources reserved in advance on
   the falsely built tunnel can be released.

   When MN gets stable in the handover target subnet, it sends a BU
   message to CN and receives a BA message from CN.  After that, the
   mobile IP module of MN sends a SessionHandover.req to the RSVP module
   inquiring whether or not to redirect the session data to the new
   optimized route.  The SessionHandover.req MUST contain the (home
   address, NCoA) pair of the MN.

   On receiving the SessionHandover.req, the RSVP module of MN MUST try
   to lookup the matching Path or Resv State according to the home
   address of MN.  Then:

   1.  If matching Path or Resv State is not found, it means that MN
       doesn't have any multimedia sessions requiring resource
       reservation.  Then the RSVP module MUST immediately send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       the MN.

   2.  If matching Path or Resv State is found, it means that MN does
       have multimedia sessions requiring resource reservation.  Then
       the RSVP module of MN MUST initiate the resource reservation
       process on the optimized route.  The RSVP module of MN generates
       the Path message with the 'B' flag unset and sends it to CN.  The
       SENDER_TSPEC in the Path message MUST be extracted from the
       corresponding Path State of the MN.  After an intermediate RSVP
       router on the transmission path receives the Path message, it
       MUST check whether it already has a corresponding Path State of
       the session according to the "IPv6 HomeAddress" "DstPort" and
       "Protocol Id" in the MSESSION object.  If the corresponding Path
       State is found, the RSVP module on the router only needs to
       update this state; otherwise, it MUST set up the corresponding
       Path State for the session.  In addition, the RSVP module on the
       router MUST send an AddrNotify.ind to the mobile IP module to
       indicate MN's home address and NCoA so that the mobile IP module
       could fill these addresses in "Home Address Option" [2] and the
       IP header when re-encapsulating the Path message.  When the Path
       message corresponding to the optimized route finally reaches CN,
       CN SHALL check the 'B' flag in Common Header to make sure it is
       unset, then the RSVP module of CN replies with the proper Resv
       message with the 'B' flag unset.  After an intermediate RSVP
       router on the transmission path receives the Resv message, it
       checks whether it already has the corresponding Resv State of the



Yi, et al.               Expires August 12, 2007               [Page 32]

Internet-Draft                  Fast RSVP                  February 2007


       session according to the "IPv6 HomeAddress" "DstPort" and
       "Protocol Id" in the MSESSION object.  If the corresponding Resv
       State is found, the RSVP module on the router only needs to
       update this state; otherwise, it tries to reserve resources for
       the session locally and set up the corresponding Resv State.
       Finally, when the RSVP module of MN receives the Resv message,
       the resource reservation process on the optimized route
       successfully completes.  Then the RSVP module MUST send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       MN.  If the reservation on the optimizated route fails, MN SHOULD
       use a certain algorithm (e.g., the binary exponential backoff
       algorithm) to retry the reservation process.  The choice of the
       appropriate algorithm is outside the scope of this document.  If
       the resource reservation on the optimized route fails even after
       the ROPATH_RETRIES, MN MUST assume that resources are not
       available on the optimized route.  Then session data from MN to
       CN SHALL be kept transmitting along the old resource reservation
       path and the resource reservation neighbor tunnel.

   On receiving the SessionHandover.ind, the mobile IP module of MN MUST
   redirect the session data to the optimized route and utilize Home
   Address Option to send packets from then on.

4.3.  MN is both the Sender and the Receiver of the Session

   When the mobile IP module of MN predicts that a handover event from
   PAR to NAR is imminent, it sends an indication message
   HandoverForecast.ind to the RSVP module.  The HandoverForecast.ind
   MUST contain the NCoA that will be used by MN in NAR's subnet.  Then
   the RSVP module:

   1.  extracts the NCoA and the home address from the
       HandoverForecast.ind and then uses this information to form the
       Router_Notify object (see section 6.2.2).  The Router_Notify
       object MUST contain the NCoA and Code 0 (see section 6.3.1),

   2.  extracts the MSESSION object from the corresponding Path or Resv
       State on MN and fills the "IPv6 DestAddress" field with NCoA to
       form a new MSESSION object.  Note that this new MSESSION object
       corresponds to the tunnel reservation and MUST NOT affect the
       MSESSION object in the Path or Resv State on MN.

   3.  uses the Router_Notify object formed in step 1 and the new
       MSESSION formed in step 2 to construct a HandoverForecast message
       and sends it to the current access router PAR.  The 'B' flag in
       the Common Header of the HandoverForecast message MUST be set
       (see section 5.3) to inform PAR that the reservation is



Yi, et al.               Expires August 12, 2007               [Page 33]

Internet-Draft                  Fast RSVP                  February 2007


       bidirectional.

   When PAR receives the HandoverForecast message, it SHALL check the
   'B' flag in Common Header to make sure it is set, then its RSVP
   module:

   1.  extracts the MN's NCoA and the Code in the Router_Notify object
       and confirms that the Code is 0 (it means that the router acts as
       PAR for MN),

   2.  looks up the matching Path State of the session according to the
       "IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION
       object that can be found in the HandoverForecast message and
       extracts the SENDER_TSPEC (defines the traffic characteristics of
       a sender's data flow) [3] contained in the matching Path State,

   3.  uses the SENDER_TSPEC and the MSESSION (copied from the
       HandoverForecast message) to construct the TunnelPath message
       with the 'B' flag set.  The TunnelPath message shares the same
       format with the Path message, except that it has a different "Msg
       Type" field value (see section 6.3.6) in Common Header to
       indicate that it corresponds to the tunnel resource reservation
       and not to the usual resource reservation between the session
       endpoints.

   4.  sets up the Path State according to the TunnelPath message and
       sends it to MN's NCoA to establish the resource reservation
       tunnel.

   When intermediate routers receive the TunnelPath message, they set up
   the Path State for the session according to the content of the
   message and forward the message to the next hop.  Finally, when the
   router of the handover target subnet (NAR) receives the TunnelPath
   message, it SHALL check the 'B' flag in Common Header to make sure it
   is set (If MN is both the sender and receiver of the session, this
   flag bit is always set), then its RSVP module:

   1.  sets up the Path State according to content of the TunnelPath
       message.

   2.  acts as an RSVP proxy for MN, constructing a TunnelResv message
       with the 'B' flag unset and then sending it out on the reverse
       direction to PAR.  The TunnelResv message shares the same format
       with the Resv message, except that it has a different "Msg Type"
       (see section 6.3.7) field value in Common Header to indicate that
       it corresponds to the tunnel resource reservation and not to the
       usual resource reservation between the session endpoints.




Yi, et al.               Expires August 12, 2007               [Page 34]

Internet-Draft                  Fast RSVP                  February 2007


   3.  sets up the Resv State according to the content of the TunnelResv
       message.

   4.  extracts the MSESSION object from the TunnelPath message received
       from PAR and changes the "IPv6 DestAddress" field with PAR's IP
       address to form a new MSESSION object.  This new MSESSION object
       corresponds to the resource reservation on the reverse direction
       from NAR to PAR.

   5.  constructs a new TunnelPath message.  This message MUST include
       the new MSESSION object formed in step 4 as well as the
       SENDER_TSPEC object copied from the TunnelPath message received
       from PAR.  Note that the 'B' flag in this message MUST be unset.

   6.  sends the TunnelPath message formed in step 5 to PAR so that the
       reservation on the reverse direction can be established.

   When intermediate routers receive the TunnelResv message, they make
   an advanced resource reservation for the session locally, set up the
   corresponding Resv State and forward the TunnelResv message to the
   previous hop.

   When intermediate routers receive the TunnelPath message
   corresponding to the resource reservation on the reverse direction,
   they set up the Path State for the session according to the content
   of the message and forward the message to the next hop.

   When PAR receives the TunnelPath message from NAR, it MUST reply a
   TunnelResv message (including the RESV_CONFIRM object) to NAR.  So
   when the reservation on the reverse direction completes, NAR will
   reply with a ResvConf message.

   Finally, when PAR receives both the TunnelResv message and the
   ResvConf message from NAR, the birectional reservation is
   successfully established.

   As a response to HandoverForecast message, PAR SHALL send a
   HandoverForecastResponse message to MN indicating one of the
   following possible conditions:

   1.  If the resource reservation tunnel establishment is successful,
       PAR MUST construct a HandoverForecastResponse message with Code 0
       in the Tunnel_Info object (see section 6.2.3) and send it to MN
       indicating the successful establishment of the resource
       reservation tunnel.  The MSESSION object in this message is
       copied from the corresponding Path or Resv State.





Yi, et al.               Expires August 12, 2007               [Page 35]

Internet-Draft                  Fast RSVP                  February 2007


   2.  If the resource reservation tunnel establishment from PAR to NAR
       fails, PAR SHOULD use a certain algorithm (e.g., the binary
       exponential backoff algorithm) to retry the reservation
       procedure.  If the resource reservation tunnel establishment from
       NAR to PAR fails, NAR SHOULD use a certain algorithm (e.g., the
       binary exponential backoff algorithm) to retry the reservation
       procedure.  The choice of the appropriate algorithm is outside
       the scope of this document.  If the resource reservation on the
       tunnel from NAR to PAR fails even after TPATH_RETRIES, NAR MUST
       assume that not enough resources are available on the neighbor
       tunnel and give up.  If the resource reservation on the tunnel
       from PAR to NAR fails even after TPATH_RETRIES or PAR doesn't
       receive ResvConf message from NAR within CONF_TIMEOUT, PAR MUST
       assume that the bidirectional resource reservation tunnel cannot
       be built, and then PAR SHALL construct a HandoverForecastResponse
       message with Code 1 in the Tunnel_Info object and send it to MN
       indicating the failure in building the tunnel.  The MSESSION
       object in this message is the same as that in the original
       HandoverForecast message from MN.

   If MN receives a HandoverForecastResponse message with Code 1 or even
   if it doesn't receive the HandoverForecastResponse message until the
   handover occurs, it MUST skip the step of resource reservation on the
   tunnel and process the optimized route resource reservation step
   described below.

   After MN hands over to a new subnet, its mobile IP module sends a BU
   message to PAR, so PAR can redirect the session data to MN's new
   position.  In addition, the mobile IP module of MN MUST check whether
   the current subnet is the same as the predicted handover target
   subnet.  Then depending on the result of this check, MN MUST take one
   of the following actions:

   1.  If the handover prediction is successful, the mobile IP module of
       MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
       When the RSVP module of MN receives this indication, it MUST
       construct a HandoverForecastConfirm message and send it to PAR.
       The MSESSION object in this message is copied from the
       corresponding Path or Resv State but with the "IPv6 DestAddress"
       field changed to MN's NCoA.  The 'B' flag in the Common Header of
       this HandoverForecastConfirm message MUST be set (see section
       5.3) to inform PAR that the reservation is bidirectional.

   2.  If the handover prediction fails, the mobile IP module of MN MUST
       send a HandoverForecastError.ind to the RSVP module.  This
       indication message MUST contain the current in use CoA and the
       formerly falsely predicted CoA of MN.  When the RSVP module of MN
       receives this indication message, it MUST construct a



Yi, et al.               Expires August 12, 2007               [Page 36]

Internet-Draft                  Fast RSVP                  February 2007


       HandoverForecastError message with the Router_Notify object
       including the current in use CoA as well as Code 0 and then send
       the message to PAR directly.  The MSESSION object in this message
       is copied from the corresponding Path or Resv State but with the
       "IPv6 DestAddress" field changed to MN's NCoA.  MN MUST also
       construct a HandoverForecastTear message containing the formerly
       falsely predicted CoA and send the message to PAR directly.  The
       MSESSION object in this message is copied from the corresponding
       Path or Resv State but with the "IPv6 DestAddress" field changed
       to MN's NCoA.  The 'B' flag in the Common Header of both the
       HandoverForecastError and HandoverForecastTear message MUST be
       set (see section 5.3) to inform PAR the reservation is
       bidirectional.

   If the handover event doesn't occur within a certain time, the mobile
   IP module of MN MUST also construct a HandoverForecastTear message
   containing the formerly falsely predicted CoA and send the message to
   PAR directly.  The MSESSION object in this message is copied from the
   corresponding Path or Resv State but with the "IPv6 DestAddress"
   field changed to MN's NCoA.  The 'B' flag in the Common Header of
   this HandoverForecastTear message MUST be set (see section 5.3) to
   inform PAR that the reservation is bidirectional.

   When receiving the HandoverForecastConfirm message, PAR SHALL check
   the 'B' flag in Common Header to make sure it is set, then it MUST
   construct a TunnelStateChange message and send it to NAR.  The
   MSESSION object in this message is copied from the
   HandoverForecastConfirm message and the 'B' flag in the message MUST
   be set.  When NAR receives the TunnelStateChange message, it SHALL
   check the 'B' flag in Common Header to make sure it is set, then NAR
   MUST reply with a TunnelStateChange message with the 'B' flag unset
   so that the intermediate routers on the bidirectional path can change
   the reservation type (see section 5.4).

   When receiving the HandoverForecastError message, PAR SHALL check to
   make sure that the 'B' flag in Common Header is set and the Code in
   Router_Notify object is filled with 0, then it MUST extract MN's
   current in use CoA and send a new TunnelPath message with the 'B'
   flag set to MN's current subnet (e.g.  Correct NAR in Figure 8), the
   MSESSION object in this message is copied from the
   HandoverForecastError message.  When receiving this TunnelPath
   message, NAR MUST reply with a TunnelResv message.  In addition, NAR
   MUST also send a TunnelPath message on the reverse direction with the
   same SENDER_TSPEC object but with the 'B' flag unset so that the
   bidirectional resource reservation on the neighbor tunnel can be
   established.

   When receiving the HandoverForecastTear message, PAR SHALL check the



Yi, et al.               Expires August 12, 2007               [Page 37]

Internet-Draft                  Fast RSVP                  February 2007


   'B' flag in Common Header to make sure it is set, then it MUST
   extract the MN's formerly falsely predicted CoA and send a
   TunnelPathTear message with the 'B' flag set to MN's falsely
   predicted subnet (e.g.  Error NAR in Figure 8), the MSESSION object
   in this message is copied from the HandoverForecastTear message.
   When receiving this message, intermediate routers MUST remove the
   corresponding Path State and Resv State.  When NAR receivers this
   message, it SHALL check to make sure that the 'B' flag in Common
   Header is set, then NAR MUST send a TunnelPathTear message on the
   reverse direction with the same SENDER_TSPEC object and with the 'B'
   flag unset so that the bidirectional resources reserved in advance on
   the falsely built tunnel can be released.

   When MN is both the receiver and the sender of the session, the
   resource reservation process on the optimized route can be divided
   into two parts: the reservation from CN to MN and the reservation
   from MN to CN.  CN is responsible for the former part and MN is
   responsible for the latter part.

   When MN gets stable in the handover target subnet, it sends a BU
   message to CN.  After the mobile IP module of CN receives this BU
   message, in addition to replying with a BA message to MN, the mobile
   IP module of CN also takes the following actions:

   1.  extracts MN's home address and NCoA (included in the BU message)
       and updates the corresponding entry of the MN in its Pending
       Cache (see section 3.1.) to record the (home address, NCoA) pair.

   2.  sends a SessionHandover.req to the RSVP module inquiring whether
       or not to redirect the session data to the new optimized route.
       The SessionHandover.req MUST contain the (home address, NCoA)
       pair of MN.

   On receiving the SessionHandover.req, the RSVP module of CN MUST try
   to lookup the matching Path or Resv State according to the home
   address of MN.  Then:

   1.  If matching Path or Resv State is not found, it means that MN
       doesn't have any multimedia sessions requiring resource
       reservation.  Then the RSVP module MUST immediately send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       the MN.

   2.  If matching Path or Resv State is found, it means that MN does
       have multimedia sessions requiring resource reservation.  Then
       the RSVP module of CN MUST initiate the resource reservation
       process on the optimized route.  The RSVP module of CN generates



Yi, et al.               Expires August 12, 2007               [Page 38]

Internet-Draft                  Fast RSVP                  February 2007


       the Path message with the 'B' flag unset and sends it to MN as
       well as updates the corresponding Path state (especially updating
       the IPv6 DestAddr field of the MSESSION with MN's NCoA).  The
       MSESSION object in the Path message MUST contain the NCoA as well
       as the home address of MN.  The SENDER_TSPEC in the Path message
       MUST be extracted from the corresponding Path State of MN.  After
       an intermediate RSVP router on the transmission path receives the
       Path message, it MUST check whether it already has the
       corresponding Path State of the session according to the "IPv6
       HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object.
       If the corresponding Path State is found, the RSVP module on the
       router only needs to update this state (especially updating the
       IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise,
       it MUST set up the corresponding Path State for the session.  In
       addition, the RSVP module on the router MUST send an
       AddrNotify.ind to the mobile IP module to indicate MN's home
       address and NCoA, so that the mobile IP module could fill these
       addresses in "Type 2 Routing Header" and the IP header when re-
       encapsulating the Path message.  After the Path message
       corresponding to the optimized route finally reaches MN, the RSVP
       module of MN replies with the proper Resv message as well as
       updates the corresponding Path and Resv state (especially
       updating the IPv6 DestAddr field of the MSESSION with MN's NCoA).
       After an intermediate RSVP router on the transmission path
       receives the Resv message, it checks whether it already has the
       corresponding Resv State of the session according to the "IPv6
       HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object.
       If the corresponding Resv State is found, the RSVP module on the
       router only needs to update this state (especially updating the
       IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise,
       it tries to reserve resources for the session locally and set up
       the corresponding Resv State.  Finally, when the RSVP module of
       CN receives the Resv message and updates the corresponding Resv
       state (especially updating the IPv6 DestAddr field of the
       MSESSION with MN's NCoA), the resource reservation process on the
       optimized route from CN to MN is successfully completed.  Then
       the RSVP module MUST send a SessionHandover.ind to the mobile IP
       module.  The SessionHandover.ind MUST contain the (home address,
       NCoA) pair of MN.  If the reservation on the optimizated route
       fails, CN SHOULD use a certain algorithm (e.g., the binary
       exponential backoff algorithm) to retry the reservation process.
       The choice of the appropriate algorithm is outside the scope of
       this document.  If the resource reservation on the optimized
       route fails even after the ROPATH_RETRIES, CN MUST assume that
       resources are not available on the optimized route.  Then session
       data from CN to MN SHALL be kept transmitting along the old
       resource reservation path and the resource reservation neighbor
       tunnel.



Yi, et al.               Expires August 12, 2007               [Page 39]

Internet-Draft                  Fast RSVP                  February 2007


   On receiving the SessionHandover.ind, the mobile IP module of CN MUST
   update the proper entry in the Binding Cache according to the (home
   address, NCoA) pair of MN which can be extracted from the
   SessionHandover.ind, thus session data from CN to MN is redirected to
   the optimized route from then on.

   In addition, when MN receives the BA message from CN, the mobile IP
   module of MN sends a SessionHandover.req to the RSVP module inquiring
   whether or not to redirect the session data to the new optimized
   route.  The SessionHandover.req MUST contain the (home address, NCoA)
   pair of the MN.

   On receiving the SessionHandover.req, the RSVP module of MN MUST try
   to lookup the matching Path or Resv State according to the home
   address of MN.  Then:

   1.  If matching Path or Resv State is not found, it means that MN
       doesn't have any multimedia sessions requiring resource
       reservation.  Then the RSVP module MUST immediately send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       the MN.

   2.  If matching Path or Resv State is found, it means that MN does
       have multimedia sessions requiring resource reservation.  Then
       the RSVP module of MN MUST initiate the resource reservation
       process on the optimized route.  The RSVP module of MN generates
       the Path message with the 'B' flag unset and sends it to CN.  The
       SENDER_TSPEC in the Path message MUST be extracted from the
       corresponding Path State of the MN.  After an intermediate RSVP
       router on the transmission path receives the Path message, it
       MUST check whether it already has a corresponding Path State of
       the session according to the "IPv6 HomeAddress" "DstPort" and
       "Protocol Id" in the MSESSION object.  If the corresponding Path
       State is found, the RSVP module on the router only needs to
       update this state; otherwise, it MUST set up the corresponding
       Path State for the session.  In addition, the RSVP module on the
       router MUST send an AddrNotify.ind to the mobile IP module to
       indicate MN's home address and NCoA so that the mobile IP module
       could fill these addresses in "Home Address Option" [2] and the
       IP header when re-encapsulating the Path message.  When the Path
       message corresponding to the optimized route finally reaches CN,
       CN SHALL check the 'B' flag in Common Header to make sure it is
       unset, then the RSVP module of CN replies with the proper Resv
       message with the 'B' flag unset.  After an intermediate RSVP
       router on the transmission path receives the Resv message, it
       checks whether it already has the corresponding Resv State of the
       session according to the "IPv6 HomeAddress" "DstPort" and



Yi, et al.               Expires August 12, 2007               [Page 40]

Internet-Draft                  Fast RSVP                  February 2007


       "Protocol Id" in the MSESSION object.  If the corresponding Resv
       State is found, the RSVP module on the router only needs to
       update this state; otherwise, it tries to reserve resources for
       the session locally and set up the corresponding Resv State.
       Finally, when the RSVP module of MN receives the Resv message,
       the resource reservation process on the optimized route
       successfully completes.  Then the RSVP module MUST send a
       SessionHandover.ind to the mobile IP module.  The
       SessionHandover.ind MUST contain the (home address, NCoA) pair of
       MN.  If the reservation on the optimizated route fails, MN SHOULD
       use a certain algorithm (e.g., the binary exponential backoff
       algorithm) to retry the reservation process.  The choice of the
       appropriate algorithm is outside the scope of this document.  If
       the resource reservation on the optimized route fails even after
       the ROPATH_RETRIES, MN MUST assume that resources are not
       available on the optimized route.  Then session data from MN to
       CN SHALL be kept transmitting along the old resource reservation
       path and the resource reservation neighbor tunnel.

   On receiving the SessionHandover.ind, the mobile IP module of MN MUST
   redirect the session data to the optimized route and utilize Home
   Address Option to send packets, thus session data from MN to CN is
   redirected to the optimized route from then on.




























Yi, et al.               Expires August 12, 2007               [Page 41]

Internet-Draft                  Fast RSVP                  February 2007


5.  Miscellaneous

5.1.  RSVP Extensions Capability Exchange

   The MN expects a HandoverForecastResponse message in response to its
   HandoverForecast message.  If the MN does not receive a
   HandoverForecastResponse message even after HF_RETRIES, it MUST
   assume that PAR (NAR) does not support the extensions proposed in
   this document if MN is the receiver (sender) of the session.  Then MN
   MUST stop re-sending the HandoverForecast message.

   Even if the access router to which MN sends the HandoverForecast
   message is capable of the extensions, the other routers on the
   neighbor tunnel may still be incapable of the extensions proposed in
   this document.  This is indicated to MN through the
   HandoverForecastResponse message with a Code value of 1.

5.2.  Distinguishing Handover Sessions and New Sessions

   Experience shows that users are more sensitive to terminating an
   ongoing session compared with blocking a new session.  So the
   extensions proposed in this document introduce a new mechanism to
   distinguish resource reservation requests from different kinds of
   sessions, giving handover sessions a higher priority, therefore
   reducing the forced termination rate of sessions due to handover.
   When the router receives a reservation request, it SHALL first check
   whether the request is included in a Resv message or a TunnelResv
   message, so as to distinguish whether the request is from a new
   session or a handover session.  Then the router SHALL use certain
   algorithms (eg.  Guard Channel) to allocate resources to handover
   sessions with a higher priority.  The allocation algorithm itself is
   out of the scope of this document.  Distinguishing handover sessions
   and new sessions is a fundamental part of the extensions proposed in
   this document and MUST be implemented in every access router that
   supports the extensions.

5.3.  Bidirectional Reservation

   In some types of service (e.g.  Voice over IP), bidirectional
   communication is carried out and therefore, bidirectional reservation
   is required.  However, in traditional RSVP, two distinct sets of
   message exchanges must be implemented to establish the bidirectional
   reservation.  This is troublesome, and may cause considerable delay
   in setting up the resource reservation path.  The extensions proposed
   in this document solve this problem by adding a 'B' Flag in the
   Common Header of the RSVP messages (see section 6.1.).  When this bit
   is set to 1, it indicates that it is a bidirectional reservation;
   otherwise, it is a unidirectional reservation.  When receiving a Path



Yi, et al.               Expires August 12, 2007               [Page 42]

Internet-Draft                  Fast RSVP                  February 2007


   (or TunnelPath) message, the session endpoint SHOULD check whether
   the 'B' flag is set.  If it is set, in addition to sending a Resv (or
   TunnelResv) message, the node SHOULD also send a Path (or TunnelPath)
   message with the same SENDER_TSPEC object and without the 'B' flag
   set on the reverse direction.  The 'B' flag in the Common Header can
   also be meaningful in the messages such as TunnelPathTear and
   TunnelStateChange.  Similarly, when receiving these messages with the
   'B' flag set, the receiver SHOULD consider that the reservation is
   bidirectional and tear down or change the reservation type on the
   reverse direction.  Bidirectional Reservation is an optional
   complement of the extensions proposed in this document and the 'B'
   flag MUST be silently ignored if the node does not recognize it.

5.4.  Utilization of Advanced Reservation before Handover

   The resources reserved in advanced on the tunnel are wasted until the
   handover occurs.  To avoid this problem, the extensions proposed in
   this document add an 'A' flag in the Common Header of the RSVP
   messages (see section 6.1.).  When receiving a TunnelPath (or
   TunnelResv) message with the 'A' flag set, the intermediate routers
   SHOULD create the corresponding Path State (or Resv State) and mark
   the state as "advanced reservation" indicating that the resources are
   reserved in advance and can be used temporarily by other applications
   until the session which makes the reservation indeed hands over to
   the target subnet.  The routers can allocate the advanced reservation
   to some applications with lower priorities (e.g. the Best Effort
   application) or some short time packet bursts.  How to allocate the
   advanced reserved resources is out of the scope of this document.
   When MN moves to the new subnet, it SHALL send a
   HandoverForecastConfirm message to PAR or NAR, depending on whether
   MN is the session receiver or the session sender.  When receiving the
   HandoverForecastConfirm message, PAR (NAR) SHOULD check whether the
   reservation type corresponding to this session is "advanced
   reservation".  If it is, PAR (NAR) MUST send a TunnelStateChange
   message to NAR (PAR).  When intermediate routers receive the
   TunnelStateChange message, they SHALL change the Path State and Resv
   State from the "advanced reservation" to "normal reservation", so
   that the resources SHALL be exclusively used by the handover session
   of MN from then on.  Utilization of Advanced Reservation is an
   optional complement of the extensions proposed in this document and
   the 'A' flag MUST be silently ignored if the intermediate routers do
   not recognize it.









Yi, et al.               Expires August 12, 2007               [Page 43]

Internet-Draft                  Fast RSVP                  February 2007


6.  New Messages and Objects

6.1.  Modified Common Header

   The extensions proposed in this document introduce two flags in the
   Common Header of the RSVP message to support bidirectional
   reservation and the utilization of advanced reservation before the
   handover.

   If the session endpoint wants to establish bidirectional reservation,
   it can set the 'B' flag in the Common Header of the Path (TunnelPath)
   message.  When receiving a Path (TunnelPath) message with the B flag
   set, in addition to replying with the (TunnelResv) message, the
   session endpoint SHALL send a Path (TunnelPath) message in the
   reverse direction.  The 'B' flag MAY also be set in the Common Header
   of HandoverForecast, HandoverForecastConfirm, HandoverForecastError,
   HandoverForecastTear, TunnelStateChange and TunnelPathTear messages
   to indicate the bidirectional reservation.

   If the access router decides that the advanced resource reservation
   on the tunnel can be temporarily utilized by other sessions before
   MN's handover event, it can set the A flag in the Common Header of
   the TunnelPath message and then the intermediate routers SHOULD mark
   the reservation state as "advanced reservation".



























Yi, et al.               Expires August 12, 2007               [Page 44]

Internet-Draft                  Fast RSVP                  February 2007


                      0             1             2             3
               +-------------+-------------+-------------+-------------+
               | Vers | Flags|   Msg Type  |       RSVP Checksum       |
               +-------------+-------------+-------------+-------------+
               |  Send_TTL   |B|A|Reserved |        RSVP Length        |
               +-------------+-------------+-------------+-------------+

         Vers                    See RFC 2205 [1].

         Flags                   See RFC 2205 [1].

         Msg Type                See RFC 2205 [1].

         RSVP Checksum           See RFC 2205 [1].

         Send_TTL                See RFC 2205 [1].

         B flag                  The B flag is set if the reservation is
                                 a bidirectional reservation.

         A flag                  The A flag is set if the reservation is
                                 an advanced reservation.

         RSVP Length             See RFC 2205 [1].

             Figure 12: Format of Common Header


6.2.  New Objects

6.2.1.  New MSESSION Object

   The extensions proposed in this document define a new MSESSION object
   to replace the SESSION object.  Compared with the SESSION object,
   MSESSION adds "IPv6 HomeAddress" field in the object.  The "IPv6
   HomeAddress" field is filled with the MN's home address and its value
   is constant during handover, so we can utilize it to label the
   session.  In the mobile environment, the RSVP router MUST label a
   session based on the content of the MSESSION and set up the
   corresponding Path State and Resv State accordingly.











Yi, et al.               Expires August 12, 2007               [Page 45]

Internet-Draft                  Fast RSVP                  February 2007


        Class = To be allocated by IANA
        C-Type = To be allocated by IANA

                     0             1             2             3
        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +               IPv6 DestAddress (16 bytes)             +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        | Protocol ID |     Flags   |           DstPort         |
        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +               IPv6 HomeAddress (16 bytes)             +
        |                                                       |
        +                                                       +
        |                                                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        IPv6 DestAddress
                The IP unicast or multicast care of address of the
                session.  This field must be non-zero and may change
                during the life time of the session.

        Protocol ID             See RFC 2205 [1].

        Flags                   See RFC 2205 [1].

        DstPort                 See RFC 2205 [1].

        IPv6 HomeAddress
                The IP unicast or multicast home address of the session.
                This field must be non-zero and remain constant during
                the life time of the session.

                Figure 13: Format of MSESSION object


6.2.2.  New Router_Notify Object

   The extensions proposed in this document define a new Router_Notify
   object.  This object is included in the HandoverForecast message,
   HandoverForecastError message and HandoverForecastTear message.  The



Yi, et al.               Expires August 12, 2007               [Page 46]

Internet-Draft                  Fast RSVP                  February 2007


   Code in this object is to notify the access router whether it should
   act as PAR or NAR.  If MN is the session receiver, the tunnel
   endpoint's IP address is MN's NCoA and if MN is the session sender,
   the tunnel endpoint's IP address is PAR's IP address.


         Class = To be allocated by IANA
         C-Type = To be allocated by IANA

                      0             1             2             3
               +-------------+-------------+-------------+-------------+
               |                                                       |
               +                                                       +
               |                                                       |
               +               TunnelEndPointAddr (16 bytes)           +
               |                                                       |
               +                                                       +
               |                                                       |
               +-------------+-------------+-------------+-------------+
               |     Code    |                 Reserved                |
               +-------------+-------------+-------------+-------------+


         TunnelEndPointAddr
                 The IP address of the tunnel endpoint.

         Code            0       The access router should act as PAR.
                         1       The access router should act as NAR.

         Reserved                See RFC 2205 [1].

             Figure 14: Format of Router_Notify object


6.2.3.  New Tunnel_Info Object

   The extensions proposed in this document define a new Tunnel_Info
   object.  This object is included in the HandoverForecastResponse
   message to indicate whether the resource reservation tunnel is
   established successfully.











Yi, et al.               Expires August 12, 2007               [Page 47]

Internet-Draft                  Fast RSVP                  February 2007


         Class = To be allocated by IANA
         C-Type = To be allocated by IANA

                      0             1             2             3
               +-------------+-------------+-------------+-------------+
               | Tunnel Code |                 Reserved                |
               +-------------+-------------+-------------+-------------+

         Tunnel Code     0       Establishment of the RSVP tunnel is
                                 successful.
                         1       Establishment of the RSVP tunnel fails.

         Reserved                See RFC 2205 [1].

              Figure 15: Format of Tunnel_Info object


6.3.  New Messages

6.3.1.  HandoverForecast Message

   When receiving the HandoverForecast.ind from the mobile IP module,
   the RSVP module of MN would send a HandoverForecast message to PAR
   (NAR) to indicate a handover event.  If MN is the session receiver,
   the Router_Notify object in the HandoverForecast message MUST contain
   the care-of address that will be used in the predicted handover
   target (NCoA) as well as Code 0.  If MN is the session sender, the
   Router_Notify object in the HandoverForecast message MUST contain the
   PAR's IP address as well as Code 1.  The information contained in
   HandoverForecast message will be used by PAR (NAR) to establish the
   resource reservation tunnel.  If MN is the sender of the session, the
   sender descriptor object MUST also be contained into this message.
   If MN is the receiver of the session or MN is both the sender and
   receiver of the session, the sender descriptor object need not be
   included.  The Msg Type of the HandoverForecast message needs to be
   allocated by IANA.


           Msg Type = To be allocated by IANA

           <HandoverForecast> ::= <Common Header> [<INTEGRITY>]
                                  <MSESSION> <Router_Notify>
                                  [<sender descriptor>]

           <Router_Notify> ::= <TunnelEndPointAddr> <Code>






Yi, et al.               Expires August 12, 2007               [Page 48]

Internet-Draft                  Fast RSVP                  February 2007


6.3.2.  HandoverForecastResponse Message

   No matter weather the establishment of the resource reservation
   tunnel is successful or not, PAR or NAR MUST send a
   HandoverForecastResponse message to MN.  The new Tunnel_Info object
   in the HandoverForecastResponse message contains a Tunnel Code to
   specify the result of the resource reservation tunnel establishment
   (we only define Code 0 and 1 right now).  The Msg Type of the
   HandoverForecastResponse message needs to be allocated by IANA.


           Msg Type = To be allocated by IANA

           <HandoverForecastResponse> ::= <Common Header> [<INTEGRITY>]
                                          <MSESSION> <Tunnel_Info>

           <Tunnel_Info> ::= <Tunnel Code>


6.3.3.  HandoverForecastConfirm Message

   When receiving the HandoverForecastConfirm.ind from the mobile IP
   module, the RSVP module of MN MUST send a HandoverForecastConfirm
   message to PAR or NAR, depending on whether MN is the session
   receiver or session sender.  The Msg Type of the
   HandoverForecastComfirm message needs to be allocated by IANA.


           Msg Type = To be allocated by IANA

           <HandoverForecastConfirm> ::= <Common Header> [<INTEGRITY>]
                                         <MSESSION>


6.3.4.  TunnelStateChange Message

   When receiving the HandoverForecastConfirm message, PAR (NAR) MUST
   send a TunnelStateChange message to NAR (PAR) so that the
   intermediate routers can change the reservation type form "advanced
   reservation" to "normal reservation".


           Msg Type = To be allocated by IANA

           <TunnelStateChange> ::= <Common Header> [<INTEGRITY>]
                                   <MSESSION>





Yi, et al.               Expires August 12, 2007               [Page 49]

Internet-Draft                  Fast RSVP                  February 2007


6.3.5.  HandoverForecastError Message

   When receiving the HandoverForecastError.ind from the mobile IP
   module, the RSVP module of MN MUST send a HandoverForecastError
   message to PAR or NAR, depending on whether MN is the session
   receiver or session sender.  If MN is the session receiver, the
   Router_Notify object in the HandoverForecast message MUST contain the
   current in use care-of address of MN as well as Code 0.  If MN is the
   session sender, the Router_Notify object in the HandoverForecast
   message MUST contain the PAR's IP address as well as Code 1.  The
   information contained in HandoverForecastError messge will be used by
   PAR (NAR) to re-establish the resource reservation tunnel.  If MN is
   the sender of the session, the sender descriptor object MUST also be
   contained in this message.  If MN is the receiver of the session or
   MN is both the sender and receiver of the session, the sender
   descriptor object need not be included.  The Msg Type of the
   HandoverForecastError message needs to be allocated by IANA.


           Msg Type = To be allocated by IANA

           <HandoverForecastError> ::= <Common Header> [<INTEGRITY>]
                                       <MSESSION> <Router_Notify>
                                       [<sender descriptor>]

           <Router_Notify> ::= <TunnelEndPointAddr> <Code>


6.3.6.  HandoverForecastTear

   When receiving the HandoverForecastError.ind from the mobile IP
   module, the RSVP module of MN MUST send a HandoverForecastTear
   message to PAR, and then PAR can release the resources reserved in
   advance on the falsely built tunnel.  The TunnelEndPointAddr field in
   the Router_Notify object MUST contain MN's formerly falsely predicted
   CoA and the Code field MUST be ignored.  The Msg Type of the
   HandoverForecastTear message needs to be allocated by IANA.


           Msg Type = To be allocated by IANA

           <HandoverForecastTear> ::= <Common Header> [<INTEGRITY>]
                                      <MSESSION> <Router_Notify>
                                      [<sender descriptor>]

           <Router_Notify> ::= <TunnelEndPointAddr> <Code>





Yi, et al.               Expires August 12, 2007               [Page 50]

Internet-Draft                  Fast RSVP                  February 2007


6.3.7.  TunnelPath Message

   TunnelPath message is sent for each session on MN that requests the
   establishment of a resource reservation tunnel.  The MSESSION object
   includes MN's home address, this address together with the "DstPort"
   and "Protocol Id" can be used to uniquely label a session in the
   mobile environment.  If the bidirectional reservation is required,
   the 'B' flag in the Common Header MUST be set and if the "advanced
   reservation" type is supported, the 'A' flag in the Common Header
   SHOULD be set.  The Msg Type of the TunnelPath message needs to be
   allocated by IANA.


           Msg Type = To be allocated by IANA

           <TunnelPath> ::= <Common Header> [<INTEGRITY>]
                            <MSESSION> <RSVP_HOP>
                            <TIME_VALUES>
                            [<POLICY_DATA>...]
                            [<sender descriptor>]


6.3.8.  TunnelResv Message

   TunnelResv message is sent for each session on MN that requests the
   establishment of a resource reservation tunnel.  If the "advanced
   reservation" type is supported, the 'A' flag in the Common Header
   SHOULD be set.  The Msg Type of the TunnelResv message needs to be
   allocated by IANA.


           Msg Type = To be allocated by IANA

           <TunneResv> ::= <Common Header> [<INTEGRITY>]
                           <MSESSION> <RSVP_HOP>
                           <TIME_VALUES>
                           [<RESV_CONFIRM>] [<SCOPE>]
                           [<POLICY_DATA>...]
                           <STYLE> <flow descriptor list>


6.3.9.  TunnelPathTear Message

   On receiving the TunnelPathTear message, the intermediate routers
   MUST delete the corresponding Path State and Resv State that match
   the MSESSION object.  If the bidirectional reservation needs to be
   removed, the 'B' flag in the Common Header of the TunnelPathTear
   message SHALL be set.  The Msg Type of the TunnelPathTear message



Yi, et al.               Expires August 12, 2007               [Page 51]

Internet-Draft                  Fast RSVP                  February 2007


   needs to be allocated by IANA.


           Msg Type = To be allocated by IANA

           <TunnelPathTear> ::= <Common Header> [<INTEGRITY>]
                                <MSESSION> <RSVP_HOP>
                                [<sender descriptor>]


6.3.10.  TunnelResvTear Message

   On receiving the TunnelResvTear message, the intermediate routers
   MUST delete the corresponding Resv State that matches the MSESSION
   object.  If the bidirectional reservation needs to be removed, the
   'B' flag in the Common Header of the TunnelResvTear message SHALL be
   set.  The Msg Type of the TunnelPathTear message needs to be
   allocated by IANA.


           Msg Type = To be allocated by IANA

           <TunnelResvTear> ::= <Common Header> [<INTEGRITY>]
                                <MSESSION> <RSVP_HOP>
                                [<SCOPE>]<STYLE>
                                <flow descriptor list>

























Yi, et al.               Expires August 12, 2007               [Page 52]

Internet-Draft                  Fast RSVP                  February 2007


7.  Security Considerations

   This document introduces a procedure and two related new RSVP
   messages (HandoverForecast, HandoverForecastResponse) for MN to
   inform PAR (or NAR) to establish the resource reservation tunnel.  If
   the HandoverForcast message is insecure, the resource may be stolen
   because the resource reservation tunnel may be established for the
   malicious node.  Hence, the PAR MUST ensure that MN that sends the
   HandoverForcast message is a legal node.  Therefore, a Security
   Association (SA) between MN and PAR (or NAR) must be established.  A
   lot of research work has already been done on the establishment of SA
   in the mobile environment.  Then IPsec could be utilized to ensure
   the secure transmission of the messages.

   This document introduces a procedure and four related messages
   (TunnelPath, TunnelResv, TunnelPathTear, TunnelResvTear) for PAR (or
   NAR) to establish and release the resource reservation tunnel.  There
   are no new security considerations beyond those already addressed in
   the existing RSVP reservation establishment and release of RFC2205.

   This document introduces a procedure and three related new RSVP
   messages (HandoverForecastConfirm, HandoverForecastError,
   HandoverForecastTear) for MN to inform PAR whether the handover
   prediction is successful or fails.  The security considerations are
   similar to those in the establishment of the resource reservation
   tunnel discussed above.

   This document introduces a procedure for CN to establish the
   reservation on the optimized route and there is no new security
   considerations beyond those already addressed in the existing RSVP
   reservation establishment of RFC2205.




















Yi, et al.               Expires August 12, 2007               [Page 53]

Internet-Draft                  Fast RSVP                  February 2007


8.  IANA Considerations

8.1.  RSVP Common Header Flags

   This document requests that IANA manages the flags in the Common
   Header of the RSVP message.  Two new flags, the 'B' flag and the 'A'
   flag are defined in section 6.1.

8.2.  RSVP Objects

   This document requests that IANA allocates three new Class-Num and
   three new C-Types for the MESSION object, Router_Notify object and
   Tunnel_Info object defined in section 6.2.  Note that the MESSION
   object only supports the IPv6 addressing now.

8.3.  RSVP Messages

   This document requests that IANA allocates ten new Msg Type for the
   ten new RSVP messages defined in section 6.3.
































Yi, et al.               Expires August 12, 2007               [Page 54]

Internet-Draft                  Fast RSVP                  February 2007


9.  Acknowledgements


















































Yi, et al.               Expires August 12, 2007               [Page 55]

Internet-Draft                  Fast RSVP                  February 2007


10.  References

10.1.  Normative References

   [1]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC 2205, September 1997.

   [2]  Johnson, David B., Perkins, E., and BJari. Arkko, "Mobility
        Support in IPv6", RFC 3775, June 2004.

   [3]  Z. Kan, D Zhang, R. Zhang and J. Ma. QoS in Mobile IPv6. In
        Proc. of International Conferences on Info-tech and Info-
        net 2001, Vol. 2, pp 492-497.
       
   [4]  R. Koodli, Ed., Karim El Malki, Mohamed Khalil, Charles E. 
        Perkins, "Fast Handovers for Mobile IPv6", RFC 4068, July
        2005.
	      	      
   [5]  A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP 
        Operation over IP Tunnels", RFC 2746, Janauary 2000.
        	
10.2.  Informative References




























Yi, et al.               Expires August 12, 2007               [Page 56]

Internet-Draft                  Fast RSVP                  February 2007


Authors' Addresses

   Yi Sun
   Institute of Computing Technology, Chinese Academy of Sciences
   Mailbox 2704
   Beijing,   100080
   P.R. China

   Phone: +86-10-62600711
   Fax:   +86-10-62533449
   Email: sunyi@ict.ac.cn


   Bin Feng
   Beijing University of Posts and Telecommunications
   Beijing
   P.R. China

   Phone: +86-13810106501
   Email: fengbin8210@126.com


   Yucheng Zhang
   University of Electronic Science and Technology of China
   Beijing
   P.R. China

   Phone: +86-13426339145
   Email: zyc552@sohu.com


   Rusong Zheng
   Institute of Computing Technology, Chinese Academy of Sciences
   Mailbox 2704
   Beijing,   100080
   P.R. China

   Phone: +86-10-62600712
   Fax:   +86-10-62533449
   Email: zhengrusong@ict.ac.cn











Yi, et al.               Expires August 12, 2007               [Page 57]

Internet-Draft                  Fast RSVP                  February 2007


   Wenxia Dong
   SouthWest JiaoTong University of China
   Beijing
   P.R. China

   Phone: +86-10-62600712
   Fax:   +86-10-62533449
   Email: dongwenxia@ict.ac.cn


   Jinglin Shi
   Institute of Computing Technology, Chinese Academy of Sciences
   Mailbox 2704
   Beijing,   100080
   P.R. China

   Phone: +86-10-62600734
   Fax:   +86-10-62533449
   Email: zsjl@ict.ac.cn


   Eryk Dutkiewicz
   University of Wollongong
   Wollongong NSW 2522
   Australia

   Phone: +61-2-42214650
   Fax:   +61-2-42214464
   Email: eryk@uow.edu.au






















Yi, et al.               Expires August 12, 2007               [Page 58]

Internet-Draft                  Fast RSVP                  February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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).





Yi, et al.               Expires August 12, 2007               [Page 59]