Internet Engineering Task Force                          Charles Qi Shen
draft-shen-nsis-rsvp-mobileipv6-00.txt                      Winston Seah
July 12, 2002                                                 Anthony Lo
Expires: January 2003                                                ICR
                                                           Haihong Zheng
                                                              Marc Greis
                                                                   Nokia

     Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework
                <draft-shen-nsis-rsvp-mobileipv6-00.txt>

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section&nbsp;10 of RFC2026.

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

1 Abstract

   This memo first gives a brief review of a RSVP and Mobile IPv6
   interoperation framework proposed in [1] and compared its features
   with the Performance Requirements set forth by Requirements of a QoS
   Solution for Mobile IP [2]. The subsequent part of the memo presents
   specification details including message formats, processing rules and
   algorithms that form the framework. The vast majority of these
   specifications has been verified by a prototype implementation. It is
   expected that this work could serve as a useful input in dealing with
   NSIS protocol and mobility issue.

2 Terminology

        MS - Mobile Sender A Mobile Node that is acting as a Flow
             Sender.

        MR - Mobile Receiver A Mobile Node that is acting as a Flow
             Receiver.



Shen, Seah, Lo, Zheng and Greis                               [Page 1]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


        SNCR - Sender Nearest Common Router the first common router on
             the old path and new path after a handoff caused by MN
             functioning as a MS.

        RNCR - Receiver Nearest Common Router the first common router on
             the old path and new path after a handoff caused by MN
             functioning as a MR.

        NCR - Nearest Common Router could be either a SNCR or a RNCR.

   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.

3 Introduction

   The increasing interest in supporting QoS sensitive applications in a
   mobile environment has led to extensive work on interoperation of QoS
   signaling and mobility mechanisms. Typically the issue is addressed
   in the context of RSVP and Mobile IP . This memo is a follow-up of
   our previous proposal on an Interoperation Framework for using RSVP
   in an Mobile IPv6 network[1].

   In this memo, we first give a brief review of the framework and
   evaluate it against the Requirement of a QoS Solution for Mobile IP
   [2] that was formed after our framework proposal. Then we present the
   specification details concerning New Message/Object Formats,
   processing rules as well as (Nearest Common Router) NCR Decision
   Algorithms which have been developed extensively since the previous
   framework memo.

   It is known that the IETF Next Step In Signaling (NSIS) WG has been
   charted to look at a future resource signaling protocol and the NSIS
   framework is well likely to cover the interaction with general
   mobility mechanism as well. In view of the fact that, RSVP is
   recommended to be used as a starting point for NSIS, and Mobile IP is
   likely the pre-dominant mobility mechanism for IP macro-mobility, we
   expect this work to be a useful input to the area of NSIS and
   mobility interaction. In addition, we provide a separate discussion
   on several issues related to general NSIS and mobility interaction in
   [3]. The similar topic is also covered as part of a framework
   proposal by Handcock et. al. [4].

   It is worth noting that, the vast majority of signaling logic and
   processing rules disclosed herein have been verified by a prototype
   implementation modified from the latest ISI RSVP release.

4 Framework and Requirements Review



Shen, Seah, Lo, Zheng and Greis                               [Page 2]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   The essential point of our framework[1] is to maintain a unique flow
   identifier regardless of node mobility. To achieve this specifically
   within the Mobile IP and RSVP context, we have chosen to use MN HAs
   in RSVP SESSION object and RSVP SENDER_TEMPLATE object. While the
   correct routing of signaling packets is ensured by using MN CoAs.

   A brief review of our RSVP-Mobile IPv6 framework is given below. We
   assume a generic scenario where both communication parties could be
   mobile. So we will use the terms Mobile Sender (MS) and Mobile
   Receiver (MR) instead of MN to reflect the situation more accurately,
   wherever necessary. The illustration of framework operation in each
   of the MR and MS case is divided into three signaling phases
   according to different functionalities, although they indeed overlap
   in terms of actual signaling timing.

4.1 Framework Review: Mobile Sender (MS) Case

4.1.1 Resource Establishment in the New Path

   When the MS obtains a new care-of address upon handoff, it
   immediately sends a PATH message containing its mobility information
   (which is its new CoA) towards the CN. This PATH message triggers the
   establishment of PATH state in the RSVP routers on the path until it
   reaches the Sender Nearest Common Router (SNCR). The SNCR finds the
   PATH message arriving with a previous hop address different from the
   one stored in the path state, upon which it immediately replies with
   a RESV message towards the MN using the new path. The reserved
   resources between the SNCR and the CN can be reused.

