Internet Engineering Task Force                          Charles Qi Shen
Internet Draft                                                       CWC
draft-shen-rsvp-mobileipv6-interop-00.txt                   Winston Seah
Date: July 2001                                                      CWC
                                                              Anthony Lo
                                                                Ericsson
                                                           Haihong Zheng
                                                                   Nokia
                                                              Marc Greis
                                                                   Nokia

  An Interoperation Framework for Using RSVP in Mobile IPv6 Networks
              <draft-shen-rsvp-mobileipv6-interop-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".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

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

1 Abstract

   This draft proposes a Mobile IPv6 and RSVP interoperation scheme. In
   this scheme, the underlying mobility support mechanism is required to
   provide a unique flow identity regardless of node mobility, making
   the node mobility transparent to flow QoS handling mechanisms. Thus
   QoS signaling delay as well as data packet delays and losses during
   handoff can be reduced.

2 Introduction

   With the growing demand for the development of commercially viable
   wireless and cellular services over Mobile IP [1] and especially



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   Mobile IPv6 [2], it is highly important to consider the interaction
   between mobility and QoS [3,4]. In particular, it is necessary to
   evaluate the applicability of existing QoS mechanisms for IP mobility
   and to enhance them, where necessary.

   This draft focuses on issues of the operation of RSVP [5] over Mobile
   IPv6, more precisely on the resulting handoff QoS performance. More
   specifically, the handoff QoS signaling delays are required to be
   small enough to minimize the handoff data packet delays and losses,
   thus also avoiding possible service degradation during handoff. In
   this draft we first identify the problems of running RSVP over MIPv6,
   and then propose a Flow Transparent Mobile IP and RSVP interoperation
   scheme to achieve this goal.

   The organization of this draft is as follows: We begin with the
   problem analysis and then discuss the Flow Transparency concept. Then
   we propose the solutions in detail, followed by the handoff operation
   of the flow transparent scheme as well as its main features. Finally,
   we discuss the security and scalability aspects of this scheme.

3 Problem Statement

   A flow [6] is a sequence of packets sent from a particular source to
   a particular destination for which the source desires special
   handling by the intervening routers. This special handling can be non
   best effort QoS treatment set up through RSVP. In a fixed network,
   the flow source and flow destination are fixed after the RSVP
   resource reservation is established for that flow. In a mobile
   environment using Mobile IPv6, however, the flow source or flow
   destination may change during an application session.

   The existing work on Mobile IPv6 and RSVP integration [7,8] usually
   identifies the flow source or flow destination based on the Mobile
   Node's care-of address. According to Mobile IPv6's built-in route
   optimization, the Correspondent Nodes (CNs) usually send packets
   directly to the Mobile Node's care-of address when the Mobile Node
   (MN) is the receiver; Mobile IPv6 also substitutes the MN's home
   address in the source address field of outgoing packets with the MN's
   care-of address when the MN is the sender, while placing the home
   address in the Home Address Option in the destination option header.

   The result is that at the network layer, the flow identity changes
   each time when the MN performs a handoff and obtains a new care-of
   address. Thus, a single application session corresponds to multiple
   network layer flows, each of which requires a new RSVP renegotiation.
   This could cause situations where a new reservation is denied because
   the old reservation is still active and blocks resources, or the new
   reservation exists simultaneously along with the old reservation.



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   More importantly, a change in the network layer flow identity means
   that all the intermediate routers along the path have to re-build
   related flow information. Thus, all handoff RSVP renegotiations have
   to be performed end-to-end, no matter how small the impact of the
   handoff on the flow path may be. This introduces long handoff QoS
   signaling delay and increases the delays and losses of data packets,
   which could lead to notable service degradation during handoffs.

   In summary, using RSVP over Mobile IPv6 poses several problems. These
   problems are caused by address inconsistencies as well as a lack of
   efficiency in the RSVP operation when the MN performs handoff and
   changes its care-of address. The problems can be separated in three
   different categories as described in the following sections.

3.1 Packet Classification Mismatch

   When a mobile acts as a sender, the PATH message from the MN contains
   the MN's home address in the SENDER_TEMPLATE object, as it can be
   assumed that the RSVP daemon in the MN is unaware of Mobile IPv6.
   This implies that the FILTER_SPEC in resulting RESV messages contains
   the mobile node's home address, i.e. the classification of packets in
   intermediate routers for the relevant session is based on the home
   address of the MN. However, the source address for packets sent from
   the MN is not the nodes home address, but its current careof address,
   as the mobile IP stack in the MN replaces the home address with the
   care-of address in any outgoing packets to avoid problems related to
   ingress filtering. This means that RSVP routers on the path of the
   relevant traffic flows are not able to classify these packets
   correctly, i.e. the traffic flow would not receive the requested QoS.

   The same applies for the case where the MN acts as a receiver. A PATH
   message arriving at a MN contains the mobile node's home address in
   the SESSION object. However, the destination address for packets sent
   to the MN is the node's care-of address, while the home address of
   the MN is carried in the routing header. This again prevents the
   packets for the flow from receiving the correct QoS, as they can not
   be assigned to the correct RSVP session in intermediate routers.
   Obviously, the packet classification mismatch issue when the MN acts
   as a receiver is not just for the Mobile IPv6 case, but is also a
   generic issue for RSVP when source routing is used. When source
   routing is used, the address of the real destination is not placed in
   the destination address field in the IP header, but in the last entry
   of the routing header instead, unless all the intermediate routers on
   the source routing path have processed the packet.

