Internet DRAFT - draft-fhns-rsvp-support-in-mipv6


Internet Engineering Task Force                  Mobile IP Working Group
INTERNET-DRAFT                                         George Fankhauser
draft-fhns-rsvp-support-in-mipv6-00.txt                       ETH Zurich
November 98                                     Stathes Hadjiefthymiades
Expires: May 99                                     University of Athens
                                                            Neda Nikaein
                                                         Lorraine Stacey
                                                     Lucent Technologies

                  RSVP Support for Mobile IP Version 6
                        in Wireless Environments


   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments  of  the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 learn the current status of any Internet-Draft, please  check  the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories  on   (Africa),   (Europe),  (Pacific  Rim),  (US  East Coast), or (US West Coast).

   Distribution of this document is unlimited.


   This draft describes a specific problem encountered when  using  RSVP
   (Resource  Reservation  Protocol)  over  optimised  routes  in  MIPv6
   (Mobile IP Version 6). The address translation in the  MIP's  binding
   cache creates a mismatch between the flow-id of the packets sent from
   correspondent node to mobile node and the flow-id signalled by RSVP.

Fankhauser et al.                                               [Page 1]

Internet Draft           RSVP Support for MIPv6              November 98

   We discuss several solutions to this problem: (1) By  modifying  RSVP
   at  mobile  and correspondent nodes to become aware of MIPv6 address-
   ing, we provide a simple repair that allows RSVP flows  to  be  esta-
   blished  between  the  fixed  network  and  mobiles;  (2a)  By adding
   optional objects to RSVP messages, a performance enhancement is  pro-
   posed  to  make handovers smooth and seamless; (2b) A different tech-
   nique with the same goal is called flow  extension  and  it  provides
   flows  with fixed flow-ids from the correspondent node into the wire-
   less access network at the expense of forwarding traffic  inside  the
   access network, whenever the mobile node moves.

   We conclude that the minimal solution (1) is a requirement  in  order
   to  make  MIPv6 and RSVP interoperable; our favored approach requires
   only minor changes to the correspondent and mobile  node's  RSVP  and
   MIP  specification.   However,  for well performing and uninterrupted
   operation we strongly recommend one of the solutions (2a or 2b)  that
   support  fast  re-establishment  or preservation of resource reserva-
   tions when mobile nodes move.

1 Introduction

   Wireless access to the Internet is becoming more and more popular due
   to  the rapid spread of wireless LANs and other wireless access tech-
   nologies with various speeds  and  ranges  (IRDA-LANs,  IEEE  802.11,
   Wireless  ATM, CDPD, etc.). Devices used include mobile phones, PDAs,
   and notebook computers. Mobile IP could become a common platform  for
   mobile  access (regardless of the underlying access technology), pro-
   viding solutions to the many security, routing, and addressing  prob-
   lems. For a good introduction to Mobile IP see [12].

   More traditional services like telephony, radio and TV  broadcasting,
   and  other  new  Internet  applications  that require more than best-
   effort service are increasingly being carried on the Internet. Mobile
   users  also  want  to  enjoy  multimedia and other realtime services.
   Therefore it is important to design Mobile IP to  interoperate  seam-
   lessly  with  protocols that provide real-time services in the Inter-

   This draft focuses on issues of MIPv6 and RSVP interoperability, more
   precisely  on  the  operation  phase  where optimised routing between
   fixed and mobile hosts is used. We apply our considerations to  MIPv6
   because it uses route optimisation by default. However MIPv4 may also
   use this technique [13].

   Although RSVP is standardised [7] it currently looks like it is going
   to be employed for access networks but not necessarily for end-to-end
   connections through the backbone networks.   Solutions  for  bridging
   RSVP  across  the  backbone  are  under development [6] and are being

Fankhauser et al.                                               [Page 2]

Internet Draft           RSVP Support for MIPv6              November 98

   discussed in the IETF intserv and diffserv working groups. We  assume
   here the usage of RSVP for wireless and fixed access networks and its
   transparent operation over the backbone.

1.1 Terms

   This draft uses the terms as defined in section "Mobile  IPv6  Terms"
   in the Internet Draft "Mobility Support in IPv6"  [9].

1.2 Problem statement

1.2.1 The Unicast Case

   An integral part of MIPv6 is the use of  optimised  paths  between  a
   mobile  node and correspondent nodes. Routing of packets via the Home
   Agent is typically only a transient phase in  MIPv6.  If  the  mobile
   node  has one or more packet streams (flows) controlled via RSVP, the
   PATH and RESV messages will also be transmitted via the direct  route
   between  the  mobile node (MN) and correspondent node (CN). When a MN
   moves, the optimised route between the MN and CN will change.  Furth-
   ermore  the MN's care-of address will also change. Both the route and
   care-of address change impact the operation of RSVP.

   In RSVP, PATH messages are sent end-to-end and RESV messages are sent
   hop-by-hop.  When  the CN is a sender it will transmit a PATH message
   where the address details are based on the MN's home address. However
   the  outer header details will be modified by the MIPv6 binding cache
   to contain the MN's care-of address as the destination address.  Even
   more  importantly,  to  ensure PATH and RESV messages follow the same
   route, the PATH messages contain a RSVP_HOP object which collects the
   address  of  each  outgoing  interface  the  message  traverses.  The
   correspondent node and intermediate routers will each  determine  the
   outgoing interface based on the MN's home address. However the packet
   will actually be routed based on the MN's care-of address. Thus  when
   the PATH message reaches the MN the routing information stored in the
   RSVP_HOP object will not correctly reflect the route followed by  the
   PATH  messages.  Hence RESV messages can not be routed back to the CN
   and therefore RSVP state will not be created between the MN  and  the
   CN.  Additionally,  RESV messages sent back from the MN reference the
   home address of the MN as  the  flow's  destination  in  the  SESSION
   object.  Again, this is not the real flow-id of the flow's data pack-
   ets, it should rather reference the MN's care-of address.

   For the unicast case, the problem of a flow-mismatch occurs when  the
   CN  is  the  sender. When the MN is the sender, the PATH message will
   contain correct routing information when it reaches  the  CN  because
   the MN directly addressed it to the CN. Hence the RESV message can be
   forwarded correctly along the reverse path to the MN. Also, the  RESV