4.1.2 Resource Release in the Obsoleted Path

   In addition to the above, the SNCR sends a RESVTEAR message towards
   the previous hop stored in the old path state. The RESVTEAR message
   triggers the removal of the reserved resources on the old path which
   are no longer needed.

4.1.3 Refresh Handling in the Common Path

   The SNCR also forwards the received handoff PATH message to the next
   hop in any case so as to update the mobility information in all RSVP
   routers on the rest of the path. This is to ensure correct routing of
   subsequent refresh messages.

4.2 Framework Review: Mobile Receiver (MR) Case

4.2.1 Resource Establishment in the New Path

   When the MR obtained a new care-of address upon handoff, it is



Shen, Seah, Lo, Zheng and Greis                               [Page 3]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   required to inform the Receiver Nearest Common Router (RNCR) of its
   mobility information in order to trigger a quick handoff PATH message
   from the RNCR. This avoids waiting for a handoff PATH message from
   the CN, which requires at least a round trip time between MR and CN.
   This is achieved by the use of a new RSVP PATHREQ message. It may
   optionally be piggybacked in a PATH message sent by the MN when it
   acts as both MS and MR.  In the following discussion, we assume the
   former method, or a separate PATHREQ message is used. The PATHREQ
   message which carries MR's mobility information (the new CoA) will be
   sent toward the CN and will be examined by each intermediate RSVP
   node until it reaches RNCR. The RNCR then triggers a Local Repair for
   the receiver route change that is, the router sends a handoff PATH
   message associated with the unique flow identifier, to the MN's new
   care-of address. This serves to establish resource state in the new
   path as soon as possible.

4.2.2 Resource Release in the Obsoleted Path

   In addition to the above, RNCR also sends a PATHTEAR message towards
   the MN's old care-of address. The PATHTEAR message triggers the
   removal of the resources on the old path which are no longer needed.

4.2.3 Refresh Handling in the Common Path

   RNCR also forwards the PATHREQ message to the next hop until it
   reaches the CN so as to update the mobility information in all the
   RSVP routers on the common path. This is to insure correct routing of
   subsequent refresh messages.

4.3 Requirements Review: Evaluate the Framework Against Requirements

   A quick examination of the Requirement of a QoS Solution for Mobile
   IP [2] shows that the above framework addressed all three performance
   requirements set forth, namely

        o Minimize the interruption in QoS at the time of handover.

        o Localize the QoS (re)establishment to the affected parts of
          the packet path in the network.

        o Releasing after handover the QoS state (if any) along the old
          packet path.

   The first and second requirements are addressed by the use of NCR in
   establishing resource state within new path incurred by handoff. The
   third requirement is met by explicitly issuing of corresponding state
   teardown messages at the NCRs.  In the following sections we present
   specification details concerning New Message/Object Formats, NCR



Shen, Seah, Lo, Zheng and Greis                               [Page 4]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   Algorithms and Processing rules that form the above RSVP-Mobile IPv6
   framework.

5 Formats of New RSVP Objects and Messages

5.1 Formats of SENDER_MOBILITY Object and RECEIVER_MOBILITY Object

   New MOBILITY objects are defined in order to convey MN's mobility
   information to RSVP. In the simplest case for Mobile IP, it contains
   the MN's current care-of address. By including these new objects, the
   RSVP process does not need to get the mobility information of the MN
   from the IP header of the RSVP messages, the clear interface between
   the IP layer and the RSVP process is maintained.


                   0             1              2             3
         +-------------+-------------+-------------+-------------+
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                   Care-of Address                     +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |    Flags    | (Reserved)  |   Sequence Number         |
         +-------------+-------------+-------------+-------------+



                               Flags: 8 bits

                               0x01: NCR Identified

               When set, indicates that the NCR has been identified.

                       Figure 1: MOBILITY Object





   In accordance with the simplex nature of RSVP, two types of MOBILITY
   objects are defined, namely, SENDER_MOBILITY objects and
   RECEIVER_MOBILITY objects. Figure 1 shows the format for the MOBILITY
   object. The length field indicates the total object length in bytes.



Shen, Seah, Lo, Zheng and Greis                               [Page 5]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   The Class Num and the C-Type for the MOBILITY object would have to be
   assigned by IANA. SENDER_MOBILITY objects and RECEIVER_MOBILITY
   objects shall have different Class Nums. The contents of the MOBILITY
   object contain:

        o Mobility information which is MS or MR's current care-of
          address.

        o An NCR Flag bit which indicates whether the appropriate NCR
          has been located. The bit carries an initial value of 0 and is
          set to 1 by the NCR.

        o A two-byte Sequence Number field which increases by one after
          each handoff and thus indicates how up-to-date the mobility
          information is.