3.2 Handoff Inefficiency

   Another problem arises when the MN moves to a new point of attachment



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   and changes its care-of address. In the uplink direction (i.e. the
   direction from the MN towards the CN), it could simply reissue a PATH
   message, which causes a RESV message to be sent from the nearest
   common router (i.e. the nearest router common to both the old and new
   path for the flows from the MN to the CN). In the case that the old
   path and the new path does not share any common path, the nearest
   common router is the CN.

   However, the reservation on the old path between the nearest common
   router and the MN's former point of attachment would remain in place
   until the reservation state for this path times out. This is not
   acceptable, especially when considering that a MN could change its
   care-of address very frequently, potentially leaving behind a large
   number of "stale" reservations at old access routers. It also needs
   to be considered that the refresh delay and resulting from this also
   the reservation timeout delay may be set to relatively high values in
   MNs (and their respective) access networks to reduce the number of
   PATH and RESV refresh messages, as it is necessary to preserve
   expensive air interface resources in wireless and cellular networks,
   which are likely to constitute a major use case for Mobile IPv6.

   For the downlink direction, when the MN changes its care-of address,
   the CN or the crossover router do not automatically issue new PATH
   messages for any sessions involving the MN. This implies that on the
   new path between the nearest common router and the MN, the data flow
   would only receive best-effort QoS. A problem related to this is that
   even if the corresponding node could be forced to immediately issue a
   new PATH message for the session towards the new care-of address when
   a binding update message is received from the MN, the intermediate
   routers would not recognize that this PATH message is not a refresh
   message (as the RSVP objects contained in the message would not
   change, since RSVP is unaware of the MN's movement), which means that
   the PATH "update" would only reach the first RSVP-capable router, but
   would not be sent on from there, as this router assumes that it is
   only a refresh message.

3.3 Refresh and Forwarding of RSVP Messages

   RSVP processes on RSVP-capable routers do not receive any information
   about the source and destination address from the IP header of the
   PATH message which created a PATH state. Thus, when a PATH state is
   refreshed, the source and destination address of the PATH refresh
   message have to be constructed from the SESSION object and the
   SENDER_TEMPLATE object contained in the PATH message. However, when
   mobile nodes are involved in the session, these objects again contain
   only home addresses but not care-of addresses. Hence, the PATH
   messages are sent with the wrong addresses and may even be routed
   incorrectly, i.e. the correct path is no longer refreshed and



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   eventually the reservation times out.

   Note that this problem does not apply for RESV messages, as they are
   routed hop-by-hop based on the PATH state information. However, the
   hop-by-hop forwarding mechanism used for RESV messages causes yet
   another problem for the interoperation between RSVP and Mobile IPv6.
   Before forwarding a PATH message, each RSVP-capable router writes the
   address of the interface over which the PATH message is sent into the
   RSVP_HOP object in the PATH message so that the corresponding RESV
   messages can later be sent towards this interface from the next RSVP
   router. The interface address is determined by the RSVP process by
   querying the routing tables in the router based on the address
   information given in the SESSION and SENDER_TEMPLATE objects. As
   these objects contain the MN's home address, the RSVP_HOP object
   would contain the address of the interface which would be used to
   send the RSVP message towards the home address, when it is actually
   forwarded towards the care-of address. This causes the RESV messages
   to be routed incorrectly.

3.4 Using the Care-of Address to Identify Flows

   One could argue that the simplest solution for at least some of the
   problems described above would be to make the RSVP processes in the
   end nodes (i.e. MN and CN) aware of Mobile IPv6. This would imply
   that in any RSVP objects contained e.g. in PATH or RESV messages sent
   by the MN and the CN, the mobile node's current care-of address could
   be used, instead of its home address. As a result, the packets
   belonging to the relevant traffic flows would be classified
   correctly. This is a very simple approach with the advantage that
   only changes in end nodes are required. However, this approach has
   several disadvantages, which are listed below:

   - As the intermediate routers only see the care-of address, the PATH
   and RESV messages which are sent with the new care-of address would
   trigger a totally new reservation in the intermediate routers instead
   of re-using the old reservation, even though the new and old
   reservation may share mostly the same path. In addition, the delay
   caused by the RSVP signal processing would be one round trip for the
   uplink and one and a half round trips for the downlink if we assume
   the binding update sent from the MN to the CN triggers the PATH
   message sent from the CN. During this period, the packets sent to and
   from the MN can only be handled using best effort, which could lead
   to a notable service degradation during handoff.

   - It is not clear how a MN would remove an old session after
   receiving a new care-of address if sessions are identified based on
   the care-of address. The reservation with the old care-of address
   would remain in place until the RSVP soft state for this reservation



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   times out. This would imply that the user may have to pay for two
   potentially expensive reservations for a certain amount of time. This
   is not acceptable, especially when considering that a MN could change
   its point of attachment and its care-of address very frequently, thus
   leaving behind a lot of old unused reservations.

   - The old care-of address of a MN may be reused after it changes its
   point of attachment to the Internet, which may imply that if
   reservations are identified based on the care-of address, another
   node could benefit from a reservation which has not been removed and
   which has also not timed out yet.

   - If sessions are identified based on the care-of address, it is
   necessary to set up fully new RSVP sessions after a MN receives a new
   care-of address instead of just updating the existing sessions. In
   the worst case this could mean that a session which still exists for
   a node's old care-of address (i.e. a session which has not timed out
   yet) could block the establishment of the session for the new care-of
   address, even though both sessions are meant to handle the same
   traffic flow.

   - In order for an RSVP process in a CN to obtain the care-of address
   of the MN, Mobile IP needs to provide an interface to reveal the
   care-of address of the MN, which could also be used by any other
   applications. This may violate location privacy requirements.

   - If all RSVP sessions for a MN have to be re-established whenever
   this node changes its point of attachment and obtains a new care- of
   address, this also implies that all procedures related to admission
   control and policy control have to be performed again, e.g. bandwidth
   brokers and policy servers may have to be contacted by RSVP-capable
   routers on the path. This potentially implies a latency which is not
   acceptable e.g. for handoffs in cellular environments.

   - In this approach, it is also necessary to always "negotiate" the
   new RSVP sessions all the way between the MN and the correspondent
   node. This precludes optimized solutions where it would be possible
   to only set up the path between the MN and the nearest common router.