Fankhauser et al.                                               [Page 3]

Internet Draft           RSVP Support for MIPv6              November 98

   message's  SESSION  object  sent by the CN contains correctly its own
   (fixed!) address as the flow's destination. However,  the  PATH  mes-
   sages  also  contain the sender's address (MN) in the SENDER_TEMPLATE
   object. This address would be normally the home address of the MN and
   has to be changed to its care-of address.

   Solutions to these 'change of route' and 'flow-mismatch' problems are
   described  in  this  Internet  Draft. Another important issue is that
   when the MN moves to a new subnetwork its care-of address changes. In
   standard  RSVP  state  information is based on the MN's home address.
   However the data packets  this  state  needs  to  apply  to  will  be
   addressed  with  the MN's care-of address. Hence there is an issue of
   matching RSVP flow state with the data packets belonging to that flow
   at intermediate routers.

   Yet another difficulty with MIPv6 is its  applicability  to  wireless
   environments  where  the MN moves to new subnetworks in real time. In
   wireless environments the speed of re-routing is  of  major  concern.
   The  objectives  are to minimise the loss of packets, and restore the
   end-to-end RSVP state as quickly as possible.

1.2.2 The Multicast Case

   For the multicast case, there are two  options  for  MNs  to  receive
   data.  The first option is via its Home Agent. In this case the HA is
   also a multicast router. The HA tunnels the multicast packets to  the
   MN.  The  second  option is for the MN to join its groups directly in
   its foreign network. This option allows the MN to receive the  multi-
   cast  packets  directly  without  passing by its HA. Since this draft
   considers the problem of using RSVP over optimised routes  in  MIPv6,
   only the second option is studied here.

   Let's consider the case where the CN  sends  multicast  data  and  at
   least one of the receiver's is a MN. An RSVP session is identified by
   the triple !<!destination address, protocol id and optionally  desti-
   nation  port!>!. The destination address of a multicast group remains
   fixed regardless of the mobility of its receivers.  In  other  words,
   the  MN's exact address and its mobility have no impact on the multi-
   cast group address. Therefore, an MN making  a  handover  to  another
   network  can  be considered as a new node joining the group. That is,
   each time the MN moves to a new subnetwork it must leave and  re-join
   the multicast group. The process of leaving and re-joining the multi-
   cast groups can be done as part of the handover procedure.

   Now, we consider the case where the MN sends multicast data. IP  uni-
   cast  routing  protocols  depend  only on the IP destination address.
   Some multicast routing protocols such as DVMRP [18]  and  MOSPF  [10]
   build  a multicast tree per source. These routing protocols construct

Fankhauser et al.                                               [Page 4]

Internet Draft           RSVP Support for MIPv6              November 98

   the multicast tree depending on the source address  as  well  as  the
   destination  address.   Other  algorithms like CBT [5] build a single
   shared tree per group. These protocols use only  the  IP  destination
   address for packet forwarding.

   Using the home address as the IP source address of the datagram leads
   the  routers executing DVMRP or MOSPF to expect the datagram from the
   link used to reach the MN's home address. Therefore,  sending  multi-
   cast  traffic in a foreign network using the MN's home address as the
   IP source address means that these routers receive  the  traffic  via
   unexpected  links.  DVMRP drops such datagrams because it expects the
   packet to arrive to the router on the shortest path from  the  router
   to  the  MN's  home  address.  MOSPF forwards the traffic based on an
   incorrect information. In both cases, some destinations  may  not  be
   reached.  In order to overcome such routing problems, we must use the
   MN's care-of-address in the IP source address.

   RSVP is not aware of mobility. When building a PATH message,  the  IP
   source  address of the filter specification is filled by the the MN's
   home address. However the IP source address of the  outer  IP  header
   must  be  modified to the MN's care-of-address because of the routing
   problems described above.  Therefore, there is a mismatch between the
   information  in the RSVP message and in the outer IP header. The PATH
   message can be routed correctly thanks to the care-of-address in  the
   outer  IP  header.  The problem is RSVP_HOP object's last-hop-address
   field which has to be changed at the MN's RSVP daemon because it  has
   been calculated based on the MN's home address and the group destina-
   tion address.

1.2.3 Summary

   Summarising, the following issues have to be addressed:

        o Most importantly, we need a working solution, i.e., MIPv6  and
         RSVP  need to be integrated. MIP provides transport layer tran-
         sparency but does not work with protocols like RSVP. Since this
         requires  changes  to either MIP or RSVP, we would like to keep
         them as minimal as possible. We also favor a  modular  solution
         that  allows  for  incremental  deployment  (e.g., hosts first,
         routers later).

        o Multicast aspects of all  possible  solutions  and  extensions
         (even if optional) have to be considered.

        o Performance aspects for wireless operation and  their  respec-
         tive applications (e.g. mobile IP phones) are an important fac-
         tor when evaluating the pros and cons of  a  mobile  integrated
         services solution.

Fankhauser et al.                                               [Page 5]

Internet Draft           RSVP Support for MIPv6              November 98