5.2 Format of PATHREQ Message


   The new PATHREQ message is defined to allow the MR to request a PATH
   message from RNCR immediately after it performs a handoff. Figure 2
   shows the format of a PATHREQ message, it contains:

        o An RSVP common header, in which the message type for PATHREQ
          message has to be assigned by IANA.

        o A SESSION object containing the MR's home address.

        o A SENDER_TEMPLATE object containing the MS's home address.

        o A RECEIVER_MOBILITY object containing the MR's current care-of
          address.

        o A SENDER_MOBILITY object containing the MS's current care-of
          address.

   Inclusion of the above four objects makes RSVP aware of the care-of
   address and home address of both MS and MR thus covers the most
   complicated case where both communication parties are MNs and acts as
   Sender and Receiver simultaneously. In case either party is
   stationary, the corresponding MOBILITY object will not be applicable
   and the home address above is replaced by the corresponding fixed
   address.

6 Nearest Common Router (NCR) Decision Algorithm

   The decision for NCRs is divided into two parts: SNCR and RNCR.
   Generally, decision for SNCR is triggered by receiving of PATH



Shen, Seah, Lo, Zheng and Greis                               [Page 6]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002



         +-------------+-------------+-------------+-------------+
         |                  RSVP Common Header                   |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                    SESSION object                     +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                SENDER_TEMPLATE object                 +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +               RECEIVER_MOBILITY object                +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                SENDER_MOBILITY object                 +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+



                                 Figure 2: PATHREQ Message




   messages; decision for RNCR is triggered by receiving of PATHREQ
   messages; RNCR and SNCR may be physically collocated in the same
   router, or could be in two different network entities.




Shen, Seah, Lo, Zheng and Greis                               [Page 7]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


6.1 Decision Algorithm for Sender NCR (SNCR)

   RSVP decides that it is the SNCR if all of the following conditions
   are met.

        o A PATH message which contains a SENDER_MOBILITY object is
          received.

        o The NCR Flag bit in the received SENDER_MOBILITY object is
          Zero.

        o There is a matching PSB found for the PATH message.

        o The matching PSB does not include a SENDER_MOBILITY object or
          the matching PSB contains a SENDER_MOBILITY object which has a
          sequence number lower than that of the received
          SENDER_MOBILITY object.

6.2 Decision Algorithm for Receiver NCR (RNCR)

   RSVP decides that it is the RNCR if all of the following conditions
   are met.

        o A PATHREQ message which contains a RECEIVER_MOBILITY object is
          received.

        o The NCR Flag bit in the received RECEIVER_MOBILITY object is
          Zero.

        o There is a matching PSB found for the SESSION object in the
          received PATHREQ message.

        o The matching PSB does not include a RECEIVER_MOBILITY object
          or the matching PSB contains a RECEIVER_MOBILITY object which
          has a sequence number lower than that of the received
          RECEIVER_MOBILITY object.

7 Processing Rules for PATHREQ Message and PATH Message with MOBILITY
   Object

7.1 Processing Rule for New PATHREQ Message

   The PATHREQ message is sent by a MR when it changes its care-of
   address. The general processing rules when RSVP receives a PATHREQ
   message are as follows:

        o RSVP searches for PSBs in the opposite direction whose SESSION
          object matches the corresponding object in the PATHREQ



Shen, Seah, Lo, Zheng and Greis                               [Page 8]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


          message.

        o If there are no matching PSBs, the PATHREQ message is simply
          forwarded to the next RSVP node. The source address and
          destination address of the forwarded PATHREQ message are
          determined as follows:

          - The source address is retrieved from RECEIVER_MOBILITY
            object which contains the receiver's care-of address.

          - The destination address is retrieved from SENDER_MOBILITY
            object which contains the sender's care-of address, if it
            exists. Otherwise, the destination address is retrieved from
            SENDER_TEMPLATE object which contains the sender's fixed or
            home address.

        o Otherwise there are matching PSBs found. For each matching
          PSB,

          - If RECEIVER_MOBILITY information is found in the PSB and the
            sequence number of that RECEIVER_MOBILITY is higher than
            that of the received RECEIVER_MOBILITY object, discard the
            received PATHREQ message.

          - Otherwise, if RECEIVER_MOBILITY is not found in the PSB or
            RECEIVER_MOBILITY is found in the PSB but with a lower
            sequence number:

            - The PSB is updated with the new RECEIVER_MOBILITY object.

            - If SENDER_MOBILITY exists either or both in PSB or
              PATHREQ, compare their sequence number, update PSB with
              the newer SENDER_MOBILITY object if applicable.

            - Check the NCR Flag bit in the received RECEIVER_MOBILITY
              object:

              - If the NCR Flag bit is 1, and the RSVP node is not the
                sender, forward the PATHREQ message to the next RSVP
                node using the same source and destination address
                decision rules as stated above when there is no matching
                PSB.

              - If the Flag bit is 0, the RSVP node is identified as
                RNCR. It does the following:

                Sets the NCR Flag bit into 1; Constructs a handoff PATH
                message that includes the RECEIVER_MOBILITY object, and