4 Proposed Solutions

   To address the issues described above, we propose an interoperation
   scheme between RSVP and MIPv6. This framework is based on the flow
   transparency concept, which is discusssed in section 4.1. Based on
   the flow transparency concept, multiple new features are proposed to
   either implement the concept, or to supplement it for achieving a
   seamless "QoS handoff".




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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


4.1 Flow Transparency Concept

   To address the issues described in section 3, we introduced a Flow
   Transparency concept [9,10] i.e., the underlying mobility support
   scheme is required to keep node mobility completely transparent to
   network layer flow handling mechanism. Essentially, flow transparency
   calls for a unique flow identity irrespective of the change of the
   mobile node's address, thus enabling the network layer flow handling
   mechanism to function normally regardless of node mobility. A flow
   transparent approach naturally avoids the following two problems:

   First, since the network layer flow identity remains the same after a
   handoff, the old reservation can be reused by the same flow whenever
   possible. Second, with a constant flow identity after handoff, the
   routers residing in the common portion of the new and old flow path
   do not have to perform a QoS update during handoff; only those
   routers that are on the new path section may be needed for the update
   process. This avoids the need for end-to-end renegotiation.

   It is worth noting that with node mobility, the number and identity
   of routers involved in the same flow are dynamic and usually
   unpredictable. It is the routers common to both new and old path of
   the flow that constitute the scope of flow transparency. This implies
   that automatic flow handling adaptation for those routers in the
   newly added path is required in order to exploit the flow
   transparency concept.

   The flow transparent mobility support is fundamental in the
   interoperation framework of using RSVP over MIPv6. With Mobile IPv6
   and RSVP, the natural solution to provide flow transparency, i.e., a
   unique flow identity regardless of node mobility, is to use the
   mobile node's home address instead of its care-of address to identify
   the source or the destination of a flow. By using the mobile node's
   home address to identify the source or destination of a flow, we
   separate the routing and the QoS functionality in a router. The
   former is based on the care-of address, reflecting the node's
   mobility; the latter is based on the home address, without the impact
   of node mobility.

   In order to identify a flow using the home address, the home address
   needs to be carried in every packet, no matter if the MN is acting as
   a sender or a receiver. The two scenarios are discussed in the
   following sections.

4.1.1 Mobile Node as Sender

   Two approaches can be used to carry the home address of an MN when it
   acts as a sender.



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   - Approach 1: According to the Mobile IPv6 specification, for packets
   sent by a mobile node, Mobile IPv6 will move the MN's home address to
   the IPv6 packet header to the Home Address option carried in an IPv6
   Destination Options Header. Since this header will not be examined
   until reaching the packet destination, intermediate routers will not
   be able to correctly classify packets belonging to the flow.
   Therefore, when flow transparency is required, we suggest that Mobile
   IPv6 ignores this special processing for MN's home address and leaves
   it in the IP source address field to enable router QoS processing.
   Note that this only requires modifications at end nodes. The ingress
   filting problem resulting from this approach will be discussed in the
   Security Considerations section.

   - Approach 2: MN uses its care-of address as source address as
   specified in the Mobile IPv6 specification, and certain modifications
   to the intermediate RSVP nodes will be required.  Three alternatives
   are proposed below.

   * Alternative 1: The Home Address Option is carried in the
   destination option as defined in Mobile IPv6. Upon receiving an IPv6
   packet, an IPv6 RSVP node classifies the source of the packet using
   the home address in the Home Address destination option if present,
   instead of the care-of address in the source address field in the
   IPv6 header. In order to do so, the IPv6 RSVP node checks the
   presence of the Home Address option in the destination option header
   when it receives an IPv6 packet. If it is present, the RSVP node
   classifies the packet using the home address; otherwise, it still
   uses the address carried in the source address field in the IP
   header.

   * Alternative 2: The Home Address Option is still carried in the
   Destination Option Header, but a newly defined Flow Transparency
   Router Alert Option carried in a Hop-by-hop Options Header may be
   inserted into the outgoing packets sent by the MN to notify each
   intermediate router of the need to classify the source address of the
   sender using the Home Address Option carried in the Destionation
   option header.

   * Alternative 3: A Mobile IPv6 node may simply move the Home Address
   Option into a Hop-by-hop Options Header when flow transparency is
   required, so that all intermediate routers will have access to the
   MN's home address.

   The three alternatives above all require modifying intermediate
   routers to look for the MN's home address at an appropriate place to
   perform packet classification correctly.

4.1.2 Mobile Node as Receiver



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   When MN acts as a receiver, no modification is required to the
   current MIPv6, where MN's care-of address is carried in the
   destination address field in the IP header and the home address is
   carried in the routing header. However, certain modifications of the
   packet classification procedure are needed in the intermediate RSVP
   nodes, as described in section 4.2. Note that in this draft, only the
   case that no additional source routing other than the MN's care-of
   address is considered. The other case where other explict routing is
   included requires more complicated system design and will be
   discussed in a future version of this draft.

4.2 Proper Packet Classification

   Based on the flow transparency concept, the home address instead of
   the care-of address is used to classify the packet. In order to
   classify a packet properly, special handling may be needed depending
   on the approach used to carry the home address.