2 Possible Solutions

   This section describes solutions and enhancements  that  resolve  the
   flow-id  mismatch  between RSVP messages and the flow's data packets.
   The first solution provides a basic fix and  some  optional  enhance-
   ments  to  restore reservations in a quick and efficient manner.  The
   second proposal builds partially on top of  the  first  and  provides
   advantages  to  fast moving terminals inside wireless access networks
   by extending flows to new routers  while  keeping  the  RSVP  session
   through  the backbone unchanged. This approach makes use of RSVP tun-

2.1 Mobility Enhanced RSVP

2.1.1 Changing End-Nodes

   A possible solution to the problem of correctly routing RSVP messages
   between  CNs and MNs is to modify the RSVP daemon at the CN and MN to
   operate on the MN's care-of address instead of its home address.  The
   RSVP  daemons could learn the care-of address by consulting its MIPv6
   binding cache.  This means that RSVP state would be created based  on
   the care-of address, and thus the path the traffic actually follows.

   There are two ways that the care-of  address  can  be  obtained.  One
   option is to modify MIP to provide an interface [1] that  allows  the
   RSVP  module  to  look  up  the  care-of address of a mobile node. An
   alternative is to modify MIP at the CN and MN only. In this case  the
   MIP  module  needs  to become RSVP aware and swap the home address in
   the PATH and RESV messages SESSION  objects  with  the  mobile  nodes
   care-of address (among other fields, see Section A for details).

   We recommend here the implementation of a clean  interface  in  MIPv6
   which  must  be  used  by the RSVP daemon. As we will see in the next
   subsection, this interface may also be extended for  triggering  PATH
   messages when mobiles change their location.

2.1.2 Changing Intermediate Routers (Alternative Approach)

   An alternative, but similar approach means  RSVP  implementations  at
   routers MUST be changed but changes are not needed at CNs[2] and MNs.
  [1] It is current practice of MIPv4  implementors  to
use  the  routing  table  to store the MN's location at
home agents [12]. If MIPv6 would use the same technique
consistently   ,   a   simple   routing  socket  lookup
(PF_ROUTE) would reveal the care-of  address  when  fed
with the home address of the MN.

Fankhauser et al.                                               [Page 6]

Internet Draft           RSVP Support for MIPv6              November 98

   In this solution outer header address information is passed up to the
   RSVP  module  at  each router (outer header means the IP header tran-
   sporting the PATH or RESV message, i.e., the  whole  packet  and  not
   only  the  payload  is forwarded to the RSVP daemon). This allows the
   RSVP daemon in each intermediate router to learn the mapping  between
   the  mobile node's home address and current care-of address. The RSVP
   daemon should then base its calculation of the RSVP-HOP  and  filters
   on the care-of address. Given the router RSVP daemon maintains a map-
   ping between the home and care-of address when  the  care-of  address
   changes the router will still recognise the RSVP messages and traffic
   as belonging to the same reservation.

2.1.3 Evaluation of the two Alternatives

   Our preferred solution, however,  is  the  first  approach.  This  is
   because  it requires less changes. It requires to make a small change
   at CNs and MNs only, to enable the RSVP  daemon  to  learn  the  MN's
   care-of  address.   This solution can be optimised by adding new RSVP
   objects. However these are not essential to  the  operation  of  RSVP
   with MIPv6. In contrast the second, alternative solution requires all
   routers to change their RSVP implementations.

2.1.4 Performance Enhancements

   One minor disadvantage of this approach (using either  implementation
   alternative)  is  that  when the mobile node moves and thus obtains a
   new care-of address, all of the intermediate routers will assume this
   is  a  new RSVP reservation flow. Hence there may be situations where
   the new reservation is denied because the old  reservation  is  still
   active and blocks resources. This problem could be overcome by intro-
   ducing a new RSVP object to the RSVP messages the MN sends (that  is,
   if  the  MN  is a receiver, it will place the RSVP object in the RESV
   message). This would allow  intermediate  routers  to  recognise  the
   reservation  is the same even though the care-of address has changed.
   A key point to note is that if some or even all intermediate  routers
   do  not recognise this RSVP object this solution will still work.  At
   those routers that don't understand the RSVP object  the  RSVP  state
   with  the  new  care-of  address will be treated as a new independent
   flow and the previously reserved flow expires later.

   Note if the home address was kept as the destination address, and the
   care-of address was stored in the new RSVP object this solution would
   require all intermediate routers to understand the  new  RSVP  object
  [2] If  a  CN  as  a  flow's sender exercises traffic
control, it has, of course, to apply the  same  changes
as intermediate routers.

Fankhauser et al.                                               [Page 7]

Internet Draft           RSVP Support for MIPv6              November 98

   instead of just changing the CNs and  MNs  and  treat  the  new  RSVP
   object as an option.

   Another concern is the time required to modify the RSVP state so that
   traffic flows along the optimal path to the MN's new care-of address.
   In standard RSVP operation PATH and  RESV  messages  are  transmitted
   periodically. Hence there can be a significant delay between the MN's
   care of address changing and the next PATH message being  sent.  This
   extra  delay can be avoided by having the arrival of a binding update
   message at the CN, trigger the transmission of a PATH message. Again,
   an  interface  between  MIP  and  RSVP daemon should be used for this

2.1.5 Use of IPv6 Flow Label

   One could argue that the mechanism described above is  not  required,
   since  IPv6  flow  labels (in conjunction with the source IP address)
   uniquely identify the traffic  flow.  If  non-zero  flow  labels  are
   employed  it is still possible to identify the traffic flow. However,
   this won't solve the routing problem of PATH messages. Moreover  IPv6
   flow labels are optional and hence they can often be zero. If this is
   the case the flow-id mismatch problem still exists.  Furthermore,  if
   the  flow-id is created by hashing on the destination address, it may
   also change when the care-of address changes.