Shen, Seah, Lo, Zheng and Greis                               [Page 9]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


                sends it to the receiver's current care-of address
                obtained from the same RECEIVER_MOBILITY object;
                Constructs a PATHTEAR message containing the old
                RECEIVER_MOBILITY object, if exists, to the receiver's
                old care-of address; If the RSVP node is not sender of
                the flow, it further forwards the PATHREQ message to the
                next RSVP node using the same source and destination
                address construction rule as stated above when there is
                no matching PSB.

7.2 New Processing Rules for PATH Message

   To deal with node mobility, PATH messages shall carry MOBILITY
   objects. If the MS performs a handoff, a SENDER_MOBILITY object will
   be included in the PATH messages. If the MR performs a handoff and
   reports it to the sender through PATHREQ message, the subsequent PATH
   message will carry the RECEIVER_MOBILITY object.

   The following states new/modified processing rules for PATH messages
   in addition to existing rules specified in RFC 2209 due to the
   introduction of new MOBILITY objects.

        o When RSVP creates a new PSB for a new PATH message with
          MOBILITY objects, the following rules apply in addition to/in
          place of existing rules where applicable:

          - If SENDER_MOBILITY object is included in the PATH message,
            it is also copied to the newly created PSB.

          - If RECEIVER_MOBILITY object is included in the PATH message,
            it is also copied to the newly created PSB.

          - When the PATH message is forwarded to the next RSVP node.
            The source address and destination address of the forwarded
            PATH message are determined as follows:

            - The source address is retrieved from SENDER_MOBILITY
              object which contains the sender's care-of address, if it
              exists. Otherwise, the source address is retrieved from
              SENDER_TEMPLATE object which contains the sender's fixed
              or home address.

            - The destination address is retrieved from
              RECEIVER_MOBILITY object which contains the receiver's
              care-of address, if it exists. Otherwise, the destination
              address is retrieved from SESSION object which contains
              the receiver's fixed or home address.




Shen, Seah, Lo, Zheng and Greis                              [Page 10]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


        o Otherwise, if matching PSB is found, the following rules apply
          in addition to/ in place of existing rules where applicable:

          - First, if a RECEIVER_MOBILITY object is included in the PATH
            message, the RSVP node determines whether it carries the
            most updated information based on the sequence number of the
            object. If the existing PSB contains no RECEIVER_MOBILITY
            information or the received RECEIVER_MOBILITY information is
            newer than the existing one, the PSB updates its
            RECEIVER_MOBILITY information.

          - Second, if a SENDER_MOBILITY object is included in the PATH
            message, the RSVP node determines whether it carries the
            most updated information based on the sequence number of the
            object. If the received SENDER_MOBILITY is older than the
            existing one in PSB, stops processing the PATH message and
            discards it. Otherwise, if the existing PSB contains no
            SENDER_MOBILITY information or the received SENDER_MOBILITY
            information is newer than the existing one,

            - The PSB updates its SENDER_MOBILITY information.

            - The NCR Flag bit in the received SENDER_MOBILITY object is
              checked. If it is not set, the RSVP node is identified as
              SNCR. It does the following:

              Sets the NCR Flag bit to 1; Sends a RESV message to the
              previous hop which leads to the MS's current care-of
              address; Sends a RESVTEAR message to the previous hop
              which leads to the MS's old care-of address; If the RSVP
              node is not receiver of the flow, it further forwards the
              PATH message to the next RSVP node using the same source
              and destination address decision rules as stated above
              when there is no matching PSB.

            - Otherwise the RSVP node is not SNCR. If the RSVP node is
              not receiver of the flow, it forwards the PATH message to
              the next RSVP node using the same source and destination
              address decision rules as stated above when there is no
              matching PSB.