4.2.1 Scenario 1: Mobile Node as Sender

   When approach 1 described in section 4.1.1 is used to carry the home
   address, no modification is required for the packet classification
   procedure defined in the current RSVP specification. Slight
   modifications are needed for the Ingress Filtering mechanism, as
   detailed in the Security Considerations section of this draft.
   However, since Ingress Filtering is normally deployed only in the
   periphery of the networks [11], the number of affected routers is
   expected to be small.

   If approach 2 is used, slight modifications are needed in the packet
   classifier in the intermediate RSVP routers. Upon receiving an IPv6
   packet, an RSVP node classifies the source of the packet using the
   home address in the destination option. Depending on the schemes for
   carrying the home address proposed for approach 2, such a checking
   procedure can be triggered by observing either the presence of the
   home address option in the destination option, or the presence of the
   flow transparency alert in the hop-by-hop option, or the presence of
   the home address carried in the hop-by-hop option.

4.2.2 Scenario 2: Mobile Node as Receiver

   To send a packet to a Mobile IPv6 node which is not in its home
   network, the home address of the MN is placed in the last entry in
   the address list of the routing header. The ability to correctly
   process a routing header in a received packet is required in all IPv6
   nodes, whether mobile or stationary, whether host or router. Based on
   this fact, we propose to identify the MN as a receiver using the
   address in the last entry of the routing header, instead of the



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   address carried in the destination address field in the IP header.
   With this approach, slight modifications are needed in the packet
   classifier in the intermediate RSVP routers.

   An alternative approach is enabled by the IPv6 flow label. An IPv6
   flow can be uniquely identified by the combination of a source
   address and a non-zero flow label. In order to maintain a unique flow
   identity to facilitate packet classification in a mobile environment,
   we suggest that the flow label be constant during the whole lifetime
   of the session regardless of node mobility. With this usage of flow
   label, as well as the use of existing flow-label related objects
   defined in RSVP protocol, routers may perform packet classification
   without examining the flow destination. Thus, this approach does not
   require modification to packet classification in intermediate RSVP
   routers. Another benefit of this approach is that it facilitates the
   use of RSVP in the presence of IPSec.

4.3 Refresh and Forwarding of RSVP Messages

   To solve the problem of sending PATH refresh messages in the uplink
   direction from a MN towards a CN, we propose to carry MN's mobility
   information in every PATH message sent from the MN and record the
   mobility information in the path state maintained by each RSVP node.
   The mobility information, containing the mapping between the home
   address and the current care-of address of the MN, is carried in a
   new RSVP object called "mobility object". The mobility information
   maintained in the PATH state is established upon receiving the first
   mobility object for a specific home address, and updated by
   subsequent mobility objects. Theoretically the mobility object only
   needs to be sent at the beginning of a session and whenever the CoA
   of MN has been changed, however, due to the unreliable transmission
   nature of RSVP messages, it needs to be carried in every PATH message
   originating from a MN to reduce the chance of non-updated PATH state
   due to packet loss.

   When the mobility object is used, not only the SESSION and
   SENDER_TEMPLATE objects, but also the care-of address maintained in
   the path state are used to determine the source address of a PATH
   refresh message. More specifically, the source address field in the
   PATH refresh message should carry the up-to-date care-of address of
   the MN, while the home address is carried in the destination option
   header.

   To solve the problem of sending PATH refresh message in the downlink
   direction from a CN towards a MN, we propose that the source routing
   information (i.e., the destination address plus the address list in
   the routing header) in the latest PATH message sent from the CN to
   the MN is added to the PATH state. In this draft, since we only



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   consider the case that no extra source routing is used except what
   MIPv6 requires, the source routing only consists of the home address
   and the current CoA of the MN. The source routing information in the
   PATH state is established upon recieving the first PATH message
   towards the MN, and is updated by the consecutive PATH message sent
   towards the MN with the same home address.

   Whenever a PATH refresh message needs to be sent, not only the
   SESSION and SENDER_TEMPLATE object, but also the source routing
   information is used to construct the PATH message. More specifically,
   a PATH refresh message contains the current care-of address of the MN
   in the destination address field, and the home address in the routing
   header.

   Including the source routing information into the PATH state also
   solves the problem of correctly routing RESV messages. As described
   in section 3.3, before forwarding a PATH message, each RSVP router
   writes the address of the interface over which the PATH message is
   sent into the RSVP_HOP object in the PATH message. Instead of using
   the SESSION and SENDER_TEMPLATE objects for querying the routing
   tables, we propose to use the care-of address maintained in the PATH
   state. Thus, the RSVP_HOP object would contain the address of the
   interface that is used to send the RSVP message towards the care-of
   address instead of the home address, which enables the RESV messages
   to be routed correctly.

4.4 Handoff Efficiency

   Improving the handoff efficiency is the major focus of this scheme.
   Based on the Flow Transparancy concept, we propose following scheme
   to improve the handoff efficiency.

4.4.1 Scenario 1: Mobile Node as Sender

   If the Home Address is used to classify the sender, the resource
   reservation efficiency problem on the uplink direction for the MN
   after its handoff is solved without any further changes to Mobile
   IPv6 or RSVP. After changing the care-of address, the MN immediately
   sends a PATH message towards the CN. This PATH message will trigger
   the establishment of PATH state in the RSVP routers on the path until
   it reaches the Uplink Nearest Common Router (UNCR - the first common
   router on the old path and new path for the flows from the MN towards
   the CN). The UNCR observes the PATH message arriving with a previous
   hop address different from the one stored in the path state, upon
   which it will immediately reply with a RESV message towards the MN
   using the new path. The reserved resources between the UNCR and the
   CN can be reused. In the case that there is no common path shared by
   the new path and the old path on the uplink, the UNCR is the CN.



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   After processing the PATH message, the UNCR needs to forward the PATH
   message to the next hop in any case. The purpose of this is to update
   the mobility information in all the RSVP routers on the path between
   in order to issue a proper refresh message. The details have been
   discussed in section 4.3.

   However, as mentioned in section 3.2, although the new path between
   the mobile nodes current point of attachment and the nearest common
   router is established, the old path between the MNs former point of
   attachment and the nearest common router still remains in place.
   Therefore, we propose that upon receiving the PATH message, the UNCR
   not only replies with a RESV message using the new path, but also
   sends a RESVTEAR message towards the previous hop stored in the old
   path state. The RESVTEAR message will trigger the removal of the
   reserved resources on the old path which are no longer needed.