2.1.6 Required or Optional Changes

   To summarise the key components of this solution are:

        o At correspondent nodes

         -RSVP daemon can obtain the mobile node  care-of  address  from
          the binding cache

         -RSVP daemon places the mobile node care-of address as the PATH
          message's SESSION object's destination address

        o At the MIP information aware intermediate router

         -On receipt of a PATH message store  the  mobile  node  care-of
          address  (standard  RSVP operation) and home address (optional
          for mobility support) in the RSVP daemons flow table.

         -Create a classifier entry based on the mobile  node's  care-of
          address (standard RSVP operation).

         -When a PATH message arrives with the same home address  but  a
          different  care-of  address  update  the flow state and filter

Fankhauser et al.                                               [Page 8]

Internet Draft           RSVP Support for MIPv6              November 98

          information with the new care-of address (optional for  mobil-
          ity support).

        o At standard intermediate routers

         -On receipt of a PATH message store the mobile  node's  care-of
          address in the flow state information.

         -Create a classifier entry based on the mobile  node's  care-of

         -On receipt of a PATH message with a different care-of  address
          for  the  mobile  node  create  new flow state information and

         -Remove the old flow state information on receipt of a PATHTear
          or when it times out.

        o At mobile nodes

         -Since the MN is reachable under its care-of address, PATH mes-
          sages  that  arrive  with  the  care-of address as the SESSION
          object's destination address should not disturb  regular  RSVP

         -When an MN sends RESV messages the SESSION  object  must  also
          contain the care-of address in order to correctly identify the
          flow on the optimised route.

         -RSVP daemon places the mobile node's home  address  in  a  new
          RESV  MIP  RSVP  object  (optional) for efficient recycling of

   The solution described above means RSVP implementations  at  CNs  and
   MNs  MUST  be  changed  and RSVP implementations at routers SHOULD be

2.1.7 Multicast Support

   The same approach can be used to resolve  the  problem  of  multicast
   reservation when an MN is a sender. In this case, we can also use the
   care-of-address   in   the   IP   source   address   field   of   the
   SENDER_TEMPLATE.   Therefore, the RSVP_HOP object of the PATH message
   is calculated correctly. However, this  can  cause  the  intermediate
   routers  to  consider the MN as a different source. In order to over-
   come this problem, we use the same approach as  described  above.  We
   add  a  new  RSVP  object to the PATH message which contains the MN's
   home address.  To summarise, we propose the following solution:

Fankhauser et al.                                               [Page 9]

Internet Draft           RSVP Support for MIPv6              November 98

        o At mobile nodes

         -When an MN sends PATH messages the SENDER_TEMPLATE object must
          contain the care-of address.

         -RSVP daemon places the mobile node's home  address  in  a  new
          PATH MIP RSVP object.

        o At the MIP information aware intermediate router

         -On receipt of a PATH message store  the  mobile  node  care-of
          address  (standard  RSVP operation) and home address (optional
          for mobility support) in the RSVP daemons flow table.

         -Create a filter spec entry based on the mobile node's  care-of
          address (standard RSVP operation).

         -When a PATH message arrives with the same home address  but  a
          different  care-of  address  update  the flow state and filter
          information with the new care-of address (optional for  mobil-
          ity support).

        o At standard intermediate routers

         -On receipt of a PATH message store the mobile  node's  care-of
          address in the flow state information.

         -Create a filter spec entry based on the mobile node's  care-of

         -On receipt of a PATH message with a different care-of  address
          for  the  mobile  node  create  new flow state information and

         -Remove the old filter spec information when it times out.

        o At correspondent nodes

         -The CN is aware of the MN's care-of address  via  the  binding
          cache. RSVP operates regularly by sending the RESV message.

2.2 Flow Extension

   This section describes an  alternative  approach  for  the  efficient
   operation of RSVP on top of MIPv6. This approach proposes an alterna-
   tive to the use of new RSVP objects for the fast update of end-to-end
   RSVP  connections. It mainly refers to the time periods following the
   occurrence of active  terminal  relocations  in  the  network  (i.e.,

Fankhauser et al.                                              [Page 10]

Internet Draft           RSVP Support for MIPv6              November 98

   handovers).  It  is also assumed that, prior to terminal relocations,
   RSVP flows have been established between the CN and the MN using  the
   basic approach discussed in Section 2.1 (the MN is assumed to be in a
   foreign subnetwork).

   When an MN attaches to a new subnetwork and acquires a new IP care-of
   address,  the  MIP-capable  router  in this subnetwork intercepts and
   suppresses the MIPv6 binding update message sent to the  CN  (we  use
   the  term  MIP-router  here for a router serving wireless access net-
   works and performing the flow extension tasks). This  causes  the  CN
   not  to update its Binding Cache. This strategy is not applied to the
   Binding Update sent to the former MIP-router. This information can be
   used in rerouting best effort traffic destined to the old location of
   the MN, to its current location (through the  use  of  an  IP  tunnel
   between  former  and  current  MIP router). The MN is then capable of
   receiving datagrams destined to its current IP address as well as the
   previous IP address.  For best effort traffic destined to the MN, the
   previous IP address should be used. This packet forwarding  technique
   is an enhancement to support loss-less handovers [8].

   Prior to or during the relocation of the terminal, the old MIP-router
   also extends the existing RSVP flows to the new MIP-router. This task
   is performed by a mobility management (MM)  entity  operating  within
   the  router.  The  extension of downlink (CN  --->  MN) flows is per-
   formed by the old MIP-router while the uplink flows (MN   --->    CN)
   are  handled  by the new MIP router. For this last step, the new MIP-
   router needs to receive the characteristics of  existing  flows  from
   the  old  router.  For  this task, specialised signaling between MIP-
   routers (MM entities in particular) is introduced (it is assumed that
   such  signaling  is treated as best effort traffic in the access net-
   work). The elongation of flows by the old MIP router to  the  current
   avoids the invalidation of existing flows caused by changes in the IP
   addresses of connection endpoints.  [3]

   The proposed elongation of the CN-MN path causes  the  route  of  the
   communication  to  be  sub-optimal  and,  consequently, imposes addi-
   tional, but relatively small, time delays. It was shown that consecu-
   tive elongations (leading to increased sub-optimality) will be needed
   rarely, as the number of inter-subnet MN relocations (i.e., handovers
   to subnetworks controlled by different MIP-routers; and hence changes
   in addresses) is very small during the lifetime of IP connections  in
  [3] If Guaranteed Service is employed  as  a  service
