[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT      MIP/RSVP Analysis     Michael Thomas
                                          Cisco Systems
                                          Oct 28, 2002






              Analysis of Mobile IP and RSVP Interactions

                 draft-thomas-nsis-rsvp-analysis-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 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/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract

   IP Mobility along with RSVP makes my head hurt.  Trying to guess the
   benefits (if any) of a proposed context transfer protocol is even
   more difficult to judge. This draft tries to make sense of some
   subset of the possible permutations in a possibly vain attempt have
   an overview of the problem space.








M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 1]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


1. Introduction

   The intersection of Mobile IP with RSVP is not well understood. This
   draft attempts to bring forth issues with their interaction, as well
   as diagram how a naive RSVP and MIP hosts would likely interact,
   assuming they implemented the protocols correctly. This version of
   the draft does not intend to be comprehensive as the vagueries of
   even simple cases raise plenty of questions. This draft does,
   however, try to speculate what the potential effects and/or
   advantages of Fast Mobility as well as the potential effects of a
   hypothetical context transfer protocol being worked on in the NSIS
   working group.


1.1 Terminology



   MN    mobile node

   AR1   old access router

   AR2   new access router

   PDP   policy decision point

   AGG   aggregation router; join point of reservations

   CN    correspondent node

   X->Y  means X sending traffic toward Y; ie, X is the source of the
         PATH and Y is the source of RESV's.

   <-|-> change bar implies that the following messages can happen
         simultaneously. It should be noted that these are only sugges-
         tive of the concurrency and in many cases can be drawn dif-
         ferently given message arrival timing.


1.2  Assumptions



1.2.1 Handoff Trigger


   As with all diagrams in this draft, we elide the mechanism by which
   AR1 decided that the handoff to AR2 was necessary.



M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 2]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


1.2.2 Reservation Healing


   In all of the diagrams, we expect that PATH's and RESV's are not pro-
   pogated past the point needed to heal a reservation in place.


1.2.3 No Dog Leg Routing


   The draft assumes that the reservation was put in place after the
   mobile node sending a binding update to the correspondent node and as
   such, the reservation is not being placed through the home agent.


1.2.4 All Parts of the PATH Must be Restored


   In order to have a seamless handoff, all routers that are RSVP aware
   in the PATH after handoff must be alerted such that the PATH and RESV
   state can be installed on that router.


1.2.5 RSVP Session-ID


   As currently formulated, RSVP generally uses the 5-tuple
   SRC,DST,PROTO,SPORT,DPORT as the index to which reservation a partic-
   ular packet should be classified. It is also used as the means to
   refer to the reservation in subsequent RSVP signaling.

   While adequate for many kinds of RSVP flows, using the 5-tuple as the
   session identifier runs into problems when the application desires
   admission of a certain class of traffic and expects to keep its
   traffic within a given Tspec, but would like to be able to change the
   filterspec mid-session. Consider, for example, the case of VoIP Call
   Waiting where the QoS envelope for the two calls is identical (say,
   64kb/sec), but only one flow will be active at any one time. Unfor-
   tunately, RSVP as currently specified requires double booking of
   resources mainly because there is no way to assocatiate the new 5-
   tuple in the filterspec with the old reservation.

   Mobility tickles the same problem, but in a different way. When a
   mobile node move from one router to another, it may change its care
   of address. It is assummed that the address used for the 5-tuple is
   the source address as seen in the IP header (as opposed to the actual
   home address). As such, instead of the destination of the reservation
   changing, the source address would be the variable part of the 5-



M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 3]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


   tuple instead of the destination, but the results yield a similar
   result: the reservation would need to be double booked, as well as
   the implication that any change of care of address would require a
   full round trip to the correspondent node.

   For these reasons, this draft makes the wild and perhaps unfounded
   assumption that the ISSLL working group will step up to allowing RSVP
   to use a session identifier in addition to the normal 5-tuple to
   identify a reservation. Given the round trip implications, the author
   cannot see how seamless mobility with RSVP reservations can be
   achieved if this assumption is false.


1.2.6 Context Transfers


   This draft dabbles in the "what-ifs" of some sort of means of
   transfering context between AR1 and AR2 on a handoff. The assumptions
   made here are:


o    both the PATH and RESV state can be transfered


o    authentication and authorization state can be transfered


o    AR2 can, as is possible, act as if it were a set of interfaces on
     AR1 for the purposes of RSVP where the handoff looked like an ordi-
     nary topology change

o    that the mobile may be made aware of the context context transfer
     and as such it would not need to consider AR2 to be completely
     naive with respect to reissuing PATH messages, or expecting RESV's.

     The intention here is not to define a mechanism nor suggest a par-
     ticular solution. The intention here is only to illustrate whether
     context transfer provides any potential benefit to existing reser-
     vations.

     It should also be noted that there are a couple larger issue
     involved with context transfer which the RSVP portion of the prob-
     lem space also needs to grapple with. Namely, context transfer is a
     posited means by which a router can restore the current state on
     another router for seamless handoffs, but it clearly does not
     answer the question of whether the move _ought_ to happen. A second
     issue arises as to what ought to happen when the QoS policies at
     one access router are different from the QoS policies at another



M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 4]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


     access router. For example, it is not hard to imagine a relatively
     congested access technology like cellular needing the admission
     control policies of RSVP, but another technology only requiring
     diffserv. Should the context transfer deal with QoS equivalencies?
     What ought be the mechanism to determine those equivalencies? And
     as above, ought the mobile node and/or previous access router have
     any say-so over such equivalencies from a policy or some other
     standpoint? Another issue is whether double booking of resources in
     a make-before-break kind of handoff is an issue. If so, how do you
     avoid it?

     As stated earlier, this draft only raises these issues to hopefully
     get an eventual answer.


1.3 Initial Reservations


   This draft assumes that there were two reservations set it place
   using the normal RSVP mechanisms between the mobile node and
   correspondent node.






























M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 5]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


MN->CN:

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------


 -------------->
 PATH (MN->CN)
                ------------------------------------>
                         PATH (MN->CN)
                                                     ----------->
                                                     PATH(MN->CN)

                                                     <-----------
                                                     RESV(MN->CN)
                             <-----------------------------------
                                         RESV (MN->CN)
 <--------------
 RESV (MN->CN)


 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------
                                                     <-----------
                                                     PATH(CN->MN)
                 <-----------------------------------
                          PATH(CN->MN)
 <--------------
 PATH(CN->MN)

 -------------->
 RESV(CN->MN)
                 ------------------------------------>
                         RESV(CN->MN)
                                                     ----------->
                                                     RESV(CN->MN)