8 Future Work

   In traditional operation of RSVP, a flow identifier is virtually also
   used as a reservation identifier. This seems to be fine in fixed
   networks. In mobile environments however, it might sometimes be
   desirable to separate these two, while the flow identifier could be
   changing from time to time, the reservation identifier remains



Shen, Seah, Lo, Zheng and Greis                              [Page 11]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   constant all the time [3,4]. It should be noted that our proposed
   framework does not in any sense exclude this possibility. More
   specifically, in cases where the reservation identifier is defined
   differently than the flow identifier, our use of HAs as reservation
   identifier does not exclude the use of addresses other than HAs, such
   as the CoAs as flow identifier. In this case, it is expected that the
   signaling logic explained in this memo will still largely be
   applicable, although certain modifications are likely to be needed.
   The applicability of this approach in our framework is currently
   under study.

9 Acknowledgments

   We would like to thank Mr. Donglin Shi for helpful discussion during
   the prototype implementation of this work.

10 Bibliography

   [1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An
   Interoperation Framework for Using RSVP in Mobile IPv6 Networks,"
   draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001.  Work in
   Progress.

   [2] H. Chaskar (Editor), "Requirements of a QoS Solution for Mobile
   IP," draft-ietf-mobileip-qos-requirements-02.txt , June 2001.  Work
   in Progress.

   [3] C. Q. Shen, "Several Framework Issues Regarding NSIS and
   Mobility," draft-shen-nsis-mobility-fw-00.txt , July 2002.  Work in
   Progress.

   [4] R. Hancock et.al., "Next Steps in Signaling: A Framework
   Proposal," draft-hancock-nsis-fw-00.txt , June 2002.  Work in
   Progress.

11 Authors' addresses

   Charles Qi Shen
   Institute for Communications Research (ICR)
   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674
   Phone: +65 6870-9358
   Email: shenqi@icr.a-star.edu.sg

   Winston Seah
   Institute for Communications Research (ICR)



Shen, Seah, Lo, Zheng and Greis                              [Page 12]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674
   Phone: +65 6870-9163
   Email: winston@icr.a-star.edu.sg

   Anthony Lo
   Institute for Communications Research (ICR)
   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674

   Haihong Zheng
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA
   Phone: +1 972 894 4232
   Email: haihong.zheng@nokia.com

   Marc Greis
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA
   Phone: +1 972 374 0629
   Email: marc.greis@nokia.com

12 Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be



Shen, Seah, Lo, Zheng and Greis                              [Page 13]


Internet Draft         RSVP Mobile IPv6 Interop            July 17, 2002


   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS 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.




                           Table of Contents



   1          Abstract ............................................    1
   2          Terminology .........................................    1
   3          Introduction ........................................    2
   4          Framework and Requirements Review ...................    2
   4.1        Framework Review: Mobile Sender (MS) Case ...........    3
   4.1.1      Resource Establishment in the New Path ..............    3
   4.1.2      Resource Release in the Obsoleted Path ..............    3
   4.1.3      Refresh Handling in the Common Path .................    3
   4.2        Framework Review: Mobile Receiver (MR) Case .........    3
   4.2.1      Resource Establishment in the New Path ..............    3
   4.2.2      Resource Release in the Obsoleted Path ..............    4
   4.2.3      Refresh Handling in the Common Path .................    4
   4.3        Requirements Review: Evaluate the Framework
   Against Requirements ...........................................    4
   5          Formats of New RSVP Objects and Messages ............    5
   5.1        Formats of SENDER_MOBILITY Object and
   RECEIVER_MOBILITY Object .......................................    5
   5.2        Format of PATHREQ Message ...........................    6
   6          Nearest Common Router (NCR) Decision Algorithm ......    6
   6.1        Decision Algorithm for Sender NCR (SNCR) ............    8
   6.2        Decision Algorithm for Receiver NCR (RNCR) ..........    8
   7          Processing Rules for PATHREQ Message and PATH
   Message with MOBILITY Object ...................................    8
   7.1        Processing Rule for New PATHREQ Message .............    8
   7.2        New Processing Rules for PATH Message ...............   10
   8          Future Work .........................................   11
   9          Acknowledgments .....................................   12
   10         Bibliography ........................................   12
   11         Authors' addresses ..................................   12
   12         Full Copyright Statement ............................   13






Shen, Seah, Lo, Zheng and Greis                              [Page 14]