model  the  end-to-end delay calculation may have to be
performed across the entire path between the CN and  MN
to  take  into  account extra nodes and links that have
been added to the communication path.

Fankhauser et al.                                              [Page 11]

Internet Draft           RSVP Support for MIPv6              November 98

   a CPN environment [17]. Most relocations will result  in  attachments
   of  the  MN to base stations (radio transceivers) in the same subnet-
   work (also termed intra-subnet handovers). Such mobility  events  can
   be  handled  at the local addressing-level without affecting the com-
   munication path beyond the router, i.e. the care-of address of the MN
   remains  the  same. This elongation of data paths has been adopted in
   Wireless ATM technology for the handling of connections (VCs)  during
   the  occurrence  of  handovers.  Relevant information can be found in
   [2], [3], [8].

2.2.1 Required or Optional Changes

   Due to the flow extension approach modifications are confined to  the
   end-nodes  and  mobile/wireless  access network routers. Intermediate
   routers along the transmission path do not need to be changed.

        o At correspondent nodes

         -The same basic modifications as described in Section  2.1  are

        o At standard intermediate routers

         -No changes needed here (of course, one could think of a combi-
          nation  of  the  two  performance enhancment approaches, i.e.,
          flow extension is used for high-frequent  movements  and  path
          triggers  and RSVP objects are used, e.g. when roaming between
          provider networks).

        o At wireless access network routers (MIP-routers)

         -Communicating the IP address of the new MIP-router to the  old

         -Transmitting the existing RSVP flow characteristics (flowspec)
          to the new MIP-router from the old MIP-router. To elongate the
          RSVP state from the  old  MIP-router  to  the  new  MIP-router
          (i.e., extend the flow) an RSVP tunnel could be used.

         -Control and suppression of binding  update  transmission  from
          MNs.  If  the design alternative mentioned below is used, this
          point becomes obsolete.

        o At mobile nodes

         -The same basic modifications as described in Section  2.1  are

Fankhauser et al.                                              [Page 12]

Internet Draft           RSVP Support for MIPv6              November 98

         -However, since the flow will retain its flow-id  over  a  long
          time  period, binding updates do not need to trigger RESV mes-
          sages, nor do we need to insert special RSVP objects.

         -Design alternative: It is also possible to suppress the  bind-
          ing  update  messages at the MN without considerable modifica-
          tions to its MIPv6 module. Such  approach  improves  bandwidth
          efficiency  at  the radio interface and reduces the complexity
          of MIP routers. One additional advantage of  this  alternative
          is  that  it does not cause disruptions in IP communication if
          the Binding Update message is included (as Destination  Option
          header)  in  IP packets having, besides headers, standard pay-
          load data such as TCP/UDP. Disabling the transmission of Bind-
          ing  Update  messages  at  the MN is also adopted in the MRSVP
          approach discussed in Section 3.2.

2.2.2 Using RSVP Tunnels for Flow Extension

   Lastly, we are considering how the extension of RSVP flows  could  be
   accomplished  in  light  of  existing protocol specifications, (i.e.,
   RSVP, MIPv6, IP encapsulation). RSVP operation over IP  tunnels  [16]
   provides  a  good basis for the implementation of the proposed scheme
   (see also Section 3.3). The old MIP-router uses  regular  IP  tunnels
   for  forwarding best effort traffic and RSVP tunnels for handling the
   extension of RSVP flows. The old MIP-router serves as the RSVP tunnel
   entry  point in the downlink direction while the new MIP-router plays
   the role of the tunnel exit point (roles are inverted in uplink  com-
   munication).  The  tunnel  session is a separate RSVP session between
   the involved routers. Its characteristics are dictated by the charac-
   teristics of the flows that need to be extended. The original session
   (CN  --->  MN / MIP-router) views the tunnel as a  single  communica-
   tion  link.  The PATH and RESV messages of the end-to-end session are
   encapsulated at one tunnel end-point and decapsulated at  the  other.
   The  end-to-end  session and the tunnel session are associated at the
   entry/exit points of the tunnel. The tunnel may encompass one or more
   RSVP-capable nodes.

   The overall scheme is based on the assumption that the new MIP-router
   is aware of the existence of RSVP flows and thus, suppresses only the
   binding update messages for active RSVP flows When the entire set  of
   RSVP  flows  is terminated, the new MIP-router allows the propagation
   of the binding update signal to the fixed network. This restores  the
   optimal communication between the MN and the CN regarding best effort
   traffic. (We might also propose to do this  whenever  flow  extension
   has become too long or too slow).

2.2.3 Multicast Support

Fankhauser et al.                                              [Page 13]