4.4.2 Scenario 2: Mobile Node as Receiver

   The situation is more complicated when the MN is acting as a
   receiver. After a handoff, the receiver sends a Binding Update to the
   CN. At the same time, it should inform the Downlink Nearest Common
   Router (DNCR - the closest router to the MN, which is on both the old
   and the new path for the flows from CN to MN) of its mobility
   information in order to trigger a handoff PATH message from the DNCR
   on the downlink. This avoids waiting for a handoff PATH message from
   the CN, which usually has to be issued after the CN receives the
   Binding Update.

   The mobility object can be carried alone in a newly defined RSVP
   PATHREQ message if the MN acts solely as a receiver or it can be
   piggybacked in a PATH message sent by the MN itself if the MN acts as
   both sender and receiver. Besides the common header, the PATHREQ
   message carries the mobility object. The PATHREQ message and the PATH
   message with a mobility object will have the CN as destination
   address and will be examined by each intermediate RSVP node. The
   format of the PATHREQ message and the mobility object is specified in
   section 5.1.

   Upon receiving a PATHREQ message or a PATH message carrying a
   mobility object sent from the MN, the RSVP router decides whether it
   is the DNCR by comparing the home address and the care-of address in
   the mobility object sent from the MN against the same information in
   the PATH state for the flow destined to the MN. The rules of DNCR
   decision are described in section 5.2.

   If the router decides that it is the DNCR and it observes that there
   is a PATH state that matches the mobility object on the downlink
   direction, a Local Repair for the receiver route change will be



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   triggered, that is, the router sends a handoff PATH message for the
   flow indicated by the flow destination, to the MN's new care-of
   address. Inside the handoff PATH message, the destination address
   contains the new CoA carried in the mobility object, and the routing
   header carries the home address of the MN. Furthermore, if the
   mobility object is carried in a PATHREQ message, the NCR doesn't need
   to forward the the PATHREQ to the next RSVP router. If it is carried
   in a PATH message, then the NCR needs to forward the PATH message to
   the next hop until it reaches the CN. The purpose of forwarding the
   PATH message is to update the mobility information in all the RSVP
   routers on the path between in order to issue a proper refresh
   message. The details are discussed in section 4.3. The format of the
   PATHREQ message and the mobility object is described in section 5.1.
   The processing rules of the PATHREQ message as well as the PATH
   message with the mobility object are described in section 5.2.

   In addition, although the new path between DNCR and MN has been
   established, the old path between DNCR and MN's old point of
   attachment still remains in place. Therefore, we propose that after
   sending a handoff PATH message towards the MN's new CoA, NCR also
   sends a PATHTEAR message towards the MN's old CoA. The PATHTEAR
   message will trigger the removal of the resources on the old path
   which are no longer needed.

   With this approach, the RSVP process does not need to get the care-of
   address of the MN from the IP header of the RSVP messages, but just
   uses the information provided by the mobility object. The clear
   interface between the IP layer and the RSVP process does not need to
   be modified. Furthermore, the classification rules (i.e., whether to
   use the source address of the packet or home address in the home
   address option) can be based on the question if a home address/care-
   of address mapping state has been established for the flow. This
   makes the classification more efficient.

5 Message Format, Algorithms and Processing Rules

   Some details of the message format, algorithms and message processing
   rules are discussed in the following sections.

5.1 Format of Mobility Object and PATHREQ Message

   The mobility object contains the home address and the current care-of
   address of the MN. Figure 1 shows the format of the mobility object.
   The length field indicates the total object length in bytes. The
   Class Num and the C-Type for the mobility object would have to be
   assigned by IANA.

   The PATHREQ message has a common header followed by the mobility



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   object defined above. Again, the message type would have to be
   assigned by IANA.


                   0             1              2             3
         +-------------+-------------+-------------+-------------+
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                     Home Address                      +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                   Care-of Address                     +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+


                         Figure 1: MOBILITY Object





5.2 Nearest Common Router Decision

   When a RSVP router receives a PATHREQ message, it needs to decide if
   it is the DNCR. When it receives a PATH message, it needs to decide
   if it is the DNCR and/or UNCR. DNCR and UNCR may be physically
   collocated in the same router, or could be two different network
   entities.

   On the uplink direction, a RSVP router decides if it is the UNCR just
   by comparing the home address, the CoA and the previous RSVP hop
   carried in the PATH message against the same information stored in
   the Path State in the uplink direction.

   - If there is no PATH state matching the home address, the router
   could be one of the new routers on the new path between the MN and
   the UNCR, or one of the routers on the path between the UNCR and the



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


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   CN if the path is changed due to the failure of a RSVP router, load
   balancing or other reasons.

   - If the home address matches but the CoA is different from what is
   stored in the PATH state, then

   * If 1) there is a PATH state related to the home address for the
   flow sent from the MN, and 2) for the same home address, the previous
   RSVP hop remains the same, then the router is one of the routers on
   the existing path between the UNCR and the CN, instead of the UNCR.

   * If 1) there is a PATH state related to the home address for the
   flow sent from the MN, and 2) for the same home address both the
   care-of address and the previous RSVP hop have been changed, the
   router is the UNCR.

   On the downlink direction, a RSVP router decides if it is the DNCR by
   searching the home address against the PATH state on the downlink
   direction. If there is a match of the home address in the PATH state
   in the downlink direction, then the router decides it is the DNCR;
   otherwise it is not.

5.3 Processing Rules for PATHREQ and PATH with Mobility Object