1.4 "Optimal" RSVP Handoff


   This flow is fictional and is based on the incorrect assumption that
   if RSVP existed solely for the purpose of making seamless mobility
   work with established RSVP sessions, this is an optimal placement of
   reestablishment messages. This flow is intended to only be viewed as
   gauge in the successive flows as to how far they deviate from this
   self-proclaimed optimum. The assumption here is that through some
   unspecified means, AR2 came to know that the mobile was moving from
   AR1. It should be noted that AGG in this diagram may, in fact, be an



M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 6]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


   arbitrary number of hops -- both RSVP and non-RSVP -- away from AR2,
   and that it is just the common join point for the reservation. It is
   assumed that implementations will consider this in the actual network
   engineering.

MN->CN, CN->MN:

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------


                          ------------------------->
                         |      PATH(MN->CN)
                          ------------------------->
                                RESV(CN->MN)

                          <-------------------------
                                RESV(MN->CN)

   It should be pointed out that aside from the implication that a
   potential difference in the CoA will not hinder the reestablishment
   of reservations, there are several things wrong RSVP-wise with the
   "optimum". Namely:


1)   It is unspecified how AR2 arrived with the PATH and RESV state
     required for both the MN->CN and CN->MN reservations. As we shall
     see later, MN itself would issue the PATH for the MN->CN reserva-
     tion to reestablish PATH and RESV state.

2)   The naked RESV from AR2 to AGG is illegitimate. There is no PATH
     state associated with it, and while we might be able to imagine AGG
     consing up the PATH state given the reservation on another inter-
     face, RSVP routers between AR2 and AGG would be completely clueless
     about the RESV. Indeed, since they have no PATH state, they
     wouldn't know where to forward the RESV for the next hop.




1.5 Additional Issues



1.5.1 Interdomain Trust Issues


   While NSIS may not directly deal with interdomain trust issues, it



M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 7]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


   isn't clear how policy based admission interacts with topology
   changes. Is this well understood? In the flows below, what would go
   in the policy objects and what if anything would need to happen at
   the PDP's? What credentials need to be carried in RESV's of routers
   past the PEP's?

   This memo tries to make an attempt to answer these questions.  In no
   way does this memo intend to be exhaustive on this subject as a
   number of simplifying assumption have been made in the subsequent
   sections.


1.5.2 RSVP Aggregation

   [2] defines a method of aggregating RSVP microflows into larger
   aggregates by tunneling individual RSVP microflows between an aggre-
   gator and deaggregator. The intended behavior is that the tunneled
   microflows will traverse the aggregated area of the network where it
   will receive the appropriate treatment by either installing a larger
   aggregated reservation, or perhaps using a diffserv service level
   agreement, etc.

   It is quite possible that mobility will uncover further issues here.
   This draft does not consider aggregation, but future revisions of
   this draft or elsewhere ought to consider interactions with RSVP
   aggregation as well.


2. Same Care of Address


   With the same care of address, we expect that the reservation will
   look the same and that this looks a whole lot like a topology change.
   The main deviation from the optimal flow is that there is the need
   for MN to reestablish the MN->CN reservation since AR2 is completely
   unaware fo any reservations that MN had established through AR1. In
   the CN->MN direction, AGG, upon seeing the host route, would under
   normal RSVP start sending PATH messages













M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 8]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



2.1 MN->CN reservation


 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

               ----------------------------------->
                        HOSTROUTE(MN, AR2)

                          <------------------------
                             HOSTROUTE(MN, AR2)

 -------------------------->
      PATH(MN->CN)

                           ------------------------>
                              PATH(MN->CN)

                           <------------------------
                              RESV(MN->CN)
 <--------------------------
      RESV(MN->CN)




























M. Thomas           draft-thomas-nsis-rsvp-analysis             [Page 9]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



2.2 CN->MN reservation


   The CN->MN reservation benefits from the fact that AGG is alerted  to
   the  topology  change  and can therefore initiate a PATH toward MN as
   with any other topology change. Since  AGG  is  the  join  point,  CN
   doesn't need to be informed of any changes as with standard RSVP.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

               ------------------------------------>
                        HOSTROUTE(MN, AR2)

                           <------------------------
                              HOSTROUTE(MN, AR2)    |
                           <------------------------
                                PATH(CN->MN)

 <--------------------------
        PATH(CN->MN)

 -------------------------->
        RESV(CN->MN)

                            ----------------------->
                                   RESV(CN->MN)























M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 10]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



2.3 CN->MN & MN->CN reservations


   With concurrent reservations, we can draw the flow as  follows.  Note
   that  in  both  flows  above,  a  round  trip  between MN and AR2 are
   required to either reestablish state, or conform to standard RSVP.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

               ------------------------------------>
                        HOSTROUTE(MN, AR2)

                           <------------------------
                             HOSTROUTE(MN, AR2)    |
                           <------------------------
                                PATH(CN->MN)
 ------------------------->
      PATH(MN->CN)

 <-------------------------
      PATH(CN->MN)        |
                           ------------------------>
                                PATH(MN->CN)

 ------------------------->
      RESV(CN->MN)
                           <------------------------
                           |    RESV(MN->CN)
                            ----------------------->
                                RESV(CN->MN)
 <-------------------------
      RESV(MN->CN)

















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 11]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



2.4 CN->MN & MN->CN Reservations with Context Transfer


   In the context transfer case, we can see that if we assume  that  AR2
   would  act  as  AR1 on a topology change, it would immediately send a
   PATH message for the MN->CN  reservation  upon  installing  the  PATH
   state  locally. Assuming that MN is aware of the context transfer, it
   would need no RSVP signaling to restore the reservation  on  its  new
   interface.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------
               ------------>
                XFER(MN)

               <-----------
                XFER_ACK(MN)

               ------------------------------------>
                        HOSTROUTE(MN, AR2)


                           <------------------------
                             HOSTROUTE(MN, AR2)    |
                           <------------------------
                                PATH(CN->MN)

                           ------------------------>
                          |   PATH(MN->CN)
                           ------------------------>
                              RESV(CN->MN)

                           <------------------------
                              RESV(MN->CN)