Internet Draft           RSVP Support for MIPv6              November 98

   As we said before, if the MN, which is the receiver of the  multicast
   data,  changes  its  subnetwork, it must rejoin its groups in the new
   subnet. Now, if the new subnetwork already has members  of  the  MN's
   groups  with  the  same  reservations,  the  MN  can receive the data
   without any delay. If this is not the case, the MN can  receive  data
   from  its  old MIP-router by using an RSVP tunnel. The new MIP-router
   knows about the MN's group list and also about the presence of groups
   and  their reservation style in its local network. Therefore, instead
   of trying to graft a path to the multicast tree, the  new  MIP-router
   asks  the  old  MIP-router  to forward the traffic destinated to this
   group via an RSVP tunnel. The same thing happens,  if  the  new  MIP-
   router  has a member of the group but not with the specified reserva-
   tion style.

   Now if the MN is the sender of the multicast traffic  (uplink  direc-
   tion), we always pass by the RSVP tunnel to reach the old MIP-router.

3 Previous Work

   This section summarises selected recent  research  on  providing  QoS
   support  in  mobile  and  wireless  networks and serves as a starting
   point for further reading.

3.1 Mobile IP Version 6

   The description MIPv6 [9] encompasses a streamlined version of Mobile
   IP  that makes use of new IPv6 features that help to improve mobility
   support. Most notable, foreign agents could be replaced by  stateless
   address  autoconfiguration and neighbor discovery. As stated earlier,
   optimised routes between CN and  MN  are  the  default  operation  in
   MIPv6.  They  can  be  implemented  properly  by  using  IPv6 routing

3.2 Mobile RSVP (MRSVP)

   MRSVP has been proposed in [15],  as  an  extension  to  conventional
   RSVP,  for  the  provision  of QoS guarantees to MNs independently of
   their movement throughout the access network. MRSVP  suggests  making
   the  required  resource reservations in all the locations expected to
   be visited by the MN (mobility  specification).  MRSVP  supports  two
   service classes. The first one, called Mobility Independent, provides
   the agreed service in every location visited by the MN.  The  second,
   called  Mobility  Dependent,  provides  a  high  probability,  but no
   guarantee, to receive the agreed service in the locations the MN  may

   MRSVP supports two different reservation styles. The MN makes  active
   reservations  from  its  present  location  towards all the CNs it is

Fankhauser et al.                                              [Page 14]

Internet Draft           RSVP Support for MIPv6              November 98

   communicating with. It also triggers  the  establishment  of  passive
   reservations  from  all the locations it may visit. Such reservations
   are made by proxy agents (remote), operating on the behalf of the  MN
   which is not present at their subnetwork. As passive reservations are
   not used by the MN (data is not flowing through  them)  they  may  be
   used  temporarily  by  other  connections  of  the Mobility Dependent
   class. When the MN roams, passive reservations are switched to active
   and vice versa.

   The MRSVP scheme provides mobility support for both unicast and  mul-
   ticast traffic.

3.3 Supporting RSVP/MIP Integration with RSVP-Tunnels

   RSVP tunnels [16] provide signalling of  RSVP  messages  in  tunnels.
   Normally,  RSVP messages in tunnels are not visible to routers due to
   encapsulation. This problem is similar to the MIP flow-mismatch prob-
   lem, but with the difference, that in MIP the RSVP daemon is provided
   with the wrong information and in tunnels, the encapsulated RSVP mes-
   sages  feature  the wrong protocol id (next header field) which makes
   them invisible.

   The proposed solution for RSVP tunnels is to  establish  nested  RSVP
   sessions  between  the  tunnel's entry and exit points, i.e. new PATH
   and RESV messages (without the encapsulation headers!) are being sent
   between entry and exit point. This solution also focuses on modifica-
   tions at the entry/exit points and tries  to  avoid  changes  to  the
   intermediate routers along the tunnel path.

   RSVP tunnels were already proposed to  support  RSVP  connections  in
   MIPv4  as  a replacement for the regular IP tunnel between HA and MN.
   They could serve also as a basis for the various  forwarding  connec-
   tions needed in our flow extension approach (Section 2.2).

   RSVP tunnels could also be employed in our RSVP object approach (Sec-
   tion  2.1)  for  the  transient phase where the MN has moved to a new
   care-of address and the old router is forwarding traffic to  the  new
   router,  but the end-to-end state hasn't been adjusted yet. Thus com-
   monality with MIPv4 - RSVP integration in terms of the  use  of  RSVP
   tunneling is true for both approaches.

3.4 IPSOFACTO: IP Multicast over Wireless ATM

   [1] describes how IP multicast can be natively supported in  wireless
   networks  over ipsofacto. To differentiate different types of traffic
   VCs are classified as unicast, multicast  and  broadcast  VCs.  Small
   extensions  to  the  IGMP protocol are proposed. In addition, a cell-
   level error recovery scheme at the data link layer  is  described  to

Fankhauser et al.                                              [Page 15]

Internet Draft           RSVP Support for MIPv6              November 98

   enhance the packet-level throughput of the transport layer.

3.5 Designing a Wireless Broadband IP System with QoS Guarantees

   [4] describes a wireless broadband IP system where a solution such as
   those  described  in  this  Internet Draft is required.  This system,
   specified within the ACTS Magic WAND project is a native IP  wireless
   access  system  providing 20Mbits/s, 5GHz radio access to an IP back-
   bone. The objective of this system is to allow full  exploitation  of
   real-time  IP  applications  in  a  mobile  environment.  This system
   comprises a mobile node, access point (implementing all radio  depen-
   dent control functionality) and a mobility enhanced IPv6 router.

   This work is also described in [14]. In this report, in  addition  to
   the  overall  design of the wireless broadband IP system, some of the
   MIP/RSVP  integration  problems  are  described  in  greater  detail,
   including diagrams and message sequence charts.