5.3.1 Processing Rule for PATHREQ Message

   The PATHREQ message is sent when a MN acts only as a receiver and it
   changes its care-of address. The general processing rules for the
   PATHREQ message are as follows

   - When a RSVP node receives a PATHREQ message and it does not have
   any matching PATH state on the opposite direction based on the home
   address carried in the mobility object, it just forwards the message
   to the next RSVP node.

   - When a RSVP node receives a PATHREQ message and it has a matching
   PATH state for a flow in the opposite direction based on the home
   address carried in the mobility object, it decides it is the DNCR and
   needs to send a PATH message towards MN's new CoA and performs the
   following procedures.

   * If there is no source routing information related to the home
   address, which indicates that the MN was inside its home network and
   did not have a CoA, the RSVP router updates the source routing
   information by inserting the new CoA before the home address in the
   source routing address list. Then it constructs a PATH message based
   on the updated information in the PATH state and then sends it to the
   MN. The RSVP router also constructs a PATHTEAR message and sends it



Shen, Seah, Lo, Zheng, Greis                                 [Page 15]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   to the MN's home address.

   * If there is source routing information related to the home address,
   the RSVP router just updates the source routing information by
   replacing the old CoA with the new CoA. Then the RSVP router
   constructs a PATH message based on the updated information in the
   PATH state and then sends it to the MN. It also constructs a PATHTEAR
   message that contains the old CoA in the destination address and the
   home address in the destination option header, and sends it to clean
   up the PATH state on the old path.

5.3.2 Processing Rule for PATH Message

   A PATH message is sent when a MN acts as a sender only or as both
   sender and receiver and it changes its CoA. The general processing
   rules for the PATH message with a mobility object are as follows.

   - When a RSVP router receives a PATH message with a mobility object,
   it first checks its PATH states on the uplink direction.

   * If there is no PATH state on the uplink direction mataching the
   home address carried in the mobility object, the RSVP router
   establish a new PATH state, including the mobility information
   carried in the mobility object, then forwards the message to the next
   hop.

   * If there is already PATH state for the uplink direction, which
   matches the home address, then the RSVP router compares the CoA
   information maintained in the PATH state against the one in the
   mobility object.

   - If the CoAs are the same, the PATH message is only considered as a
   refresh message, and whether or not to forward it to the next hop
   depends on the message processing rules as currently defined for
   RSVP.

   - If the CoAs are different from each other, the PATH state should be
   updated with the new mobility information carried in the mobility
   object and the PATH message is forwarded to the next hop. If the RSVP
   router also finds out that the RSVP_HOP objects in the PATH State and
   in the PATH message are different, the local repair should be
   invoked, and a RESV message is sent to the MN using the updated
   information in the PATH State. In addition, it also sends a RESVTEAR
   message towards the old CoA of the MN to tear down the old
   reservation.

   - After checking the uplink PATH state, the RSVP node also checks the
   PATH state on the opposite direction. The procedure is exactly the



Shen, Seah, Lo, Zheng, Greis                                 [Page 16]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   same as described in section 5.3.1, except for the message name.

6 Seamless QoS Provision for Handoffs

   Seamless handoff QoS provision is always desired in a mobile QoS
   scheme. Normally this requires to explicitly reserve resources in
   advance at the cells that the MN is about to visit [12,13,14,15]. The
   challenge for these schemes is, how to predict the MN's movement
   behavior so that pre-reservation may be done only in necessary cells.
   If prediction is not available, resource pre-reservation may have to
   be performed in all neighboring cells, which wastes resources.
   Although this waste may be alleviated through definition of new RSVP
   reservation models (like active reservations and passive
   reservations), the expense would be extra protocol complexity.

   The flow transparent RSVP and Mobile IPv6 interoperation provides a
   relatively simple alternative of making seamless handoff QoS
   provision possible. In the handoff mobility and QoS signaling as
   mentioned above, it is likely that the RSVP message will traverse
   shorter than the Binding Update , because the handoff RSVP message
   ends at a Nearest Common Router while the Binding Update has to reach
   the CN all the time. Thus the RSVP renegotiation holds a possibility
   of being finished before the CN is updated with MN's new care-of
   address, especially when there are congested links within the path
   between the Nearest Common Router and CN. This implies that before CN
   starts sending packets to MN's new location, resources could have
   already been set up along that path. As a consequence, all packets
   subsequently destined for MN's new location from the CN will be
   offered QoS as desired and no any extra delay is incurred due to
   handoff. In other words, the QoS provision to the flow is seamless
   during the handoff, which might give great improvements to handoff
   service quality of mobile real-time services.

7 Security Considerations

   The Approach 1 in Section 4.1.1 suggests that a Mobile Node uses the
   home address as source address when flow transparency is required.
   This approach, if used, may cause problems with Ingress Filtering
   [11], which is a security measure used to defeat denial of service
   attacks that employ IP source address spoofing. Packets directly
   using Mobile Node's home address as source address will likely be
   dropped by the Ingress Filtering routers if they are sent from a
   foreign network. A possible solution to this problem is presented
   below.

   When a Mobile Node is sending a packet, the home address is placed in
   the source address field, and current Mobile IPv6 special processing
   for the Mobile Node's home address is replaced with a new processing