3. Different Care of Address


   Here we expect to be able to use a shared reservation for the new
   CoA, but no other assumptions are made beyond that.









M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 12]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



3.1 MN->CN

As we can see, the MN->CN with new CoA require that MN launches  a  PATH
to  AR2  which  is unware of the existing reservations on AR1. These are
aggregated as a topology change at AGG and need not traverse back to CN.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 -------------------------->
        PATH (MN->CN)
                            ------------------------>
                                PATH (MN->CN)

                            <-----------------------
                                    RESV (MN->CN)
 <--------------------------
        RESV (MN->CN)
































M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 13]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



3.2 CN->MN


   Since PATH's originate from the sender and only MN is  aware  of  the
   topology  change, the only means of tracing the new path is for CN to
   launch a new PATH. One obvious trigger might be a binding update back
   to  CN  which  would  alert  CN  that  the reservation's topology has
   changed.

   As can be readily seen, the reservation cannot be reestablished to CN
   until it receives a binding update.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 --------------------------------------------------------------->
                        BU(Co AR2)

 <---------------------------------------------------------------
                        BU_ACK()
                                                    <------------
                                                     PATH(CN->MN)
                            <-----------------------
                                    PATH(CN->MN)
 <--------------------------
        PATH(CN->MN)
 -------------------------->
        RESV (CN->MN)
                            ------------------------>
                                    RESV(CN->MN)
                                                    ------------>
                                                     RESV(CN->MN)


















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 14]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



3.3 MN->CN, CN->MN Reservations


   Combining the two flows yields the following. Note that there is very
   little  overlap  as well as the six messages to/from the mobile node.
   This is a far cry from our "optimal" flow.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 --------------------------------------------------------------->
                        BU(Co AR2)

 -------------------------->
        PATH(MN->CN)
                            ------------------------>
                                PATH(MN->CN)
                            <------------------------
                                RESV(MN->CN)
 <--------------------------
        RESV(MN->CN)


 <----------------------------------------------------------------
                        BU_ACK()                                 |
                                                    <-------------
                                                     PATH(CN->MN)
                            <-----------------------
                                PATH(CN->MN)
 <--------------------------
        PATH(CN->MN)
 -------------------------->
        RESV (CN->MN)
                            ------------------------>
                                RESV (CN->MN)
                                                    ------------->
                                                     RESV (CN->MN)













M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 15]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



3.4 MN->CN, CN->MN Reservations with Context Transfer


   The context tranfer scenario here  is  better  than  without  context
   transfer,  but still has many problems. For the CN->MN flow, there is
   still the dependency to use the binding update to  CN  to  reinitiate
   the  PATH message. However, while there were two reservations missing
   in the previous flow (AGG->AR2, AR2->MN), it is possible  that  since
   AR2  had the PATH and RESV state from AR1 for the hop to MN, it could
   proactively reestablish that portion of  the  reservation  before  it
   actually sees the RESV coming back from AGG.

   This seems on its face -- as above -- to be a rather unfortunate  and
   undesirable  outcome.  The  main  problem is that unlike the same CoA
   context transfer, the host route update performed the job of alerting
   the  routers  of  the  topology  change. There seems to be no obvious
   mechanism to do this with RSVP itself.

   Note that this flow is silent about any fast handoff between AR1->AR2
   tunnel. Section 4 will explore the interaction between fast handoffs,
   context transfers and mobility, and reservations.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------
               ------------>
                XFER(MN)

               <-----------
                XFER_ACK(MN)

 --------------------------------------------------------------->
                        BU(Co AR2)

                            ------------------------>
                                PATH(MN->CN)

                            <-----------------------
                                RESV(MN->CN)


 <---------------------------------------------------------------
                        BU_ACK()                                |
                                                    <------------
                                                     PATH(CN->MN)
                            <-----------------------
                                 PATH(CN->MN)




M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 16]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


                            ----------------------->
                                 RESV(CN->MN)
                                                    ------------>
                                                     RESV(CN->MN)

4. Mobile IP Fast Handoffs

   It is expected that when a mobile node desires a seamless handoff
   that it will use the fast handoff work being currently addressed in
   the Mobile IP working group [refxxx]. While most of the details are
   unimportant, the pertinent part of the work is that there will be a
   forward tunnel established for flows originating from the correspon-
   dent node to the mobile node. This forward tunnel is identical to the
   forward tunnel between the mobile node's home agent and the mobile
   node itself. While the tunnel may in fact be transient between the
   old access router and the new, there may still be high motivation to
   make certain that the so-called side-haul traffic has admission con-
   trol as well.

   Because this traffic is only in the direction of the correspondent
   node to the mobile node and because it is definitionally the dif-
   ferent CoA case, we only need to consider two additional cases: RSVP
   when there is no context transfer, and our hypothetical router con-
   text transfer protocol. In this section, we denote the forward tunnel
   establishment message as a binding update.


























M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 17]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



4.1 Fast Handoffs without Context Transfer

   Fast handoffs as currently being formulated in the MIP working  group
   use   a   forward   tunnel   from   a   mobile   IP  router  that  is
   topologically/geographically close to the  mobile  node  on  the  old
   access  link (typically the first hop router) toward the mobile node.
   Since this is a tunnel, RSVP and specifically [RFC2746] treats the as
   a  new  interface  on  the old access router for which the old access
   router and mobile node must create a new reservation for the  forward
   tunnel  in  order  to  preserve  the  quality  of  service  that  the
   reservation on the direct link was previously entitled to. Note  that
   fast  handoff is not involved with how the reservation is reestablish
   in the direction of CN->MN.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 --------------->
      BU(Co AR2)

 <---------------
      BU_ACK()  |
                ------------>
                PATH(AR1->MN)

 <--------------------------
        PATH(AR1->MN)

 -------------------------->
        RESV (AR1->MN)

                <------------
                RESV(AR1->MN)

















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 18]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