3.6 Mobility Management in an IP-based Wireless ATM Network

   In [8], Hadjiefthymiades et al. studied mobility management issues in
   a WATM architecture exclusively intended and optimised for IP traffic
   support. The considered system is  a  variation  of  the  Magic  WAND
   architecture.  It  is  capable  of  supporting  IP  applications with
   specific QoS requirements in light of terminal mobility. The proposed
   architecture  is  based  on specifications/standards like RSVP, MIPv6
   and IFMP.

   The architecture assumes two types  of  terminal  relocations  (hand-
   overs).   Handovers confined to the same MIP router are treated at L2
   (ATM in the case of a WATM system). Handovers involving more than one
   MIP  routers (intersubnet handovers), necessitate the use of resource
   and mobility management schemes. The paper  identifies  the  problems
   encountered   in  MIP-RSVP  interaction  and  presents  some  initial
   thoughts for their resolution.

3.7 Wireless Multicasting in an IP Environment

   [11] describes a framework for multicast communication in a  wireless
   IP  environment.  It presents a group membership management mechanism
   optimised for wireless networks. It also studies the effect of termi-
   nal  mobility  on  the  multicast  communications  in  a  mobile IPv6

4 Conclusion

   As stated in Section 2.1 the  minimal  solution  to  the  problem  of
   MIP/RSVP integration requires the modification and the interfacing of

Fankhauser et al.                                              [Page 16]

Internet Draft           RSVP Support for MIPv6              November 98

   the RSVP daemon and MIP's binding cache at CNs and MNs. This solution
   requires  less changes when compared to an approach that tries to fix
   flow-ids at intermediate routers. It is important to note that inter-
   facing  MIP  and  RSVP implementations requires changes to both stan-
   dards. For proper multicast operation the same changes as for unicast
   are sufficient.

   For advanced solutions, where performance  and  smooth  handovers  in
   wireless environments are considered, we have proposed two solutions:

        1.   Triggers/Objects:  PATH messages are triggered  on  binding
             updates  and  home  address objects in RESV messages enable
             intermediate routers to recognise connections and to  reuse
             resources   even  when  the  care-of  address  (destination
             address of flow) changes.

        2.   Flow  Extension:   This  approach  keeps  the   reservation
             unchanged until it reaches the wireless access network.

   A qualitative comparison of the two approaches  shows  the  following

                           Triggers/Objects          Flow extension
    Changes to CN          yes (needed for          yes (needed for
                          minimal solution)        minimal solution)

    Changes to              yes (RSVP MIP                  no
    intermediate           object extension
    routers                  and reuse of
                          flow's resources)
    Changes to            no (forwarding of           yes (binding
    MIP-router             late packets is        update interception,
                         also an option here)       flow forwarding)

    Changes to MN                yes                      yes
    Changes to HA                 no                       no

    Supports                     yes                      yes
    Bandwidth                    yes                 yes (we assume
    efficient                                     overprovisioning in)
                                                  the access network)

    End-to-end delay     always shortest path           slightly
                        (but re-establishment         incr. delay
                             of resources
                        requires a round-trip)

Fankhauser et al.                                              [Page 17]

Internet Draft           RSVP Support for MIPv6              November 98

    Lossless HO          yes (with forwarding             yes
                           of late packets)

    HO delay                  roundtrip                  faster
    Impl.                      moderate                  higher


   A quantitative evaluation of  these  advanced  solutions  depends  on
   traffic  characteristics,  network topologies, etc. and is subject to
   future investigations.

   Although a minimalist solution would enable  the  operation  of  RSVP
   over MIP, we strongly recommend one of the solutions (2) that support
   fast re-establishment or preservation of resource  reservations  when
   mobile nodes move. Only such enhancements can guarantee well perform-
   ing and uninterrupted operation.

   Without  quantitative   evaluation   we   can   just   observe   that
   Triggers/Objects  is  a  quick and low complex solution that might be
   able to provide sufficiently good service, e.g. for mobile IP phones.
   The  flow  extension  approach  is  a little more complex but has the
   advantage of faster deployment. In multi-provider environments, where
   we cannot control the whole path end-to-end, a solution that modifies
   only CNs, access network routers and MNs has a big advantage.

   We should also mention, that a combination of the two enhancements is
   possible  and  useful  for  large wireless networks, roaming services

   Furthermore, the two performance enhancement approaches described  in
   this  draft  could  also  be  applied to the MIPv4 route optimisation
   approach since it is based on the same principles as used  in  MIPv6.
   However,  we  do not provide a detailed description of this topic and
   more study of the applicability of this draft to MIPv4 is required.


   We would like to thank the following people for commenting  and  dis-
   cussing  early  versions  of  this  draft: Juha Ala-Laurila, Sarantis
   Paskalis, and Jukka Seppala. Part of this work has been performed  in
   the  framework  of  the  project  ACTS AC085 The Magic WAND, which is
   partly funded by the European Community and the Swiss BBW  (Bundesamt
   fur  Bildung und Wissenschaft). The authors would like to acknowledge
   the contributions of their colleagues from Ascom Systec AG, Compagnie
   IBM France, IBM Zurich Research Laboratory, Institut Eurecom, France,

Fankhauser et al.                                              [Page 18]

Internet Draft           RSVP Support for MIPv6              November 98

   INTRACOM Hellenic Telecommunications, Lucent Technologies WCND, Nokia
   Mobile  Phones  and  Nokia  Research Center, Robert BOSCH GmbH, Swiss
   Federal Institute of Technology (ETH) Zurich, Tampere  University  of
   Technology, University of Athens, University of Lancaster, University
   of Ulm, and VTT Technical Research Center Finland.

