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]