4.2 Fast Handoffs with Context Transfer

   With a context transfer, again assuming the mobile is  aware  of  the
   transfer  so  that  it  does  not  add unnecessary signling.  The net
   effect here is that the  mobile  only  needs  to  initiate  the  fast
   handoff by signaling AR1. As above, AR1 will initiate a PATH message,
   but since AR2 already knows about the reservation ahead of  time  due
   to the context transfer, it knows that the next hop has the same PATH
   and RESV state. As such AR2 is the join point and does  not  need  to
   forward the PATH to MN and instead immediately sends the RESV back to
   AR1.

   This has the nice effect that there is minimal signaling between  the
   mobile node and the access routers.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 --------------->
     BU(Co AR2)

                ------------>
                XFER(MN)

                <------------
                XFER_ACK(MN)

                ------------>
                PATH(AR1->MN)

                <------------
                RESV(AR1->MN)

 <---------------
       BU_ACK()















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 19]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



4.3 MN->CN, CN->MN with Context Transfer and Fast Handoff


   This combined flow  shows  the  effects  of  context  transfer,  fast
   handoff with both flows. Note that the mobile node need only initiate
   the transfer, but  not  do  any  other  signaling  on  the  last  hop
   interface that is in the critical path.

 MN           AR1         AR2         PDP         AGG          CN
 ----------------------------------------------------------------

 --------------->
    BU(Co AR2)

                ------------>
                XFER(MN)

                <------------
                XFER_ACK(MN)

                ------------>
                PATH(AR1->MN)
                            |
                            ------------------------>
                                PATH(MN->CN)

                            <-----------------------
                                RESV(MN->CN)
                <-----------
                RESV(AR1->MN)

 <---------------
     BU_ACK()

  /* tunnel is established with QoS along the way; the rest of the
     flow is not in the critical handoff path  */

 --------------------------------------------------------------->
        BU(Co AR2)

 <----------------------------------------------------------------
        BU_ACK(  )                                               |
                                                    <-------------
                                                     PATH(CN->MN)
                            <-----------------------
                                PATH(CN->MN)




M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 20]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


                            ------------------------>
                                RESV (CN->MN)
                                                    ------------->
                                                     RESV (CN->MN)





4.4 Reservations Through the Home Agent

   In some cases, the correspondent node may be unable or unwilling to
   perform a binding update. In this case, the reservation will always
   flow through the home agent in the CN->MN direction. It should be
   noted that this flow is identical to the Fast Handoff flow, aside
   from the details of which routers are also affected during reestab-
   lishment. This should not be surprising since Fast Handoff is just
   using the old access router as a "local" home agent to establish the
   identical kind of forward tunnel that the mobile node's real home
   agent would create.

   Since the tunnel between MN and HA is effectively a virtual interface
   between the two, the same considerations apply as in [RFC2746], which
   is to say that in order to restore the reservation on the new acces
   router between the home agent and the mobile, all of the same con-
   siderations apply as in the fast handoff case. Since Fast Mobility is
   not dependent on how the packets arrive at AR1 (tunneled, not tun-
   neled), packets arriving through the home agent are treated like any
   other packets destined for the mobile node.

   Therefore, fast mobility can be achieved as usual by tunneling the
   already tunneled packets from AR1 to the mobile node. The only thing
   that changes is that the filterspec will need to be adjusted to
   reflect encapsulated data from the Home Agent instead of the actual
   reservation to the correspondent node, but this is inherent in
   [RFC2746].

   Of course, we end up with two levels of tunnel for the duration of
   the fast handoff tunnel, but this seems inherent with the design of
   fast handoffs.  Whether the implied bandwidth overhead is too burden-
   some is beyond the scope of this draft.










M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 21]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


 MN           AR1         AR2         PDP         AGG          HA
 ----------------------------------------------------------------

 --------------------------------------------------------------->
      BU(Co AR2)

 <---------------------------------------------------------------
      BU_ACK()                                                  |
                          <--------------------------------------
                                    PATH(HA->MN)
 <--------------------------
        PATH(HA->MN)

 -------------------------->
        RESV (HA->MN)

                            ------------------------------------->
                                    RESV(HA->MN)


5 Analysis

   At first glance comparing the flow in section 2.4 and 4.3 the with
   the "optimal" flow, seems anything but optimum. However the "optimal"
   only gave a minimum amount of signaling which would be required; it
   did not assign any metrics to deviations from optimal. In this sec-
   tion, we shall try to assign some numeric quantities to determine how
   far each flow is from optimum.

   To do this, we assign a numeric times to each link, These numbers are
   arbitrarily chosen here and attempt to express the relative cost of
   sending a message and its associated latency in milliseconds. For any
   particular technology these numbers should be adjusted. Since the end
   goal is seamless mobility, we define the total numeric cost as the
   time between the initiation of a handoff and the when a functional
   bidirectional reservation is in place between the mobile node and the
   correspondent node care of the new access router.

   Costs:


o    Tlast =  MN<->AR: 20ms. Last mile is always s l o w.

o    Tagg = AR<->AGG: 2ms. Assumedly fast ethernet, etc

o    Tarar = AR<->AR: 5ms. perhaps slower than Tagg

o    Tcn =  MN<->CN: 100ms. This is a very arbitrary number; we assume



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 22]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


     CN is very far away

     5.1 Optimal Flow

     In our fictional flow, we only have 3 messages between AR and AGG.
     Therefore our calculation is:

     Tagg * 3 = 2*3  = 6ms.

     5.2 Optimized Real Flows

     Section 2.4 is the same CoA case with context transfer. It's calcu-
     lation is:

     Tarar*2 + Tagg*6 = 5*2 + 2*6 = 22

     Section 3.4 is the different CoA case with context transfer, but no
     fast handoff:

     Tarar*2 + Tcn*2 + Tagg*4 + Tlast*2 = 5*2 + 2*100 + 2*4 + 2*20 = 258

     Section 4.3 is the different CoA with context transfer, but with
     fast handoffs. Note that we do not count the cost of the round trip
     to the CN and associated messaging since it is not in the critical
     path:

     Tlast*2 + Tarar*4 + Tagg*2 = 40 + 20 + 4 = 64

     5.2.1 Optimized Conclusions (or v.v.)

     The general results should not be completely surprising.  The fic-
     tional is always best as fiction is wont to be.  Keeping the same
     care of address is the next best thing though as the amount of time
     to propogate the host route is relatively small and it doesn't
     involve any communication with the mobile or correspondent nodes.
     The cost of even using context transfer without fast handoff is
     unsuprisingly bad as it requires a potentially expensive round trip
     back to the correspondent node. For real time mobility, this will
     undoubtably be unacceptiable. For whole enchilada, we find a middle
     ground. The main difference between the same and different CoA
     cases is actually in the need for a round trip on the slow last
     mile interface. Assuming that not many more of these slow round
     trips are not necessary, however, this may prove a fast enough for
     most cases. It should be noted that proactive handoffs from AR1 to
     AR2 are not accounted for here specifically, but ought to produce
     somewhat better results in the different CoA case.

     5.3 Other Flows



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 23]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


     For completeness sake, the rest of the flows are listed here.

     /* some day */