5 Bibliography

   [1] A. Acharya, R. Dighe, and F. Ansari.  IP Switching over Fast  ATM
   Cell  Transport  (IPSOFACTO):  IP  Multicast  over  Wireless ATM.  In
   Proceedings of IEEE ICUPC '98 , October 1998.

   [2] A. Acharya, J. Lin, B. Rajagopalan, and D. Raychaydhuri.   Mobil-
   ity  Management  in Wireless ATM Networks.  IEEE Communications Maga-
   zine , 35(11):100--109, November 1997.

   [3] P. Agrawal, E. Hyden, P. Krzyzanowski, P. Misthra, M. Srivastava,
   and  J.  Trotter.   SWAN: A Mobile Multimedia Wireless Network.  IEEE
   Personal Communications , April 1996.

   [4] Juha Ala-Laurila, Lorraine Stacey, Neda Nikaein, and  Jukka  Sep-
   pala.   Designing a Wireless Broadband IP System with QoS Guarantees.
   In Proceedings of ACTS Mobile Summit '98 , June 1998.

   [5] A. Ballardie.  Core Based Trees (CBT version 2) Multicast Routing
   - Protocol Specification.  RFC 2189, September 1997.

   [6] S. Berson and S. Vincent.   Aggregation  of  Internet  Integrated
   Services  State.   In Proceedings of IWQoS 98 , Napa Valley, USA, May

   [7] R. Braden,  L.  Zhang,  S.  Berson,  S.  Herzog,  and  S.  Jamin.
   Resource  Reservation Protocol (RSVP) - Version 1 Functional Specifi-
   cation.  RFC 2205, September 1997.

   [8] Stathes Hadjiefthymiades, Sarantis Paskalis,  George  Fankhauser,
   and Lazaros Merakos.  Mobility Management in an IP-based Wireless ATM
   Network.  In Proceedings of ACTS Mobile Summit '98 , June 1998.

   [9] David B. Johnson and Charles Perkins.  Mobility Support in  IPv6.
   Internet  Draft,  draft-ietf-mobileip-ipv6-06.txt,  work in progress,
   August 1998.

   [10] J. Moy.  Multicast Extensions to OSPF.  RFC 1584, March 1994.

   [11] N. Nikaein and  C.  Bonnet.   Wireless  Multicasting  in  an  IP
   Environment.   In Proceedings 5th Intl. Workshop on Mobile Multimedia
   Communication MoMuc '98 , October 1998.

Fankhauser et al.                                              [Page 19]

Internet Draft           RSVP Support for MIPv6              November 98

   [12] C. Perkins.  Mobile Networking Through Mobile IP.  IEEE Internet
   Computing , January 1998.

   [13] Charles Perkins and David B.  Johnson.   Route  Optimization  in
   Mobile IP.  Internet Draft, draft-ietf-mobileip-optim-07.txt, work in
   progress, August 1998.

   [14]  Lorraine  Stacey,  Juha  Ala-Laurila,  Jouni  Mikkonen,   Jukka
   Seppala,  Stathes  Hadjiefthymiades, Neda Nikaein, George Fankhauser,
   and Sarantis Paskalis.  ACTS Project AC085 "Magic WAND",  Deliverable
   1D6            "IP            Over           Wireless           ATM",, August 1998.

   [15] A. Talukdar, B. Badrinath, and A. Acharya.   MRSVP:  A  Resource
   Reservation  Protocol  for an Integrated Services Packet Network with
   Mobile Hosts.  Technical report DCS-TR-337, Rutgers University, 1997.

   [16] A. Terzis, J. Krawczyk,  J.  Wroclawski,  and  L.  Zhang.   RSVP
   Operation  Over  IP Tunnels.  Internet Draft, draft-ietf-rsvp-tunnel-
   03.txt, work in progress, August 1998.

   [17] M. Veeraraghavan and G. Dommety.  Mobile Location Management  in
   ATM Networks.  IEEE JSAC , October 1997.

   [18] D. Waitzman, C. Patridge, and S. Deering.  Distance Vector  Mul-
   ticast Routing Protocol.  RFC 1075, November 1988.

A List of Modified RSVP Objects

A.1 Minimal Changes to RSVP Objects for Correct MIP/RSVP Operation

        o SESSION objects: All of these (i.e. in PATH and RESV  messages
         need to make reference to the MN's care-of address (flow direc-
         tion CN  --->  MN). Flows to CNs keep CNs' address  as  a  flow

        o RSVP_HOP objects: In PATH messages sent to  MNs  must  contain
         the care-of address of the MN.

        o FILTER_SPEC objects: Sender addresses  in  filter  specs  ori-
         ginated  from  MN's  in  RESV  messages  must  contain  care-of

        o SENDER_TEMPLATE objects: In PATH messages sent to the CN  must
         contain the sender's (MN) care-of address.

A.2 Changes to RSVP Objects with Triggers/Objects

Fankhauser et al.                                              [Page 20]

Internet Draft           RSVP Support for MIPv6              November 98

        o MIP_HOME_ADDR objects: Needed in RESV messages  sent  to  CNs.
         They  could be optionally replaced by constant IPv6 flow labels
         for flow recognition.

   Authors' addresses

   George Fankhauser
   Computer Engineering and Networks Laboratory
   ETH Zurich
   ETH Zentrum
   CH-8092 Zurich

   Stathes Hadjiefthymiades
   Communication Networks Laboratory
   Department of Informatics
   University of Athens
   TYPA Building, Panepistimioupolis,
   Ilisia, Athens 15784

   Neda Nikaein
   Mobile Communication Department
   Institut Eurecom
   2229, Route des Crete
   B.P. 193
   F-06904 Sophia Antipolis

Fankhauser et al.                                              [Page 21]

Internet Draft           RSVP Support for MIPv6              November 98

   Lorraine Stacey
   Lucent Technologies
   Sigma, Windmill Hill Business Park,
   Swindon, Wiltshire SN5 7EP
   United Kingdom

Fankhauser et al.                                              [Page 22]