Shen, Seah, Lo, Zheng, Greis                                 [Page 17]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   for its care-of address. A new Care-of Address Option similar to the
   current Home Address Option in Mobile IPv6 is defined as shown in
   figure 2.


       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  | Option Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        Care-of Address                        +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 2: Care-of Address Option





   This Care-of Address Option will then be carried as an IPv6
   Destination Option Header in each outgoing packets sent by the MN
   (similar to the current Mobile IPv6 specification). The remaining
   part is for the Ingress Filtering mechanism to attend to this change.
   So the Ingress Filtering routers will be required to not only examine
   the IP address in the source address field, but also to look for the
   Care-of Address Option before making a decision. If the care-of
   address matches the incoming interface of the packet, it SHOULD also
   forward the packet as appropriate. Note that in this case although
   the care-of address option is carried as a Destination Options
   Header, it is actually examined by an intermediate router - the
   router which performs Ingress Filtering. If this is seen as a
   confliction with the Destination Options Header definition, which
   says it carries optional information that needs to be examined only
   by a packet's destination node(s), then a new IPv6 extension header,
   called Intermediate Router Options Header, may be defined similarly.
   It will have the same format as the Destination Options Header except
   for the Header Type value, and it will carry optional information
   that needs to be examined by intermediate routers like in this case.

   The above solution to Ingress Filtering maintains its original
   purpose, i.e., when an attack of denial of service does indeed occur,



Shen, Seah, Lo, Zheng, Greis                                 [Page 18]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   a network administrator can be sure that the attack is actually
   originating from within the known prefixes that are being advertised.
   The modification required for its implementation is also in line with
   possible additional functions that should be considered for future
   platform implementations as suggested in [11].

8 Scalability Considerations

   There has been wide concern over the scalability of end-to-end RSVP
   and Integrated Service (Intserv) architecture, which has led to the
   development of relatively simple and coarse methods of providing
   differentiated classes of service for Internet traffic, such as
   Differentiated Service (Diffserv). However, Intserv, RSVP and
   Diffserv may still be viewed as complementary technologies in the
   pursuit of end-to-end QoS and a framework combining Intserv/RSVP and
   Diffserv offers great benefits [16,17]. A possible architecture of
   this kind could be Diffserv deployed in the backbone or core networks
   and Intserv/RSVP in access or edge networks. If this is the case, the
   flow transparent scheme may be viewed as a "Micro Mobile QoS" scheme
   which improves handoff QoS performance within a domain consisting of
   wireless and fixed access networks, because this scheme can also
   accommodate Flow Transparency incapable clouds. Routers that do not
   understand the newly defined MOBILITY object can simply ignore and
   forward it until a capable router is reached and decides it is the
   Nearest Common Router. To one extreme, if all routers along the path
   are flow transparency capable, each handoff will involve minimum
   routers possible. To the other extreme, if none of the routers in the
   path understand flow transparency, it goes back to the normal end-to-
   end scheme. If some of the routers are flow transparency enabled, the
   effect will be something in between, depending on the specific router
   deployment.

9 Concluding Remarks and Future Work

   This draft proposes a Flow Transparent Mobile IPv6 and RSVP
   interoperation scheme. The scheme requires the node mobility to be
   kept transparent from QoS flow handling mechanism, thus making it
   possible to keep the RSVP renegotiation from being performed end-to-
   end each time when the MN changes its care-of address. This could
   minimize delays and losses of the handoff QoS signaling and data
   packets. Depending on the network scenario, seamless handoff QoS
   provision might be achieved, which would further improve handoff
   performance of mobile real-time services.

   The future network architecture is likely to be the Internet
   connecting with heterogeneous wireless access networks, such as
   UMTS/GPRS, Wireless LAN, Bluetooth, etc. Different access
   technologies may overlap since they possess different



Shen, Seah, Lo, Zheng, Greis                                 [Page 19]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   characteristics. Flow Transparency may particularly be important in
   the case where the MN performs a handoff at the same location, simply
   switching between subnets of different access technologies.

   It is possible that in the wireless Internet framework, the QoS
   mechanism in the access part would involve mechanisms like the Packet
   Data Protocol (PDP) Context mechanisms in UMTS/GPRS and/or RSVP, and
   that of the core network would include Diffserv and/or MPLS. Further
   work is required to formulate details about how the flow transparent
   scheme operates in such a framework. A change of QoS requirements
   during handoff should also be considered. Multicasting support may be
   taken into account too. Furthermore, Flow Transparency itself might
   be extended from single-flow to multiple-flow transparency to
   accommodate mobility support with coarser QoS technologies like
   Diffserv.

10 Intellectual Property Considerations

   CWC may seek intellectual property protection for technologies
   disclosed herein. If any standards arising from this disclosure
   become protected by one or more patents assigned to CWC, CWC
   undertakes to license them on reasonable and nondiscriminatory terms
   based on reciprocity.

   Nokia Corporation and/or its affiliates hereby declare that they are
   in conformity with Section&nbsp;10 of RFC 2026. Nokia's contributions may
   contain one or more patents or patent applications. To the extent
   Nokia's contribution is adopted to the specification, Nokia
   undertakes to license patents technically necessary to implement the
   specification on fair, reasonable and nondiscriminatory terms based
   on reciprocity.

11 Bibliography

   [1] C. Perkins, "IP Mobility Support," RFC 2002 , October 1996.

   [2] D. Johnson and C. Perkins, "Mobility Support in IPv6," IETF
   Internet Draft , November 2000.  work in progress.

   [3] H. Chaskar, "Requirements of a QoS Solution for Mobile IP,"
   draft-chaskar-mobileip-qos-requirements-00.txt , June 2001.  work in
   progress.

   [4] M. Thomas, "Analysis of Mobile IP and RSVP Interactions," draft-
   thomas-seamoby-rsvp-analysis-00.txt , February 2001.  work in
   progress.

   [5] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,