6 Mobility and Interdomain Policy


   [RFC2749] and [RFC2753] provide a framework for policy based admis-
   sion control for RSVP. The general case is that there may be many
   policy enforcement points (PEP) as well as many policy decision
   points (PDP). In general, it is envisioned that PEP's will be stra-
   tegically placed at the borders of RSVP enabled networks to enforce
   policy based admission control, though there is an implementation
   detail. Although a reservation may flow through any number of dif-
   ferently administered RSVP domains, for simplicity's sake we will
   limit the number of administrative domains each reservation traverses
   to two for policy decisions as well as the domains that the reserva-
   tion crosses.

   We define a cross realm reservation as one where the realm of the
   current set of policy objects will either require adjustment by the
   sender to procure the proper policy objects, or expect that one of
   the upstream routers supply a new policy object which will allow the
   reservation to pass the next PEP.

   To complete the scenario for mobility, we must consider at least one
   other possibility: that the mobile node may move from one visited
   network administrative domain to another. For simplicity, we consider
   that the PDP that the mobile node is authorized by is in the same
   domain as its home agent, though in reality there need be no such
   linkage.

   The following diagram illustrates the various networks and their
   associated PDP's. We will consider all of the reservations this draft
   in turn.

   The following conventions are used in this diagram and the rest of
   this section:


box   Boxes denote various networks which are administered separately.


AR   an access router which is a PEP on the ingress side for reserva-
     tions. That is to say, it is a PEP only in the direction coming
     from the untrusted interface, eg the mobile node.




M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 24]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


BR   a border router which is a PEP on the ingress from another adminis-
     trative domain typically toward the big I internet.


PDP  a policy decision point for a given administrative domain.


MN   a mobile node which is in the same administrative domain as the
     home network.


CN   a node which is in the same administrative domain as the correspon-
     dent network.



            Home Net                          Correspondent Net

       +--------------------+              +---------------------+
       |                    |              |                     |
       |                    |              |                     |
       |    hA    hPDP      |              |       cPDP         cAR---CN
       |                    |              |                     |
       |                    |              |                     |
       +-------hBR----------+              +---------cBR---------+


            Visited1 Net                         Visited2 Net


       +-------v1BR---------+              +---------v2BR--------+
       |                    |              |                     |
       |                    |              |                     |
       |     v1PDP          |              |       v2PDP         |
       |                    |              |                     |
       |                    |              |                     |
       +---v1AR1----v1AR2---+              +---v2AR1-----v2AR2---+
            |
           MN        [direction of movement--------------------->]




6.1 Bilateral vs Hierarchical Cross Realm Policy

   [RFC2753] describes two possible approaches to interrealm policy
   based admission control. The first method requires hopwise bilateral
   arrangements between the administrative domains.  That is, as a



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 25]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


   reservation's RESV crosses administrative boundaries, the appropriate
   policy object which should grants admission is placed in the RESV. An
   RSVP router may add to, replace, or delete policy objects as the
   reservation passes by. Using this method, routers would normally
   rewrite a new policy object acceptible for the next upstream PEP.

   The second method -- somewhat obliquely refered to in section 5.4 of
   [RFC2753] -- uses cascaded PDP's such that if a PDP cannot make a
   policy decision locally because it is not in the same realm as the
   current policy object, it can relay the policy request to a PDP in
   the realm of the policy object for a decision. This method also
   allows for the establishment of a hierarchy of PDP's which eventually
   relay the policy request to the final PDP for a decision.

   The following section will describe the tradeoffs at work, and what
   the specific problems are with respect to mobility.

   A specific example is in order here. Suppose that there exists a
   mobile node which is serviced by AT&T and has a certificate to prove
   that it is mikes-phone@attwireless.net. mikes-phone@attwireless.net
   then attaches itself to MCI's network and want to instantiate a
   reservation -- say for a phone call. The only certificate that the
   phone posseses is the one that AT&T installed as part of the service
   agreement. The phone will therefore, place that certificate with a
   digital signature into a policy object when it needs to send the
   RESV. While it is possible for the phone to have multiple different
   providers (and hence) multiple certificates, this is not scalable and
   therefore the general case is where the phone does not directly pos-
   sess a credential to pass each PEP/PDP it might encounter for the
   reservation.

   As normal, MCI's PEP will forward the RESV to its local PDP for a
   decision.  While it's not too far a stretch of the imagination to
   believe that MCI's PDP could authenticate mikes-phone@attwireless.net
   -- assuming it shared and trusted AT&T's root certificate -- there
   still remains one very large problem: MCI's PDP is completely clue-
   less about what mikes-phone@attwireless.net is _authorized_ for. This
   brings up an interesting question about what MCI's PDP does when it
   sees a cross realm request from its PEP. MCI's PDP could:

   1) Expect AT&T's subscriber database and policies are
      replicated at MCI's PDP.  2) Authorize anything it can authenti-
   cate 3) Expect that there is policy/authorization
      information in the certificate that AT&T gave
      me and that the PDP knows how to act on it 4) Relay that (now
   authenticated) request back
      to something that does understand the policy




M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 26]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


   (1) is, of course, a joke that has no way of scaling, and would most
   likely not be be acceptible even if it were scalable.

   Clearly, (2) is pretty suboptimal if for no other reason than the
   fact that AT&T has no way to revoke the certificate in anything
   approaching real time if the service is canceled. Also, any kind of
   restrictions AT&T wishes to place on the phone's service would be
   unknown to MCI's PDP.

   (3) has two main problems: first, it would require a common policy
   scheme that is codified in the certificate which both providers
   understand. This leads to a least common denominator problem, and
   would most likely lead to a huge interoperability problem as the
   bilateral agreements end up special casing various policies amongst
   themselves.

   Secondly -- and probably more serious -- is that policy as captured
   in the certificate is effectively static. Any changes of policy would
   require that the old certificate be revoked and a new certificate
   issued. This may be OK when the policy is relatively static and sim-
   ple but if we want to allow a dynamic policy, (eg, calling cards) a
   static policy mechanism is not going to be well suited.

   (4) provides the most dynamic and fine grained policy control. Revo-
   cation isn't much of an issue because authentication doesn't automat-
   ically translate to authorization for any services. Also:  since the
   policy logic is self contained within AT&T's PDP and it has access to
   all of the necessary subscriber information, doesn't rely on any
   krufty less-than-grand-unified policy schema.  Another nice side
   effect is that the authentication relationship needed is between the
   phone and AT&T's PDP which are not coicidentally in the same realm.

   (4)'s tradeoff, of course, is that it requires a potentially expen-
   sive round trip to AT&T's PDP for decisions. One mitigation is that
   AT&T's PDP could allow the decision to be cached at MCI's PDP, but
   the problem never completely goes away. However, in the specific case
   of mobility and fast handoffs, as we shall see in subsequent sec-
   tions, the round trip penalty may not be a catastrophic penalty. The
   reason is that there is other messaging as is evident in the previous
   sections which make a very strong case for Fast Handoffs and Context
   Transfer.

   Thus to simplify this already too-weighty draft, we will focus on (4)
   as it seems like it provides the proper framework for mobile nodes as
   they are most likely to be deployed. This is not to say that any of
   possibilities are not viable in, perhaps, more limited situations.
   This draft does not attempt to pass judgement on their feasibility
   elsewhere.



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 27]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


6.2 Assumptions

   The following assumptions are made here:


o    All policy based admission control must use some form of proof of
     identity


o    The crypto used to assert identity in the RSVP RESV requests from
     the MN and CN are digitally signed using a X.509 certificate with
     which the node and PDP share a common root CA. Other schemes such
     as Kerberos [RFC1510] and plain text passwords may be used as well,
     though it is not guaranteed they will produce identical results
     here.


o    That the PATH, PEP and PDP's in the PATH are not known in advance.


o    Original policy objects in the RESV's may be deleted and/or new
     policy objects may be added to the RESV.


o    PDP's have pre-existing relationships with one another and function
     as the settlement point for accounting by either using bilateral
     agreements, or some clearinghouse arrangement ala [OSP]


6.3 Initial Case

   The initial case for policy based admission is where the mobile node
   is on Visited Network 1 with a bidirectional reservation with the
   correspondent node CN.

















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 28]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



6.3.1 MN->CN

   In this case, the correspondent node supplies the policy  objects  to
   gain  admission. Note the explicit use of cascaded PDP's to defer the
   decision back to the PDP in the originating administrative domain.

    MN     v1AR1     v1BR     v1PDP    hPDP   cBR     cPDP   cAR   CN
    -----------------------------------------------------------------
    --------->
      PATH
             ---------->
                 PATH
                       ------------------------->
                                  PATH
                                                -------------->
                                                      PATH
                                                              ------>
                                                               PATH

                                                              <------
                                                               RESV
                                                        <------
                                                          REQ
                                                        ------>
                                                          DEC
                                                <--------------
                                                     RESV
                       <-------------------------
                                    RESV
                       --------->
                          REQ
                                ------------------------>
                                          REQ
                                <------------------------
                                          DEC
                       <---------
                          DEC
            <-----------
               RESV
    <--------
      RESV









M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 29]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



6.3.2 CN->MN

   In the CN to MN case, the  MN  is  the  one  that  needs  to  provide
   credentials to the PDP's,

    MN     v1AR1     v1BR     v1PDP    hPDP   cBR     cPDP   cAR   CN
    -----------------------------------------------------------------
                                                             <-------
                                                               PATH
                                               <-------------
                                                    PATH
                       <------------------------
                                   PATH
            <-----------
                PATH
    <--------
      PATH

    -------->
      RESV
             ------------------->
                REQ
                                ------->
                                  REQ
                                <-------
                                  DEC
             <-------------------
                DEC
             ------------>
                RESV
                         ----------------------->
                                  RESV
                                                -------->
                                                  REQ
                                                <--------
                                                  DEC
                                                -------------->
                                                     RESV
                                                              ------>
                                                               RESV










M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 30]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



6.4.1 MN->v1AR2, MN->CN Direction

   If the mobile moves from v1AR1 to v1AR2 in the normal mobile case, it
   must  initiate a PATH message to trace the new route back to CN. Note
   that this is no different than the flow in 6.2.1 with  the  exception
   of v1AR1 being replaced by v1AR2; no binding updates are necessary.

    MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
    -----------------------------------------------------------------
    --------------->
      PATH
                   ------>
                     PATH
                          ---------------------->
                                  PATH
                                                -------------->
                                                      PATH
                                                              ------>
                                                               PATH

                                                              <------
                                                               RESV
                                                        <------
                                                          REQ
                                                        ------>
                                                          DEC
                                                <--------------
                                                     RESV
                          <----------------------
                                  RESV
                          -------->
                             REQ
                                  ---------------------->
                                          REQ
                                  <----------------------
                                          DEC
                          <---------
                            DEC
                  <--------
                     RESV
    <--------------
         RESV








M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 31]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



6.4.2 MN->v1AR2, CN->MN Direction

   The only difference with this flow and the flow in 6.2.2  is  that  a
   binding  update to CN is need to stimulate the CN to retrace the PATH
   for the reservation

    MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
    -----------------------------------------------------------------
    ---------------------------------------------------------------->
                                   BU
                                                             <-------
                                                               PATH
                                               <-------------
                                                    PATH
                       <------------------------
                                   PATH
            <-----------
                PATH
    <--------
      PATH

    -------->
      RESV
             ------------------->
                REQ
                                ------->
                                  REQ
                                <-------
                                  DEC
             <-------------------
                DEC
             ------------>
                RESV
                         ----------------------->
                                  RESV
                                                -------->
                                                  REQ
                                                <--------
                                                  DEC
                                                -------------->
                                                     RESV
                                                              ------>
                                                               RESV
    <----------------------------------------------------------------
                                   BU_ACK