Shen, Seah, Lo, Zheng, Greis                                 [Page 20]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
   Specification," RFC 2205 , September 1997.

   [6] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification," RFC 2460 , December 1998.

   [7] G. Fankhauser, S. Hadjiefthymiades, N. Nikaein, and L. Stacey,
   "RSVP Support for Mobile IP Version 6 in Wireless Enviroments," Tech.
   Rep.  TIK-Report Nr. 58, Computer Engineering and Networks
   Laboratory, Swiss Federal Institute of Technology (ETH) Zurich, 1998.

   [8] G. Chiruvolu, A. Agrawal, and M. Vandenhoute, "Mobility and QoS
   Support for IPv6-based Real-time Wireless Internet Traffic," 1999
   IEEE International Conference on Communications , vol. 1, pp. 334--8,
   1999.

   [9] Q. Shen, A. Lo, W. Seah, and C.C. Ko, "On Providing Flow
   Transparent Mobility Support for IPv6-based Wireless Real-time
   Services," Proceedings of the Seventh International Workshop on
   Mobile Multimedia Communications (MoMuC2000) , pp. 2B--4--1 -- 2B--4-
   --6, October 2000.

   [10] Q. Shen, A. Lo, and W. Seah, "Performance Evaluation of Flow
   Transparent Mobile IPv6 and RSVP Integration," To appear in
   Proceedings of the Fifth World Multi-Conference on Systemics,
   Cybernetics and Informatics (SCI2001) , July 2001.

   [11] P. Ferguson and D. Senie, "Ingress Filtering: Defeating Denial
   of Service Attacks Which Employ IP Source Address Spoofing," RFC 2827
   , May 2000.

   [12] A.K. Talukdar, B.R. Badrinath, and A. Acharya, "MRSVP: A
   Reservation Protocol for an Integrated Services Packet Network with
   Mobile Hosts," Tech. Rep. DCS-TR-337, Department of Computer Science,
   Rutgers University, U.S.A., 1997.

   [13] W. Chen and L. Huang, "RSVP Mobility Support: A Signaling
   Protocol for Integrated Services Internet with Mobile Hosts,"
   Proceedings of IEEE INFOCOM 2000: Conference on Computer
   Communications , vol. 3, pp. 1283--92, 2000.

   [14] D.O. Awduche and E. Agu, "Mobile Extensions to RSVP,"
   Proceedings of Sixth International Conference on Computer
   Communications and Networks , pp. 132--6, 1997.

   [15] I. Mahadevan and K.M. Sivalingam, "An Experimental Architecture
   for Providing QoS Guarantees in Mobile Networks Using RSVP,"
   Proceedings of Ninth International Symposium on Personal, Indoor, and



Shen, Seah, Lo, Zheng, Greis                                 [Page 21]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   Mobile Radio Communications (PIMRC'98) , vol. 1, pp. 50--4, 1998.

   [16] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, and et al., "A
   Framework for Integrated Services Operation over Diffserv Networks,"
   RFC 2998 , November 2000.

   [17] Y. Bernet, "The Complementary Roles of RSVP and Differentiated
   Services in the Full-Service QoS Network," IEEE Communications , vol.
   38, no. 2, pp. 154--162, 2000.

12 Authors' addresses

   Charles Qi Shen
   Centre for Wireless Communications
   National University of Singapore
   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674
   Singapore
   Phone: +65 870-9358
   Email: shenqi@cwc.nus.edu.sg

   Winston Seah
   Centre for Wireless Communications
   National University of Singapore
   20 Science Park Road
   #02-34/37, TeleTech Park
   Singapore Science Park II
   Singapore 117674
   Singapore
   Phone: +65 870-9163
   Email: winston@cwc.nus.edu.sg

   Anthony Lo
   Ericsson EuroLab Netherlands
   Business & Science Park
   Institutenweg 25
   P O Box 645, 7500 AP Enschede
   The Netherlands
   Phone: +31 53-450-5480
   Email: Anthony.Lo@eln.ericsson.se
   (Anthony Lo's portion of the work on this draft was done when he was
   with CWC.)

   Haihong Zheng
   Nokia Research Center
   6000 Connection Drive



Shen, Seah, Lo, Zheng, Greis                                 [Page 22]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   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




                           Table of Contents



   1          Abstract ............................................    1
   2          Introduction ........................................    1
   3          Problem Statement ...................................    2
   3.1        Packet Classification Mismatch ......................    3
   3.2        Handoff Inefficiency ................................    3
   3.3        Refresh and Forwarding of RSVP Messages .............    4
   3.4        Using the Care-of Address to Identify Flows .........    5
   4          Proposed Solutions ..................................    6
   4.1        Flow Transparency Concept ...........................    7
   4.1.1      Mobile Node as Sender ...............................    7
   4.1.2      Mobile Node as Receiver .............................    8
   4.2        Proper Packet Classification ........................    9
   4.2.1      Scenario 1: Mobile Node as Sender ...................    9
   4.2.2      Scenario 2: Mobile Node as Receiver .................    9
   4.3        Refresh and Forwarding of RSVP Messages .............   10
   4.4        Handoff Efficiency ..................................   11
   4.4.1      Scenario 1: Mobile Node as Sender ...................   11
   4.4.2      Scenario 2: Mobile Node as Receiver .................   12
   5          Message Format, Algorithms and Processing Rules .....   13
   5.1        Format of Mobility Object and PATHREQ Message .......   13
   5.2        Nearest Common Router Decision ......................   14
   5.3        Processing Rules for PATHREQ and PATH with
   Mobility Object ................................................   15
   5.3.1      Processing Rule for PATHREQ Message .................   15
   5.3.2      Processing Rule for PATH Message ....................   16
   6          Seamless QoS Provision for Handoffs .................   17
   7          Security Considerations .............................   17
   8          Scalability Considerations ..........................   19



Shen, Seah, Lo, Zheng, Greis                                 [Page 23]


Internet Draft    RSVP and Mobile IPv6 Interoperation      July 13, 2001


   9          Concluding Remarks and Future Work ..................   19
   10         Intellectual Property Considerations ................   20
   11         Bibliography ........................................   20
   12         Authors' addresses ..................................   22















































Shen, Seah, Lo, Zheng, Greis                                 [Page 24]