M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 32]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


7 Same Care of Address

   With policy, the same care of address case has fewer scenarios
   because it does not deal with the case of the mobile node traversing
   administrative domains because we expect that that will require a
   different care of address by definition.  For the sake of simplicity,
   v1BR is colocated with the AGG functionality in previous sections.

7.1 MN->v1AR2, MN->CN Direction

   Note that in this flow the routing  change  is  completely  localized
   within the trusted part of the visited network, therefore none of the
   PDP's need to be consulted.

 MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 -----------------------------------------------------------------

         -------------->
            HOSTROUTE

                <-------
                HOSTROUTE

 --------------->
      PATH
                -------->
                  PATH

                <--------
                  RESV
 <---------------
      RESV



















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 33]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


7.2 MN->v1AR2, CN->MN Direction

   In this flow the mobile node must present a  policy  object  to  gain
   admission  since  it  must  pass  the  v1AR1  PEP.  This  is  clearly
   suboptimal as it requires a potentially costly  round  trip  to  MN's
   home PDP.

 MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 -----------------------------------------------------------------


         ------------->
            HOSTROUTE

                <------
                 HOSTROUTE|
                <------
                  PATH
 <---------------
        PATH

 --------------->
        RESV
                ------------->
                    REQ
                             ---------->
                                REQ
                             <----------
                                DEC
                <-------------
                     DEC
                ------>
                 RESV


















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 34]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


7.2 MN->v1AR2 with Context Transfer

   If the context were to be transfered from v1AR1 to v1AR2,  we  should
   be  able  to  forego  the  mobile  node  from  having  to  submit its
   credentials for hPDP since it was already authorized by hPDP at v1AR1
   which  is  within  the  same administrative domain. Note that further
   RSVP messages from MN will require that v1AR2 share a key with MN  to
   sign  the  Integrity Object, but assuming that a shared key for v1AR1
   was transfered the same key could be used for  both  access  routers.
   How  MN and v1AR1 came to share a key is outside of the scope of this
   draft.

   Note that this flow is, in fact, identical to the flow in 2.4,  which
   of course is a good thing.

 MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 -----------------------------------------------------------------

          ------->
           XFER
          <-------
           XFER_ACK

          ------------->
            HOSTROUTE

                <-------
                 HOSTROUTE|
                <-------
                  PATH(CN->MN)

                ------->
                | PATH(MN->CN)
                ------->
                  RESV(CN->MN)

                <-------
                  RESV(MN->CN)


8 Change of Care of Address

   With normal mobile IP, reestablishment of the reservation isn't any
   different than the initial case. That is to say, the reservation must
   be fully reauthorized as if it were a brand new reservation. As such
   we can combine the case where we cross administrative boundaries
   since the flows are identical.




M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 35]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



8.1 MN->v1AR2, MN->CN Direction

   If the mobile moves from v1AR2 to v2AR1 in the normal mobile case, it
   must  initiate a PATH message to trace the new route back to CN. Note
   that this is no different than the flow  in  6.2.1  with  the  proper
   transposition to v1AR2 to v2AR1.

    MN    v1AR2  v2AR1  v2BR   v2PDP    hPDP   cBR    cPDP   cAR   CN
    -----------------------------------------------------------------
    --------------->
      PATH
                   ------>
                     PATH
                          ---------------------->
                                  PATH
                                                -------------->
                                                      PATH
                                                              ------>
                                                               PATH

                                                              <------
                                                              RESV
                                                        <------
                                                          REQ
                                                        ------>
                                                          DEC
                                                <--------------
                                                     RESV
                          <----------------------
                                  RESV
                          -------->
                             REQ
                                  ---------------------->
                                          REQ
                                  <----------------------
                                          DEC
                          <---------
                            DEC
                  <--------
                     RESV
    <--------------
         RESV








M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 36]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



8.2 MN->v2AR1, CN->MN Direction

   Likewise as in 8.1, the only difference with this flow and  the  flow
   in  6.2.2  is that a binding update to CN is need to stimulate the CN
   to retrace  the  PATH  for  the  reservation  as  well  as  the  same
   transposition of v1AR2 to v2AR1 as above.

   Obviously, this flow leaves a lot to be desired since it  must  incur
   serveral expensive round trips to distant PDP's.

    MN    v1AR2  v2AR1  v2BR   v2PDP    hPDP   cBR    cPDP   cAR   CN
    -----------------------------------------------------------------
    ---------------------------------------------------------------->
                                   BU
                                                             <-------
                                                               PATH
                                               <-------------
                                                    PATH
                       <------------------------
                                   PATH
            <-----------
                PATH
    <--------
      PATH

    -------->
      RESV
             ------------------->
                REQ
                                ------->
                                  REQ
                                <-------
                                  DEC
             <-------------------
                DEC
             ------------>
                RESV
                         ----------------------->
                                  RESV
                                                -------->
                                                  REQ
                                         <---------------
                                               REQ
                                         --------------->
                                              DEC

                                                <--------



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 37]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


                                                  DEC
                                                -------------->
                                                     RESV
                                                              ------>
                                                               RESV
    <----------------------------------------------------------------
                                   BU_ACK












































M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 38]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



8.3 MN->v1AR2 with Context Transfer

   In a care of address change, context transfer may help the  situation
   somewhat.  Since  it  isn't  clear  whether context can be transfered
   across administrative domains, this flow shows the case where context
   transfer ought to work.

   As with other flows that do not use fast  handoff  in  the  preceding
   sections, this flow shows that the MN->CN direction benefits from the
   transfer, whereas the CN->MN direction is still bound by a round trip
   to  the  CN  as  well  as  round  trips  to  the  home  PDP since the
   correspondent node's PEP is unaware of the context transfer and  will
   demand credentials as usual at its border, though not quite as bad as
   8.2 since the v1AR2 will be able to act as a local PDP since  it  has
   the context from v1AR1.

    MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
    ----------------------------------------------------------------

           --------->
             XFER(MN)

           <--------
             XFER_ACK(MN)

    --------------------------------------------------------------->
                           BU(Co v1AR2)

                    ------->
                    PATH(MN->CN)

                    <-------
                     RESV(MN->CN)

    <---------------------------------------------------------------
                           BU_ACK()                                |
                                                             <------
                                                        PATH(CN->MN)
                                                <-------------
                                                  PATH(CN->MN)
                           <---------------------
                                  PATH(CN->MN)
                   <--------
                    PATH(CN->MN)
    <---------------
     PATH(CN->MN)
    --------------->



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 39]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


     RESV(CN->MN)
                   --------->
                    RESV(CN->MN)
                            ---------------------->
                                 RESV(CN->MN)
                                                  -------->
                                                    REQ
                                         <-----------------
                                               REQ
                                         ----------------->
                                              DEC
                                                  <--------
                                                     DEC
                                                   ---------->
                                                    RESV(CN->MN)
                                                             ------>
                                                        RESV(CN->MN)



9 Fast Handoffs with Policy Based Admission

   Fast handoff is clearly need to bridge the latency of the flow in
   section 8.3; policy based admission only exacerbates an existing
   dreadful situation.  The following sections examine how Fast Handoffs
   interact with policy based admission along with some conjecture as to
   how Context Transfer may improve the situation.
























M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 40]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



9.1 Fast Handoff with Policy

   For a fast hand we establish a forward tunnel between v1AR1 and v1AR2
   which  requires  that  MN  reauthorize  with v1PDP and hPDP.  This is
   potentially a long round trip  which  is  in  the  critical  path  of
   setting  up  the  tunnel  which  will  field  the  traffic  from  the
   correspondent nodes during the transition.
 MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 ----------------------------------------------------------------

 --------->
  BU(Co AR2)

 <---------
  BU_ACK()|
          ------>
           PATH(AR1->MN)

 <---------------
        PATH(AR1->MN)

 --------------->
        RESV (AR1->MN)
                --------------->
                      REQ
                               -------->
                                  REQ
                               <--------
                                  DEC
                <---------------
                      DEC
          <------
            RESV(AR1->MN)

















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 41]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



9.2 Fast Handoffs with Context Transfer

   There is a _major_ assumption here that existence of the  reservation
   from  v1AR1  to  v1AR2  would  also  allow  v1AR1  to  authorize  the
   reservation for the forward tunnel to v1AR2.   This  is,  perhaps,  a
   dubious  assumption  and  does  not  seem  like the way that the COPS
   policy framework is intended to work, so this is all arguable. With a
   stateful  v1PDP,  or v1AR1 acting as a local PDP it may be acceptible
   as a local policy to give a grace period to mobile nodes so  long  as
   their other reservations were admitted.

 MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 ----------------------------------------------------------------

 --------->
     BU(Co AR2)

          ------->
           XFER(MN)

          <-------
           XFER_ACK(MN)

          ------->
           PATH(AR1->MN)

          <-------
           RESV(AR1->MN)

 <---------------
       BU_ACK()



















M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 42]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002



9.3 MN->CN, CN->MN with Context Transfer and Fast Handoff


   This combined  flow  shows  the  effects  of  context  transfer  fast
   handoff,  and  policy  based  admission control with both flows. Note
   that the mobile node need only initiate the transfer, but not do  any
   other  signaling  on  the  last hop interface that is in the critical
   path. Other than the addition of PDP traffic on  the  reestablishment
   of  the  CN->MN  path  after  the fast handoff was made, this flow is
   otherwise identical to the flow in section 4.3.


  MN    v1AR1  v1AR2  v1BR   v1PDP    hPDP   cBR    cPDP   cAR   CN
 ----------------------------------------------------------------

 --------->
 BU(Co AR2)

          ------->
           XFER(MN)

          <-------
           XFER_ACK(MN)

           ------>
            PATH(AR1->MN)
                  |
                  ------>
                   PATH(MN->CN)

                  <------
                   RESV(MN->CN)
            <------
             RESV(AR1->MN)

 <---------------
     BU_ACK()

  /* tunnel is established with QoS along the way; the rest of the
     flow is not in the critical handoff path  */

 --------------------------------------------------------------->
        BU(Co AR2)

 <----------------------------------------------------------------
        BU_ACK(  )
                                                          <------



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 43]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


                                                     PATH(CN->MN)
                                             <-------------
                                               PATH(CN->MN)
                        <---------------------
                               PATH(CN->MN)
                <--------
                 PATH(CN->MN)
 <---------------
  PATH(CN->MN)
 --------------->
  RESV(CN->MN)
                --------->
                 RESV(CN->MN)
                         ---------------------->
                              RESV(CN->MN)
                                               -------->
                                                 REQ
                                      <-----------------
                                            REQ
                                      ----------------->
                                           DEC
                                               <--------
                                                  DEC
                                                ---------->
                                                 RESV(CN->MN)
                                                          ------>
                                                     RESV(CN->MN)

   [need to work on the analysis section here...]

References

[RFC2205]
     Network Working Group, R. Braden, Ed, "Resource ReSerVation Proto-
     col (RSVP) Version 1 Functional Specification"

[RFC2746]
     Network Working Group, A. Terzis, et al, "RSVP Operation Over IP
     Tunnels"

[RFC2749]
     Network Working Group, S. Herzog, Ed "COPS Usage for RSVP"

[RFC2752]
     Network Working Group, S. Yadav, et al, "Identity Representation
     for RSVP"

[RFC2753]



M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 44]

INTERNET-DRAFT Analysis of Mobile IP and RSVP Interactions  Oct 28, 2002


     Network Working Group, R. Yavatkar, et al, "A Framework for
     Policy-based Admission Control "

[RFC2747]
     Network Working Group, F. Baker, et al, "RSVP Cryptographic Authe-
     tication"

[1]  Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Support
     in IPv6" draft-ietf-mobileip-rfc2002bis-03.txt


[2]  ISSLL Working Group, F. Baker, et al. "RSVP Reservation Aggrega-
     tion" draft-ietf-issll-rsvp-aggr-02.txt

Acknowledgments
   I'd like to thank Dave Oran, Bruce Davie and Ron Cohen who took the
   time to review this draft, and ponder many of my seemingly innocuous
   questions.

Author's Address

          Michael Thomas
          Cisco Systems
          375 E Tasman Rd
          San Jose, Ca, 95134, USA
          Tel: +1 408-525-5386
          email: mat@cisco.com
























M. Thomas           draft-thomas-nsis-rsvp-analysis            [Page 45]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/