Network Working Group Sun. Yi
Internet-Draft ICT
Intended status: Standards Track Feng. Bin
Expires: August 12, 2007 BUPT
Zhang. Yucheng
UEST
Zheng. Rusong
ICT
Dong. Wenxia
SWJTU
Shi. Jinglin
ICT
Dutkiewicz. Eryk
University of Wollongong
February 8, 2007
Extensions to Resource Reservation Protocol (RSVP) for Mobile IPv6
draft-sunyi-fast-rsvp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 12, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Yi, et al. Expires August 12, 2007 [Page 1]
Internet-Draft Fast RSVP February 2007
Abstract
RSVP [1] is designed as a signaling protocol that provides end-to-end
QoS guarantee for real-time services in the fixed hardwired network.
However, when used in the mobile environment, the protocol doesn't
work well due to the mobility of the endpoints. Immediately after a
handover occurs, because of the lack of resource reservation in the
handoff target subnet, QoS of the session degrades notably. Another
problem is that when route optimization is implemented, the protocol
will be invalidated due to certain features of the route optimization
mechanism.
This document proposes extensions to RSVP. The extensions enable
RSVP to operate in the mobile IPv6 network while providing advanced
resource reservation before handover and resource reservation on the
optimized route after handover. With these features, QoS of the
sessions can be guaranteed and the utilization of network resources
can be enhanced resulting in the improvement of overall network
performance.
Yi, et al. Expires August 12, 2007 [Page 2]
Internet-Draft Fast RSVP February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of RSVP Extensions . . . . . . . . . . . . . . . . . 9
3.1. Addressing the QoS Guarantee during Handover . . . . . . . 9
3.2. Cooperation between the RSVP Module and the Mobile IP
Module . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. RSVP Extensions Operation . . . . . . . . . . . . . . . . 11
4. Details of RSVP Extensions . . . . . . . . . . . . . . . . . . 23
4.1. MN is the Receiver of the Session . . . . . . . . . . . . 23
4.2. MN is the Sender of the Session . . . . . . . . . . . . . 28
4.3. MN is both the Sender and the Receiver of the Session . . 33
5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1. RSVP Extensions Capability Exchange . . . . . . . . . . . 42
5.2. Distinguishing Handover Sessions and New Sessions . . . . 42
5.3. Bidirectional Reservation . . . . . . . . . . . . . . . . 42
5.4. Utilization of Advanced Reservation before Handover . . . 43
6. New Messages and Objects . . . . . . . . . . . . . . . . . . . 44
6.1. Modified Common Header . . . . . . . . . . . . . . . . . . 44
6.2. New Objects . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.1. New MSESSION Object . . . . . . . . . . . . . . . . . 45
6.2.2. New Router_Notify Object . . . . . . . . . . . . . . . 46
6.2.3. New Tunnel_Info Object . . . . . . . . . . . . . . . . 47
6.3. New Messages . . . . . . . . . . . . . . . . . . . . . . . 48
6.3.1. HandoverForecast Message . . . . . . . . . . . . . . . 48
6.3.2. HandoverForecastResponse Message . . . . . . . . . . . 49
6.3.3. HandoverForecastConfirm Message . . . . . . . . . . . 49
6.3.4. TunnelStateChange Message . . . . . . . . . . . . . . 49
6.3.5. HandoverForecastError Message . . . . . . . . . . . . 50
6.3.6. HandoverForecastTear . . . . . . . . . . . . . . . . . 50
6.3.7. TunnelPath Message . . . . . . . . . . . . . . . . . . 51
6.3.8. TunnelResv Message . . . . . . . . . . . . . . . . . . 51
6.3.9. TunnelPathTear Message . . . . . . . . . . . . . . . . 51
6.3.10. TunnelResvTear Message . . . . . . . . . . . . . . . . 52
7. Security Considerations . . . . . . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8.1. RSVP Common Header Flags . . . . . . . . . . . . . . . . . 54
8.2. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . . 54
8.3. RSVP Messages . . . . . . . . . . . . . . . . . . . . . . 54
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . . . 59
Yi, et al. Expires August 12, 2007 [Page 3]
Internet-Draft Fast RSVP February 2007
1. Introduction
RSVP [1]is designed as a signaling protocol that provides end-to-end
QoS guarantee for real-time services in the fixed hardwired network.
However, when used in the mobile environment, the protocol doesn't
work well due to the mobility of the endpoints. Immediately after a
handover occurs, because of the lack of resource reservation in the
handoff target subnet, QoS of the sessions degrade notably. Another
problem is that when route optimization is implemented (which is a
compelling strategy in Mobile IPv6 network [2]), the protocol will be
invalidated due to certain features of the route optimization
mechanism. This document proposed extensions to RSVP. The
extensions enable RSVP to operate in the mobile IPv6 network while
providing advanced resource reservation before handover and resource
reservation on the optimized route after handover. With these
features QoS of the sessions can be guaranteed and the utilization of
network resources can be enhanced resulting in the improvement of
overall network performance.
The extensions proposed in this document address the following
problems: (1) How to make the mobile node realize fast handover with
QoS guarantees and (2) How to establish resource reservation on the
optimized route after Mobile IPv6 route optimization.
The extensions proposed in this document divide a handover process
with QoS guarantees into 2 stages:
1. Setup of the resource reservation neighbor tunnel before
handover.
2. Resource reservation on the optimized route after handover.
In the first stage, based on the handover prediction result that the
mobile IP module makes, the extensions proposed in this document
establish a QoS guaranteed tunnel in advance before the handover
occurs. In the second stage, in co-operation with the route
optimization mechanism used in Mobile IPv6 protocol, the extensions
proposed in this document establish resource reservation on the
optimized route after handover. The reference handover scenario is
illustrated in Figure 1.
To support the basic functions, some new messages are defined and
some new objects are added to the messages in traditional RSVP. In
addition, some primitives are also defined for exchanging information
between the mobile IP module and the RSVP module within the same
node. With the modifications of the RSVP module, most of the
functions in this document can be met. However, some modifications
of the mobile IP module are also required to fulfill the objectives
Yi, et al. Expires August 12, 2007 [Page 4]
Internet-Draft Fast RSVP February 2007
of this document.
+---------------+
| Correspondent |
| Node (CN) |
+---------------+
|
|
+---------------+
/-------| IPv6 network |-------\
/ +---------------+ \
/ \
+---------------+ +---------------+
| Previous | | New |
| Access Router | | Access Router |
| (PAR) | | (NAR) |
+---------------+ +---------------+
+-------------+ +-------------+
| Mobile Node |-------------------->| Mobile Node |
| (MN) | | (MN) |
+-------------+ +-------------+
Figure 1: Reference Scenario for Handover
Yi, et al. Expires August 12, 2007 [Page 5]
Internet-Draft Fast RSVP February 2007
2. Terminologies
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The use of
the term, "silently ignore" and "silently discard" is not defined in
RFC 2119. However, the terms are used in this document and can be
similarly construed.
The following terminology and abbreviations are used in this
document.
Mobile Node (MN)
A mobile host supporting Mobile IPv6.
Correspondent Node (CN)
The peer host with which MN is communicating.
Previous Access Router (PAR)
The MN's default router before its handover event.
New Access Router (NAR)
The MN's default router after its handover event.
Care-of Address (CoA)
A unicast routable address associated with a MN
while visiting a foreign link.
Previous CoA (PCoA)
The MN's care-of address used in PAR's subnet.
New CoA (NCoA)
The MN's care-of address used in NAR's subnet.
Handover
A procedure of terminating the IP connectivity to
one subnet and obtaining a new IP connectivity to
another subnet.
RSVP Proxy
The module on a access router which can initiate
RSVP procedures or respond to RSVP requests on
behalf of MN.
Advanced Reservation
Resource reservation which is established before
Yi, et al. Expires August 12, 2007 [Page 6]
Internet-Draft Fast RSVP February 2007
the handover event occurs.
HandoverForecast.ind (HF.ind)
A primitive from MN's mobile IP module to its RSVP
module indicating a predicted handover.
HandoverForecastConfirm.ind (HFConfirm.ind)
A primitive from MN's mobile IP module to its RSVP
module indicating a prediction is successful.
HandoverForecastError.ind (HFError.ind)
A primitive from MN's mobile IP module to its RSVP
module indicating a prediction fails.
SessionHandover.req (SH.req)
A primitive from CN's (MN's) mobile IP module to
its RSVP module requesting whether the session data
to MN (CN) can be switched to the optimized route.
SessionHandover.ind (SH.ind)
A primitive from CN's (MN's) RSVP module to its
mobile IP module indicating the session data to MN(CN)
can be switched the optimized route.
AddrNotify.ind (AN.ind)
A primitive from router's RSVP module to its mobile IP
module indicating the home address and care-of address
of MN so that mobile IP module can rebuild the "Type 2
routing header" or "Home address option" accordingly.
HandoverForecast (HF)
A message from MN's RSVP module to PAR's (NAR's) RSVP
module providing information about the predicted
handover. The message acts as a trigger to establish
the resource reservation tunnel.
HandoverForecastResponse (HFRsp)
A message from PAR's (NAR's) RSVP module to MN's RSVP
module indicating whether the resource reservation
tunnel has been established successfully.
HandoverForecastConfirm (HFConfirm)
A message from MN's RSVP module to PAR's RSVP module
indicating the handover prediction is successful.
TunnelStateChange (TSChange)
A message from PAR (NAR) to NAR (PAR) to indicate the
intermediate routers to change the reservation type
Yi, et al. Expires August 12, 2007 [Page 7]
Internet-Draft Fast RSVP February 2007
(see section 5.4).
HandoverForecastError (HFError)
A message from MN's RSVP module to PAR's (NAR's) RSVP
module indicating the handover prediction fails, so
that the resource reservation tunnel can be rebuilt
in time.
HandoverForecstTear (HFTear)
A message from MN's RSVP module to PAR's RSVP module
to indicate PAR tearing down the resource reservation
tunnel which is mistakenly built by the false
handover prediction.
TunnelPath (TPath)
A message exchanged between RSVP routers to establish
PATH state over the resource reservation tunnel.
TunnelResv (TResv)
A message exchanged between RSVP routers to establish
RESV state over the resource reservation tunnel.
TunnelPathTear (TPathTear)
A message exchanged between RSVP routers to release
the resources reserved in advance on the falsely built
resource reservation tunnel.
TunnelResvTear (TResvTear)
A message exchanged between RSVP routers to release
the resources reserved in advance on the falsely built
resource reservation tunnel.
Yi, et al. Expires August 12, 2007 [Page 8]
Internet-Draft Fast RSVP February 2007
3. Overview of RSVP Extensions
3.1. Addressing the QoS Guarantee during Handover
In traditional RSVP, the SESSION object is used to label a session.
Unfortunately, in mobile environment, the content of the SESSION
object may change after a handover because the "IPv6 DestAddress"
field changes. However, the resource reservation along the path
still corresponds to the old SESSION object and therefore, the QoS of
the service flow is no longer guaranteed. The extensions proposed in
this document introduce a new MSESSION (see section 6.2.) object to
replace the SESSION object in the traditional RSVP protocol.
Compared with the SESSION object, MSESSION adds an "IPv6 HomeAddress"
field in the object. The "IPv6 HomeAddress" field is filled with the
MN's home address and its value is constant during handover, so we
can utilize it to label the session. In mobile environment, the RSVP
router MUST label a session based on the content of the MSESSION and
set up the corresponding Path State and Resv State accordingly.
The key factor affecting the QoS of the session during handover is
how fast resource reservation can be re-established after MN hands
over to a new subnet.
To reduce the resource reservation re-establishment latency, the
extensions proposed in this document enable the RSVP module to make
advanced resource reservation on the neighbor tunnel when MN is still
connected to PAR. Based on the handover prediction result made by
MN's mobile IP module, the RSVP module of MN would send a
HandoverForecast message to PAR (NAR) to inform it about the handover
event. Then PAR (NAR) utilizes this information to make advanced
resource reservation on the tunnel before the handover occurs. So
when MN moves to NAR's subnet, the session between MN and CN can use
this advanced resource reservation neighbor tunnel to transmit the
session data and QoS of the session can be guaranteed.
The extensions proposed in this document specify a resource
reservation tunnel between PAR and MN's NCoA, via NAR. As
illustrated in Figure 2, PAR and MN are the two endpoints of the
resource reservation neighbor tunnel. However, the reservation
should be established before the handover occurs, and MN is not
within NAR's subnet at that time. Therefore, the extensions proposed
in this document introduce a new entity named RSVP proxy, which can
make advanced resource reservation on behalf of MN. In Figure 2, NAR
acts as an RSVP proxy, sending or receiving RSVP messages on behalf
of MN before MN hands over to its subnet.
Yi, et al. Expires August 12, 2007 [Page 9]
Internet-Draft Fast RSVP February 2007
+---------+ RSVP TUNNEL +---------+ +--------+
| PAR |-------------------| NAR |----| MN |
| |-------------------| |----| |
+---------+ +---------+ +--------+
(RSVP Proxy)
Figure 2: RSVP TUNNEL and RSVP Proxy
By setting up a resource reservation tunnel between two neighbor
subnets in advance, the mobile node could realize handover with QoS
guarantee. However, the use of tunnel induces the triangular route
problem, thus causing network resource waste. In Mobile IPv6 [2],
route optimization becomes a compelling strategy, and the reservation
process on the optimized route should be considered. However, in
order to guarantee the QoS of the session, communication between MN
and CN must keep utilizing the tunnel until resources have been
successfully reserved on the optimized route.
3.2. Cooperation between the RSVP Module and the Mobile IP Module
With the extensions of the RSVP module, most of the functions can be
met. However, some modifications to the mobile IP module and some
information exchanging between RSVP module and mobile IP module are
also required. The mobile IP module MUST have the following
functions.
1. When predicting that a handover is imminent, the mobile IP module
of MN MUST send a HandoverForecast.ind to the RSVP module. The
HandoverForecast.ind MUST include the information such as the
predicted NAR's IP address and the corresponding NCoA.
2. After MN hands over to the new subnet, the mobile IP module MUST
check whether the current subnet is the same as the predicted
handover target subnet and send certain indication to the RSVP
module depending on the checking result. If the handover
prediction is successful, a HandoverForecastConfirm.ind MUST be
sent. Otherwise, a HandoverForecastError.ind MUST be sent
immediately. The HandoverForecastError.ind MUST contain the
current in use CoA and MAY contain the formerly falsely predicted
CoA of MN.
3. When MN is stable in the new subnet, the mobile IP module MUST
start the route optimization process. If the mobile IP module of
the CN receives a BU message from MN, it MUST send a
SessionHandover.req to the RSVP module and MUST NOT redirect the
session data to the optimized route until receiving the
SessionHandover.ind from the RSVP module. The
Yi, et al. Expires August 12, 2007 [Page 10]
Internet-Draft Fast RSVP February 2007
SessionHandover.req MUST contain the session's home address and
NCoA.
4. If intermediate routers on the optimized route receive a PATH or
RESV message with "Type 2 routing header" or "Home address
option" in IP header fields, the mobile IP module of the router
MUST utilize the AddrNotify.ind acquired from the RSVP module to
rebuild the "Type 2 routing header" or "Home address option"
before delivering the message to the next hop.
3.3. RSVP Extensions Operation
The extensions proposed in this document begin when the mobile IP
module on MN sends a HandoverForecast.ind to the RSVP module on the
same node and then the RSVP module sends a HandoverForecast message
(see section 6.3.1.) to PAR or NAR depending on whether MN is the
sender or the receiver of the session. If MN is the session
receiver, the HandoverForecast message will be sent to PAR.
Otherwise, the HandoverForecast message will be sent to NAR. The
mobile IP module MAY send a HandoverForecast.ind at any convenient
time, for instance as a response to some link-specific event (a
"trigger") or simply after a handover prediction by GPS. However,
the expectation is that prior to sending the HandoverForecast
message, the mobile IP module on MN MUST have discovered the
predicted handover target subnet (i.e., NAR in Figure 1) and acquired
a NCoA that can be used in that subnet.
With the information provided in the HandoverForecast message, PAR
(NAR) formulates a TunnelPath message (see section 6.3.7) and NAR
(PAR) replies a TunnelResv message (see section 6.3.8). Finally,
through the message exchange between PAR and NAR, a resource
reservation tunnel is established in advance and MN can use this QoS-
guaranteed path immediately after the handover event if the handover
prediction is successful.
When PAR (NAR) receives the TunnelResv message, it sends a
HandoverForecastResponse message (see section 6.3.2) to MN to
indicate the completion of the resource reservation tunnel
establishment. However, if the reservation on the tunnel fails, the
router also sends a HandoverForecastResponse message to MN to
indicate the failure, and then MN will stop the following process.
After MN moves to the new subnet, it checks whether the current
subnet is the same as the predicted handover target subnet (e.g.
comparing the IP address of the current access router and the
predicted access router). Depending on whether the handover
prediction is correct, there are two modes of the operation.
Yi, et al. Expires August 12, 2007 [Page 11]
Internet-Draft Fast RSVP February 2007
1. The prediction is successful. The mobile IP module of MN starts
the binding update process with PAR. After that, it sends a
HandoverForecastConfirm.ind to the RSVP module in the same node
and the latter sends a HandoverForecastConfirm message (see
section 6.3.3.) to PAR or NAR depending on whether MN is the
receiver or the sender of the session. On receiving the
HandoverForecastConfirm message, PAR (NAR) sends a
TunnelStateChange (see section 6.3.4) message to NAR (PAR) to
indicate to the intermediate routers to change the reservation
type (see section 5.4).
2. The prediction fails. The mobile IP module of MN locates the
correct NAR and then starts the binding update process with PAR.
After that, it sends a HandoverForecastError.ind to the RSVP
module on the same node so that the RSVP module SHALL take the
following actions:
If MN is the session receiver, it sends a HandoverForecastError
message (see section 6.3.5.) to PAR to indicate that the handover
prediction fails. After receiving the HandoverForecastError message,
PAR sends a TunnelPath message to the current NAR of MN to establish
the resource reservation tunnel. In addition, MN sends a
HandoverForcastTear message (see section 6.3.6) to PAR and on
receiving this message PAR sends a TunnelPathTear message (see
section 6.3.9.) to the formerly predicted NAR to release the
previously mistakenly built reservation tunnel.
If MN is the session sender, it sends a HandoverForecastError message
to the current NAR to indicate the handover prediction fails. After
receiving the HandoverForecastError message, NAR sends a TunnelPath
message to PAR of MN to establish the resource reservation tunnel.
In addition, MN sends a HandoverForcastTear message to PAR and on
receiving this message, PAR sends a TunnelResvTear message (see
section 6.3.10) to the formerly predicted NAR to release the
previously mistakenly built reservation tunnel.
The scenarios with successful handover predictions are illustrated in
Figure 3, Figure 4 and Figure 5, considering MN act as the session
receiver only, the session sender only, and both the session receiver
and session sender respectively. For convenience, these scenarios
are characterized as a "prediction success" mode of operation. The
scenarios with failed handover predictions are illustrated in Figure
6, Figure 7 and Figure 8, considering MN act as the session receiver
only, the session sender only, and both the session receiver and
session sender respectively. For convenience, these scenarios are
characterized as a "failure recovery" mode of operation.
Yi, et al. Expires August 12, 2007 [Page 12]
Internet-Draft Fast RSVP February 2007
MN PAR NAR
|----------------------------| | |
| Mobile IP RSVP | | |
| Module Module | | |
|----------------------------| | |
| | | |
predict | | |
handover | | |
|------HF.ind----->| | |
| |-----HF---->| |
| | |----TPath--->|
| | |<---TResv----|
| |<---HFRsp---| |
| | | |
disconnect | | |
| | | |
connect | | |
| | | |
|------------------------BU------------------>|
| | |<-----BU-----|
| | |-----BAck--->|
|<----------------------BAck------------------|
|--HFConfirm.ind-->| | |
| |-HFConfirm->| |
| | |--TSChange-->|
| | | |
Figure 3: "Prediction Success" Mode
(MN is the session receiver)
Yi, et al. Expires August 12, 2007 [Page 13]
Internet-Draft Fast RSVP February 2007
MN PAR NAR
|----------------------------| | |
| Mobile IP RSVP | | |
| Module Module | | |
|----------------------------| | |
| | | |
predict | | |
handover | | |
|------HF.ind----->| | |
| |------------HF----------->|
| | |<---TPath----|
| | |----TResv--->|
| |<----------HFRsp----------|
| | | |
disconnect | | |
| | | |
connect | | |
| | | |
|------------------------BU------------------>|
| | |<-----BU-----|
| | |-----BAck--->|
|<----------------------BAck------------------|
|--HFConfirm.ind-->| | |
| |---------HFConfirm------->|
| | |<--TSChange--|
| | | |
Figure 4: "Prediction Success" Mode
(MN is the session sender)
Yi, et al. Expires August 12, 2007 [Page 14]
Internet-Draft Fast RSVP February 2007
MN PAR NAR
|----------------------------| | |
| Mobile IP RSVP | | |
| Module Module | | |
|----------------------------| | |
| | | |
predict | | |
handover | | |
|------HF.ind----->| | |
| |-----HF(B=1)---->| |
| | |---TPath(B=1)-->|
| | |<-----TResv-----|
| | |<-----TPath-----|
| | |------TResv---->|
| | |<---ResvConf----|
| |<-----HFRsp------| |
disconnect | | |
| | | |
connect | | |
| | | |
|---------------------------BU----------------------->|
| | |<------BU-------|
| | |------BAck----->|
|<-------------------------BAck-----------------------|
|--HFConfirm.ind-->| | |
| |-HFConfirm(B=1)->| |
| | |-TSChange(B=1)->|
| | |<---TSChange----|
| | | |
Figure 5: "Prediction Success" Mode
(MN is both the receiver and the sender of the session)
Yi, et al. Expires August 12, 2007 [Page 15]
Internet-Draft Fast RSVP February 2007
MN PAR Error Correct
|----------------------------| | NAR NAR
| Mobile IP RSVP | | | |
| Module Module | | | |
|----------------------------| | | |
| | | | |
predict | | | |
handover | | | |
|------HF.ind----->| | | |
| |-----HF---->| | |
| | |----TPath--->| |
| | |<---TResv----| |
| |<---HFRsp---| | |
disconnect | | | |
| | | | |
connect | | | |
|--------------------------BU------------------------->|
| | |<---------BU----------|
| | |---------BAck-------->|
|<------------------------BAck-------------------------|
|----HFError.ind-->| | | |
| |---------------------HFError------>|
| | |<-------HFError-------|
| | |--------TPath-------->|
| | |<-------TResv---------|
| |---------------------HFTear------->|
| | |<-------HFTear--------|
| | |--TPathTear->| |
| | | | |
Figure 6: "Failure Recovery" Mode
(MN is the session receiver)
Yi, et al. Expires August 12, 2007 [Page 16]
Internet-Draft Fast RSVP February 2007
MN PAR Error Correct
|----------------------------| | NAR NAR
| Mobile IP RSVP | | | |
| Module Module | | | |
|----------------------------| | | |
| | | | |
predict | | | |
handover | | | |
|------HF.ind----->| | | |
| |------------HF----------->| |
| | |<---TPath----| |
| | |----TResv--->| |
| |<----------HFRsp----------| |
disconnect | | | |
| | | | |
connect | | | |
|--------------------------BU------------------------->|
| | |<---------BU----------|
| | |---------BAck-------->|
|<------------------------BAck-------------------------|
|----HFError.ind-->| | | |
| |---------------------HFError------>|
| | |<-------TPath---------|
| | |--------TResv-------->|
| |---------------------HFTear------->|
| | |<-------HFTear--------|
| | |--TResvTear->| |
| | | | |
Figure 7: "Failure Recovery" Mode
(MN is the session sender)
Yi, et al. Expires August 12, 2007 [Page 17]
Internet-Draft Fast RSVP February 2007
MN PAR Error Correct
|-------------------------| | NAR NAR
| Mobile IP RSVP | | | |
| Module Module | | | |
|-------------------------| | | |
| | | | |
predict | | | |
handover | | | |
|-----HF.ind---->| | | |
| |-HF(B=1)->| | |
| | |---TPath(B=1)--->| |
| | |<-----TResv------| |
| | |<-----TPath------| |
| | |------TResv----->| |
| | |<-----ResvConf---| |
| |<--HFRsp--| | |
disconnect | | | |
| | | | |
connect | | | |
|-----------------------BU---------------------------->|
| | |<------------BU-----------|
| | |-------------BAck-------->|
|<---------------------BAck----------------------------|
|--HFError.ind-->| | | |
| |---------------HFError(B=1)--------->|
| | |<-----HFError(B=1)--------|
| | |---------TPath(B=1)------>|
| | |<--------TResv------------|
| | |<--------TPath------------|
| | |---------TResv----------->|
| | |<--------ResvConf---------|
| |----------------HFTear(B=1)--------->|
| | |<------HFTear(B=1)--------|
| | |-TPathTear(B=1)->| |
| | |<---TPathTear----| |
| | | | |
Figure 8: "Failure Recovery" Mode
(MN is both the receiver and the sender of the session)
After MN becomes stable in the new subnet, the route optimization
process would start.
In the case that MN is the session receiver, CN is responsible for
initiating the reservation process on the optimized route. The
extensions proposed in this document introduce a new cache named
Pending Cache. In addition to maintaining a Binding Cache, the
Yi, et al. Expires August 12, 2007 [Page 18]
Internet-Draft Fast RSVP February 2007
mobile IP module of CN also maintains a Pending Cache. Every entry
in the Pending Cache contains a (home address, care-of address) pair.
When the mobile IP module of CN receives a BU message from MN, it
simply updates the corresponding entry of MN in the Pending Cache
(without updating the corresponding entry of MN in the Binding Cache)
and sends a SessionHandover.req to its RSVP module. Since the IP
layer of CN only checks the Binding Cache to decide the destination
addresses of the packets after it receives session data from the
upper layer, thus when to redirect session data to the new optimized
route is controlled entirely by the RSVP module. On receiving the
SessionHandover.req message, the RSVP module of CN checks whether the
mobile node (indicated in the SessionHandover.req message) has
multimedia sessions requiring resource reservation. If MN has no
such sessions, the RSVP module of CN immediately sends a
SessionHandover.ind message to the mobile IP module. If MN does have
sessions with resource reservation requirements, the RSVP module of
CN MUST start the resource reservation process on the optimized
route. Before the resource reservation process on the optimized
route completes, Binding Cache remains unchanged, so sessions between
CN and MN are still transmitted along the old route and the resource
reservation neighbor tunnel. Only after the RSVP module completes
the resource reservation on the optimized route and sends a
SessionHandover.ind message to the mobile IP module SHOULD the mobile
IP module update the corresponding entry of MN in the Binding Cache.
Then the session data is switched to the new optimized route and
seamless handover between the two routes without QoS degradation can
be achieved.
The reservation process on the optimized route when MN is the
receiver of the session is illustrated in Figure 9.
Yi, et al. Expires August 12, 2007 [Page 19]
Internet-Draft Fast RSVP February 2007
MN router CN
|--------------------| | |--------------------|
| Mobile IP RSVP | | | RSVP Mobile IP |
| Module Module | | | Module Module |
|--------------------| | |--------------------|
| | | | |
MN is stable | | | |
in new subnet | | | |
|-----------------------BU---------------------->|
|<---------------------BAck----------------------|
| | | |<-SH.req--|
| |<---Path-----|<---Path----| |
| |----Resv---->|----Resv--->| |
| | | |--SH.ind->|
| | | | redirect
| | | | session data
| | | | |
Figure 9: Reservation on the Optimized Route
(MN is session receiver)
In the case when MN is the session sender, MN itself is responsible
for initiating the reservation process on the optimized route. When
the mobile IP module of MN receives a BA message from CN, it sends a
SessionHandover.req to its RSVP module. When to redirect session
data to the new optimized route is then controlled entirely by the
RSVP module. On receiving the SessionHandover.req message, the RSVP
module of MN checks whether it has multimedia sessions requiring
resource reservation. If MN has no such sessions, its RSVP module
immediately sends a SessionHandover.ind message to the mobile IP
module. If MN does have sessions with resource reservation
requirements, its RSVP module MUST start the resource reservation
process on the optimized route. Before the resource reservation
process completes, sessions between MN and CN are still transmitted
along the old route and the resource reservation neighbor tunnel.
Only after the RSVP module completes resource reservation on the
optimized route and sends a SessionHandover.ind message to the mobile
IP module SHOULD the mobile IP module redirect the session data to
the new optimized route. Thus seamless handover between the two
routes without QoS degradation can be achieved.
The reservation process on the optimized route when MN is the sender
of the session is illustrated in Figure 10.
Yi, et al. Expires August 12, 2007 [Page 20]
Internet-Draft Fast RSVP February 2007
MN router CN
|--------------------| | |--------------------|
| Mobile IP RSVP | | | RSVP Mobile IP |
| Module Module | | | Module Module |
|--------------------| | |--------------------|
| | | | |
MN is stable | | | |
in new subnet | | | |
|-----------------------BU---------------------->|
|<---------------------BAck----------------------|
|--SH.req->| | | |
| |----Path---->|----Path--->| |
| |<---Resv-----|<---Resv----| |
|<-SH.ind--| | | |
redirect | | | |
session data | | | |
| | | | |
Figure 10: Reservation on the Optimized Route
(MN is session sender)
By exchanging Path and Resv messages between MN and CN, the resource
reservation process on the optimized route can be achieved. When the
mobile IP module of the intermediate router on the optimized route
receives a Path message, it sends the message to the RSVP module for
processing. After the RSVP module receives the Path message, it
checks whether it already has the corresponding Path State of the
session according to the "IPv6 HomeAddress" "DstPort" and "Protocol
Id" in the MSESSION object. If the corresponding Path State is
found, the RSVP module on the router only needs to update this state;
otherwise, it sets up the corresponding Path State for the session.
When the RSVP module completes processing the Path message, it would
send the message back to the mobile IP module. In addition, the RSVP
module on the router should notify the mobile IP module of MN's home
address by sending a AddrNotify.ind, so that the mobile IP module
could fill this address in "Type 2 Routing Header" (if MN is the
session receiver) or "Home address option" (if MN is the session
sender) when re-encapsulating the Path message. The scenario about
the process of the Path message on the intermediate router is
illustrated in the Figure 11.
Yi, et al. Expires August 12, 2007 [Page 21]
Internet-Draft Fast RSVP February 2007
|
|
|Path MN CN
| |--------------------| PATH |--------------------|
V-->| |------>| |
| Mobile IP | PATH | RSVP |
| Module |<------| Module |
| | AN.ind| |
|<--| |<------| |
| |--------------------| |--------------------|
|Path
V
Figure 11: Process of the Path Message on the
Intermediate Router
Yi, et al. Expires August 12, 2007 [Page 22]
Internet-Draft Fast RSVP February 2007
4. Details of RSVP Extensions
4.1. MN is the Receiver of the Session
When the mobile IP module of MN predicts that a handover event from
PAR to NAR is imminent, it sends an indication message
HandoverForecast.ind to the RSVP module. The HandoverForecast.ind
MUST contain the NCoA that will be used by MN in NAR's subnet. Then
the RSVP module:
1. extracts the NCoA and the home address from the
HandoverForecast.ind and then uses this information to form the
Router_Notify object (see section 6.2.2). The Router_Notify
object MUST contain the NCoA and Code 0 (see section 6.3.1.).
2. extracts the MSESSION object from the corresponding Path or Resv
State on MN and fills the "IPv6 DestAddress" field with NCoA to
form a new MSESSION object. Note that this new MSESSION object
corresponds to the tunnel reservation and MUST NOT affect the
MSESSION object in the Path or Resv State on MN.
3. uses the Router_Notify object formed in step 1 and the new
MSESSION formed in step 2 to construct a HandoverForecast message
with 'B' flag unset (see section 5.3) and sends it to the current
access router PAR.
When PAR receives the HandoverForecast message, it SHALL check the
'B' flag in Common Header to make sure it is unset, then the RSVP
module of it:
1. extracts the MN's NCoA and the Code in the Router_Notify object
and confirms that the Code is 0 (it means that the router acts as
PAR for MN).
2. looks up the matching Path State of the session according to the
"IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION
object that can be found in the HandoverForecast message and
extracts the SENDER_TSPEC (defines the traffic characteristics of
a sender's data flow) [3] contained in the matching Path State.
3. uses the SENDER_TSPEC and the MSESSION (copied from the
HandoverForecast message) to construct the TunnelPath message
with the 'B' flag unset. The TunnelPath message shares the same
format with the Path message, except that it has a different "Msg
Type" field value (see section 6.3.6.) in Common Header to
indicate that it corresponds to the tunnel resource reservation
and not to the usual resource reservation between the session
endpoints.
Yi, et al. Expires August 12, 2007 [Page 23]
Internet-Draft Fast RSVP February 2007
4. sets up the Path State according to the TunnelPath message and
sends it to MN's NCoA to establish the resource reservation
tunnel.
When intermediate routers receive the TunnelPath message, they set up
the Path State for the session according to the content of the
message and forward the message to the next hop. Finally, when the
router of the handover target subnet (NAR) receives the TunnelPath
message, it SHALL check the 'B' flag in Common Header to make sure it
is unset, then its RSVP module:
1. sets up the Path State according to the content of the TunnelPath
message.
2. acts as a RSVP proxy for MN, constructing a TunnelResv message
with 'B' flag unset and then sending it out on the reverse
direction to PAR. The TunnelResv message shares the same format
with the Resv message, except that it has a different "Msg Type"
(see section 6.3.7) field value in Common Header to indicate that
it corresponds to the tunnel resource reservation and not to the
usual resource reservation between the session endpoints.
3. sets up the Resv State according to the content of the TunnelResv
message.
When intermediate routers receive the TunnelResv message, they make
an advanced resource reservation for the session locally, set up the
corresponding Resv State and forward the TunnelResv message to the
previous hop.
Finally, when PAR receives the TunnelResv message, it sets up the
Resv State, and a resource reservation tunnel between PAR and NAR is
successfully built.
As a response to HandoverForecast message, PAR SHALL send a
HandoverForecastResponse message to MN indicating one of the
following possible conditions:
1. If the resource reservation tunnel establishment is successful,
PAR MUST construct a HandoverForecastResponse message with Code 0
in the Tunnel_Info object (see section 6.2.3) and send it to MN
indicating the successful establishment of the resource
reservation tunnel. The MSESSION object in this message is
copied from the corresponding Path or Resv State.
2. If the resource reservation tunnel establishment fails, PAR
SHOULD use a certain algorithm (e.g., the binary exponential
backoff algorithm) to retry the reservation procedure. Choosing
Yi, et al. Expires August 12, 2007 [Page 24]
Internet-Draft Fast RSVP February 2007
the appropriate algorithm is outside the scope of this document.
If the resource reservation on the tunnel fails even after
TPATH_RETRIES, PAR MUST assume that not enough resources are
available on the neighbor tunnel and then PAR SHALL construct a
HandoverForecastResponse message with Code 1 in the Tunnel_Info
object and send it to MN indicating the failure in building the
tunnel. The MSESSION object in this message is copied from the
corresponding Path or Resv State.
If MN receives a HandoverForecastResponse message with Code 1 or even
if it doesn't receive the HandoverForecastResponse message until the
handover occurs, it MUST skip the step of resource reservation on the
tunnel and process the optimized route resource reservation step
described below.
After MN hands over to a new subnet, its mobile IP module sends a BU
message to PAR, so PAR can redirect the session data to MN's new
position. In addition, the mobile IP module of MN MUST check whether
the current subnet is the same as the predicted handover target
subnet. Then depending on the result of this check, MN MUST take one
of the following actions:
1. If the handover prediction is successful, the mobile IP module of
MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
When the RSVP module of MN receives this indication, it MUST
construct a HandoverForecastConfirm message with the 'B' flag
unset and send it to PAR. The MSESSION object in this message is
copied from the corresponding Path or Resv State but with the
"IPv6 DestAddress" field changed to MN's NCoA.
2. If the handover prediction fails, the mobile IP module of MN MUST
send a HandoverForecastError.ind to the RSVP module. This
indication message MUST contain the current in use CoA and the
formerly falsely predicted CoA of MN. When the RSVP module of MN
receives this indication message, it MUST construct a
HandoverForecastError message with the Router_Notify object
including the current in use CoA as well as Code 0 and then send
the message to PAR directly. The 'B' flag in this message MUST
be unset. The MSESSION object in this message is copied from the
corresponding Path or Resv State but with the "IPv6 DestAddress"
field changed to MN's NCoA. MN MUST also construct a
HandoverForecastTear message containing the formerly falsely
predicted CoA and send the message to PAR directly. The 'B' flag
in this message MUST be unset. The MSESSION object in this
message is copied from the corresponding Path or Resv State but
with the "IPv6 DestAddress" field changed to MN's NCoA.
If the handover event doesn't occur within a certain time, the mobile
Yi, et al. Expires August 12, 2007 [Page 25]
Internet-Draft Fast RSVP February 2007
IP module of MN MUST also construct a HandoverForecastTear message
containing the formerly falsely predicted CoA and send the message to
PAR directly. The 'B' flag in this message MUST be unset. The
MSESSION object in this message is copied from the corresponding Path
or Resv State but with the "IPv6 DestAddress" field changed to MN's
NCoA.
When receiving the HandoverForecastConfirm message, PAR SHALL check
the 'B' flag in Common Header to make sure it is unset, then it MUST
send a TunnelStateChange message with 'B' flag unset and send the
message to NAR. The MSESSION object in this message is copied from
the HandoverForecastConfirm message so the intermediate routers can
change the reservation type (see section 5.4).
When receiving the HandoverForecastError message, PAR SHALL check to
make sure that the 'B' flag in Common Header is unset and the Code in
Router_Notify object is filled with 0. Then it MUST extract MN's
current in use CoA and send a new TunnelPath message with 'B' flag
unset to MN's current subnet (e.g. Correct NAR in Figure 6). The
MSESSION object in this message is copied from the
HandoverForecastError message. When receiving this TunnelPath
message, NAR MUST reply with a TunnelResv message with the 'B' flag
unset so that resource reservation on the correct tunnel can be
established.
When receiving the HandoverForecastTear message, PAR SHALL check the
'B' flag in Common Header to make sure it is unset, then it MUST
extract the MN's formerly falsely predicted CoA and send a
TunnelPathTear message with the 'B' flag unset to MN's falsely
predicted subnet (e.g. Error NAR in Figure 6). The MSESSION object
in this message is copied from the HandoverForecastTear message.
When receiving this message, intermediate routers MUST remove the
corresponding Path State and Resv State so that the resources
reserved in advance on the falsely built tunnel can be released.
When MN gets stable in the handover target subnet, it sends a BU
message to CN. After the mobile IP module of CN receives this BU
message, in addition to replying with a BA message to MN, the mobile
IP module of CN also takes the following actions:
1. extracts MN's home address and NCoA (included in the BU message)
and updates the corresponding entry of MN in the Pending Cache
(see section 3.1.) to record the (home address, NCoA) pair.
2. sends a SessionHandover.req to the RSVP module inquiring whether
or not to redirect the session data to the new optimized route.
The SessionHandover.req MUST contain the (home address, NCoA)
pair of MN.
Yi, et al. Expires August 12, 2007 [Page 26]
Internet-Draft Fast RSVP February 2007
On receiving the SessionHandover.req, the RSVP module of CN MUST try
to lookup the matching Path or Resv State according to the home
address of MN. Then:
1. If matching Path or Resv State is not found, it means that MN
doesn't have any multimedia sessions requiring resource
reservation. Then the RSVP module MUST immediately send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
the MN.
2. If matching Path or Resv State is found, it means that MN does
have multimedia sessions requiring resource reservation. Then
the RSVP module of CN MUST initiate the resource reservation
process on the optimized route. The RSVP module of CN generates
the Path message with the 'B' flag unset and sends it to MN. In
addition, the RSVP module updates the corresponding Path state
(especially updating the IPv6 DestAddr field of the MSESSION with
MN's NCoA). The MSESSION object in the Path message MUST contain
the NCoA as well as the home address of MN. The SENDER_TSPEC in
the Path message MUST be extracted from the corresponding Path
State of MN. After an intermediate RSVP router on the
transmission path receives the Path message, it MUST check
whether it already has the corresponding Path State of the
session according to the "IPv6 HomeAddress" "DstPort" and
"Protocol Id" in the MSESSION object. If the corresponding Path
State is found, the RSVP module on the router only needs to
update this state (especially updating the IPv6 DestAddr field of
the MSESSION with MN's NCoA); otherwise, it MUST set up the
corresponding Path State for the session. In addition, the RSVP
module on the router MUST send an AddrNotify.ind to the mobile IP
module to indicate MN's home address and NCoA, so that the mobile
IP module could fill these addresses in "Type 2 Routing Header"
and the IP header when re-encapsulating the Path message. After
the Path message corresponding to the optimized route finally
reaches MN, MN SHALL check the 'B' flag in Common Header to make
sure it is unset, then the RSVP module of MN replies with the
proper Resv message with the 'B' flag unset and updates the
corresponding Path and Resv state (especially updating the IPv6
DestAddr field of the MSESSION with MN's NCoA). After an
intermediate RSVP router on the transmission path receives the
Resv message, it checks whether it already has the corresponding
Resv State of the session according to the "IPv6 HomeAddress"
"DstPort" and "Protocol Id" in the MSESSION object. If the
corresponding Resv State is found, the RSVP module on the router
only needs to update this state (especially updating the IPv6
DestAddr field of the MSESSION with MN's NCoA); otherwise, it
tries to reserve resources for the session locally and set up the
Yi, et al. Expires August 12, 2007 [Page 27]
Internet-Draft Fast RSVP February 2007
corresponding Resv State. Finally, when the RSVP module of CN
receives the Resv message and updates the corresponding Resv
state (especially updating the IPv6 DestAddr field of the
MSESSION with MN's NCoA), the resource reservation process on the
optimized route successfully completes. Then the RSVP module
MUST send a SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
MN. If the reservation on the optimizated route fails, CN SHOULD
use a certain algorithm (e.g., the binary exponential backoff
algorithm) to retry the reservation process. The choice of the
appropriate algorithm is outside the scope of this document. If
the resource reservation on the optimized route fails even after
the ROPATH_RETRIES, CN MUST assume that resources are not
available on the optimized route. Then session data from CN to
MN SHALL be kept transmitting along the old resource reservation
path and the resource reservation neighbor tunnel.
On receiving the SessionHandover.ind, the mobile IP module of CN MUST
update the proper entry in the Bindng Cache according to the (home
address, NCoA) pair of MN which can be extracted from the
SessionHandover.ind, thus session data is redirected to the optimized
route from then on.
4.2. MN is the Sender of the Session
When the mobile IP module of MN predicts that a handover event from
PAR to NAR is imminent, it sends an indication message
HandoverForecast.ind to the RSVP module. The HandoverForecast.ind
MUST contain the PAR's IP address. Then the RSVP module:
1. extracts the NCoA and the home address from the
HandoverForecast.ind and then uses this information to form the
Router_Notify object (see secton 6.2.2). The Router_Notify
object MUST contain the PAR's IP address and Code 1 (see section
6.3.1.),
2. extracts the MSESSION object from the corresponding Path or Resv
State on MN and fills the "IPv6 DestAddress" field with PAR's IP
address to form a new MSESSION object. Note that this new
MSESSION object corresponds to the tunnel reservation and MUST
NOT affect the MSESSION object in the Path or Resv State on MN.
3. uses the Router_Notify object formed in step 1 and the new
MSESSION formed in step 2 to construct a HandoverForecast message
with 'B' flag unset (see section 5.3) and sends it to the
predicted access router NAR. The SENDER_TSPEC object in this
message is copied from the corresponding Path state.
Yi, et al. Expires August 12, 2007 [Page 28]
Internet-Draft Fast RSVP February 2007
When NAR receives the HandoverForecast message, it SHALL check the
'B' flag in Common Header to make sure it is unset, then the RSVP
module of it:
1. extracts the PAR's IP address and the Code in the Router_Notify
object that can be found in the HandoverForecast message and
confirms that the Code is 1 (it means that the router acts as NAR
for MN),
2. extracts the SENDER_TSPEC object and the MSESSION object both of
which are included in the HandoverForecast message.
3. acts as an RSVP proxy of MN and uses the SENDER_TSPEC object as
well as the MSESSION object to construct the TunnelPath message
with the 'B' flag unset. The TunnelPath message shares the same
format with the Path message, except that it has a different "Msg
Type" field value in Common Header to indicate that it
corresponds to the tunnel resource reservation and not to the
usual resource reservation between the session endpoints.
4. sets up the Path State of the session accordingly and sends the
TunnelPath message to PAR.
When intermediate routers receive the TunnelPath message, they set up
the Path State for the session according to the content of the
message and forward the message to the next hop. Finally, when PAR
receives the TunnelPath message, it SHALL check the 'B' flag in
Common Header to make sure it is unset, then its RSVP module:
1. sets up the Path State according to the content of the TunnelPath
message.
2. constructs a TunnelResv message with the 'B' flag unset and then
sends it out on the reverse direction to NAR. The TunnelResv
message shares the same format with the Resv message, except that
it has a different "Msg Type" (see section 6.3.7) field value in
Common Header to indicate that it corresponds to the tunnel
resource reservation and not to the usual resource reservation
between the session endpoints.
3. sets up the Resv State according to the content of the TunnelResv
message.
When intermediate routers receive the TunnelResv message, they make
an advanced resource reservation for the session locally, set up the
corresponding Resv State and forward the TunnelResv message to the
previous hop.
Yi, et al. Expires August 12, 2007 [Page 29]
Internet-Draft Fast RSVP February 2007
Finally, when NAR receives the TunnelResv message, it sets up the
Resv State, and a resource reservation tunnel between NAR and PAR is
successfully built.
As a response to HandoverForecast message, NAR SHALL send a
HandoverForecastResponse message to MN indicating one of the
following possible conditions:
1. If the resource reservation tunnel establishment is successful,
NAR MUST construct a HandoverForecastResponse message with Code 0
in the Tunnel_Info object (see section 6.2.3) and send it to MN
indicating the successful establishment of the resource
reservation tunnel. The MSESSION object in this message is
copied from the corresponding Path or Resv State.
2. If the resource reservation tunnel establishment fails, NAR
SHOULD use a certain algorithm (e.g., the binary exponential
backoff algorithm) to retry the reservation procedure. The
choice of the appropriate algorithm is outside the scope of this
document. If the resource reservation on the tunnel fails even
after TPATH_RETRIES, NAR MUST assume that not enough resources
are available on the neighbor tunnel and then NAR SHOULD
construct a HandoverForecastResponse message with Code 1 in the
Tunnel_Info object and send it to MN indicating the failure in
building the tunnel. The MSESSION object in this message is
copied from the corresponding Path or Resv State.
If MN receives a HandoverForecastResponse message with Code 1 or even
if it doesn't receive the HandoverForecastResponse message until the
handover occurs, it MUST skip the step of resource reservation on the
tunnel and process the optimized route resource reservation step
described below.
After MN hands over to a new subnet, its mobile IP module sends a BU
message to PAR, so PAR can redirect the session data to MN's new
position. In addition, the mobile IP module of MN MUST check whether
the current subnet is the same as the predicted handover target
subnet. Then depending on the result of this check, MN MUST take one
of the following actions:
1. If the handover prediction is successful, the mobile IP module of
MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
When the RSVP module of MN receives this indication, it MUST
construct a HandoverForecastConfirm message with the 'B' flag
unset and send it to NAR. The MSESSION object in this message is
copied from the corresponding Path or Resv State but with the
"IPv6 DestAddress" field changed to PAR's IP address.
Yi, et al. Expires August 12, 2007 [Page 30]
Internet-Draft Fast RSVP February 2007
2. If the handover prediction fails, the mobile IP module of MN MUST
send a HandoverForecastError.ind to the RSVP module. This
indication message MUST contain the current in use CoA and the
formerly falsely predicted CoA of MN. When the RSVP module of MN
receives this indication message, it MUST construct a
HandoverForecastError message with the Router_Notify object
including the IP address of MN's previous access router (PAR) as
well as Code 1 and then send the message to NAR directly. The
'B' flag in this message MUST be unset. The MSESSION object in
this message is copied from the corresponding Path or Resv State
but with the "IPv6 DestAddress" field changed to PAR's IP
address. The SENDER_TSPEC object in this message is copied form
the corresponding Path state. MN MUST also construct a
HandoverForecastTear message containing the formerly falsely
predicted CoA and send the message to PAR directly. The 'B' flag
in this message MUST be unset. The MSESSION object in this
message is copied from the corresponding Path or Resv State but
with the "IPv6 DestAddress" field changed to PAR's IP address.
If the handover event doesn't occur within a certain time, the mobile
IP module of MN MUST also construct a HandoverForecastTear message
containing the formerly falsely predicted CoA and send the message to
PAR directly. The 'B' flag in this message MUST be unset. The
MSESSION object in this message is copied from the corresponding Path
or Resv State but with the "IPv6 DestAddress" field changed to PAR's
IP address.
When receiving the HandoverForecastConfirm message, NAR SHALL check
the 'B' flag in Common Header to make sure it is unset, then it MUST
send a TunnelStateChange message with the 'B' flag unset to PAR, the
MSESSION object in this message is copied from the
HandoverForecastConfirm message so that the intermediate routers can
change the reservation type (see section 5.4).
When receiving the HandoverForecastError message, NAR SHALL check to
make sure that the 'B' flag in Common Header is unset and the Code in
Router_Notify object is filled with 1, then it MUST extract PAR's IP
address and send a new TunnelPath message with the 'B' flag unset to
PAR. The MSESSION object and the SENDER_TSPEC object in this message
are copied from the HandoverForecastError message. When receiving
this TunnelPath message, PAR MUST reply with a TunnelResv message
with the 'B' flag unset so that the resource reservation on the
correct tunnel can be established.
When receiving the HandoverForecastTear message, PAR SHALL check the
'B' flag in Common Header to make sure it is unset, then it MUST
extract the MN's formerly falsely predicted CoA and send a
TunnelResvTear message with the 'B' flag unset to MN's falsely
Yi, et al. Expires August 12, 2007 [Page 31]
Internet-Draft Fast RSVP February 2007
predicted subnet (e.g. Error NAR in Figure 7). The MSESSION object
in this message is copied from the HandoverForecastTear message.
When receiving this message, intermediate routers MUST remove the
corresponding Resv State so that the resources reserved in advance on
the falsely built tunnel can be released.
When MN gets stable in the handover target subnet, it sends a BU
message to CN and receives a BA message from CN. After that, the
mobile IP module of MN sends a SessionHandover.req to the RSVP module
inquiring whether or not to redirect the session data to the new
optimized route. The SessionHandover.req MUST contain the (home
address, NCoA) pair of the MN.
On receiving the SessionHandover.req, the RSVP module of MN MUST try
to lookup the matching Path or Resv State according to the home
address of MN. Then:
1. If matching Path or Resv State is not found, it means that MN
doesn't have any multimedia sessions requiring resource
reservation. Then the RSVP module MUST immediately send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
the MN.
2. If matching Path or Resv State is found, it means that MN does
have multimedia sessions requiring resource reservation. Then
the RSVP module of MN MUST initiate the resource reservation
process on the optimized route. The RSVP module of MN generates
the Path message with the 'B' flag unset and sends it to CN. The
SENDER_TSPEC in the Path message MUST be extracted from the
corresponding Path State of the MN. After an intermediate RSVP
router on the transmission path receives the Path message, it
MUST check whether it already has a corresponding Path State of
the session according to the "IPv6 HomeAddress" "DstPort" and
"Protocol Id" in the MSESSION object. If the corresponding Path
State is found, the RSVP module on the router only needs to
update this state; otherwise, it MUST set up the corresponding
Path State for the session. In addition, the RSVP module on the
router MUST send an AddrNotify.ind to the mobile IP module to
indicate MN's home address and NCoA so that the mobile IP module
could fill these addresses in "Home Address Option" [2] and the
IP header when re-encapsulating the Path message. When the Path
message corresponding to the optimized route finally reaches CN,
CN SHALL check the 'B' flag in Common Header to make sure it is
unset, then the RSVP module of CN replies with the proper Resv
message with the 'B' flag unset. After an intermediate RSVP
router on the transmission path receives the Resv message, it
checks whether it already has the corresponding Resv State of the
Yi, et al. Expires August 12, 2007 [Page 32]
Internet-Draft Fast RSVP February 2007
session according to the "IPv6 HomeAddress" "DstPort" and
"Protocol Id" in the MSESSION object. If the corresponding Resv
State is found, the RSVP module on the router only needs to
update this state; otherwise, it tries to reserve resources for
the session locally and set up the corresponding Resv State.
Finally, when the RSVP module of MN receives the Resv message,
the resource reservation process on the optimized route
successfully completes. Then the RSVP module MUST send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
MN. If the reservation on the optimizated route fails, MN SHOULD
use a certain algorithm (e.g., the binary exponential backoff
algorithm) to retry the reservation process. The choice of the
appropriate algorithm is outside the scope of this document. If
the resource reservation on the optimized route fails even after
the ROPATH_RETRIES, MN MUST assume that resources are not
available on the optimized route. Then session data from MN to
CN SHALL be kept transmitting along the old resource reservation
path and the resource reservation neighbor tunnel.
On receiving the SessionHandover.ind, the mobile IP module of MN MUST
redirect the session data to the optimized route and utilize Home
Address Option to send packets from then on.
4.3. MN is both the Sender and the Receiver of the Session
When the mobile IP module of MN predicts that a handover event from
PAR to NAR is imminent, it sends an indication message
HandoverForecast.ind to the RSVP module. The HandoverForecast.ind
MUST contain the NCoA that will be used by MN in NAR's subnet. Then
the RSVP module:
1. extracts the NCoA and the home address from the
HandoverForecast.ind and then uses this information to form the
Router_Notify object (see section 6.2.2). The Router_Notify
object MUST contain the NCoA and Code 0 (see section 6.3.1),
2. extracts the MSESSION object from the corresponding Path or Resv
State on MN and fills the "IPv6 DestAddress" field with NCoA to
form a new MSESSION object. Note that this new MSESSION object
corresponds to the tunnel reservation and MUST NOT affect the
MSESSION object in the Path or Resv State on MN.
3. uses the Router_Notify object formed in step 1 and the new
MSESSION formed in step 2 to construct a HandoverForecast message
and sends it to the current access router PAR. The 'B' flag in
the Common Header of the HandoverForecast message MUST be set
(see section 5.3) to inform PAR that the reservation is
Yi, et al. Expires August 12, 2007 [Page 33]
Internet-Draft Fast RSVP February 2007
bidirectional.
When PAR receives the HandoverForecast message, it SHALL check the
'B' flag in Common Header to make sure it is set, then its RSVP
module:
1. extracts the MN's NCoA and the Code in the Router_Notify object
and confirms that the Code is 0 (it means that the router acts as
PAR for MN),
2. looks up the matching Path State of the session according to the
"IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION
object that can be found in the HandoverForecast message and
extracts the SENDER_TSPEC (defines the traffic characteristics of
a sender's data flow) [3] contained in the matching Path State,
3. uses the SENDER_TSPEC and the MSESSION (copied from the
HandoverForecast message) to construct the TunnelPath message
with the 'B' flag set. The TunnelPath message shares the same
format with the Path message, except that it has a different "Msg
Type" field value (see section 6.3.6) in Common Header to
indicate that it corresponds to the tunnel resource reservation
and not to the usual resource reservation between the session
endpoints.
4. sets up the Path State according to the TunnelPath message and
sends it to MN's NCoA to establish the resource reservation
tunnel.
When intermediate routers receive the TunnelPath message, they set up
the Path State for the session according to the content of the
message and forward the message to the next hop. Finally, when the
router of the handover target subnet (NAR) receives the TunnelPath
message, it SHALL check the 'B' flag in Common Header to make sure it
is set (If MN is both the sender and receiver of the session, this
flag bit is always set), then its RSVP module:
1. sets up the Path State according to content of the TunnelPath
message.
2. acts as an RSVP proxy for MN, constructing a TunnelResv message
with the 'B' flag unset and then sending it out on the reverse
direction to PAR. The TunnelResv message shares the same format
with the Resv message, except that it has a different "Msg Type"
(see section 6.3.7) field value in Common Header to indicate that
it corresponds to the tunnel resource reservation and not to the
usual resource reservation between the session endpoints.
Yi, et al. Expires August 12, 2007 [Page 34]
Internet-Draft Fast RSVP February 2007
3. sets up the Resv State according to the content of the TunnelResv
message.
4. extracts the MSESSION object from the TunnelPath message received
from PAR and changes the "IPv6 DestAddress" field with PAR's IP
address to form a new MSESSION object. This new MSESSION object
corresponds to the resource reservation on the reverse direction
from NAR to PAR.
5. constructs a new TunnelPath message. This message MUST include
the new MSESSION object formed in step 4 as well as the
SENDER_TSPEC object copied from the TunnelPath message received
from PAR. Note that the 'B' flag in this message MUST be unset.
6. sends the TunnelPath message formed in step 5 to PAR so that the
reservation on the reverse direction can be established.
When intermediate routers receive the TunnelResv message, they make
an advanced resource reservation for the session locally, set up the
corresponding Resv State and forward the TunnelResv message to the
previous hop.
When intermediate routers receive the TunnelPath message
corresponding to the resource reservation on the reverse direction,
they set up the Path State for the session according to the content
of the message and forward the message to the next hop.
When PAR receives the TunnelPath message from NAR, it MUST reply a
TunnelResv message (including the RESV_CONFIRM object) to NAR. So
when the reservation on the reverse direction completes, NAR will
reply with a ResvConf message.
Finally, when PAR receives both the TunnelResv message and the
ResvConf message from NAR, the birectional reservation is
successfully established.
As a response to HandoverForecast message, PAR SHALL send a
HandoverForecastResponse message to MN indicating one of the
following possible conditions:
1. If the resource reservation tunnel establishment is successful,
PAR MUST construct a HandoverForecastResponse message with Code 0
in the Tunnel_Info object (see section 6.2.3) and send it to MN
indicating the successful establishment of the resource
reservation tunnel. The MSESSION object in this message is
copied from the corresponding Path or Resv State.
Yi, et al. Expires August 12, 2007 [Page 35]
Internet-Draft Fast RSVP February 2007
2. If the resource reservation tunnel establishment from PAR to NAR
fails, PAR SHOULD use a certain algorithm (e.g., the binary
exponential backoff algorithm) to retry the reservation
procedure. If the resource reservation tunnel establishment from
NAR to PAR fails, NAR SHOULD use a certain algorithm (e.g., the
binary exponential backoff algorithm) to retry the reservation
procedure. The choice of the appropriate algorithm is outside
the scope of this document. If the resource reservation on the
tunnel from NAR to PAR fails even after TPATH_RETRIES, NAR MUST
assume that not enough resources are available on the neighbor
tunnel and give up. If the resource reservation on the tunnel
from PAR to NAR fails even after TPATH_RETRIES or PAR doesn't
receive ResvConf message from NAR within CONF_TIMEOUT, PAR MUST
assume that the bidirectional resource reservation tunnel cannot
be built, and then PAR SHALL construct a HandoverForecastResponse
message with Code 1 in the Tunnel_Info object and send it to MN
indicating the failure in building the tunnel. The MSESSION
object in this message is the same as that in the original
HandoverForecast message from MN.
If MN receives a HandoverForecastResponse message with Code 1 or even
if it doesn't receive the HandoverForecastResponse message until the
handover occurs, it MUST skip the step of resource reservation on the
tunnel and process the optimized route resource reservation step
described below.
After MN hands over to a new subnet, its mobile IP module sends a BU
message to PAR, so PAR can redirect the session data to MN's new
position. In addition, the mobile IP module of MN MUST check whether
the current subnet is the same as the predicted handover target
subnet. Then depending on the result of this check, MN MUST take one
of the following actions:
1. If the handover prediction is successful, the mobile IP module of
MN MUST send a HandoverForecastConfirm.ind to the RSVP module.
When the RSVP module of MN receives this indication, it MUST
construct a HandoverForecastConfirm message and send it to PAR.
The MSESSION object in this message is copied from the
corresponding Path or Resv State but with the "IPv6 DestAddress"
field changed to MN's NCoA. The 'B' flag in the Common Header of
this HandoverForecastConfirm message MUST be set (see section
5.3) to inform PAR that the reservation is bidirectional.
2. If the handover prediction fails, the mobile IP module of MN MUST
send a HandoverForecastError.ind to the RSVP module. This
indication message MUST contain the current in use CoA and the
formerly falsely predicted CoA of MN. When the RSVP module of MN
receives this indication message, it MUST construct a
Yi, et al. Expires August 12, 2007 [Page 36]
Internet-Draft Fast RSVP February 2007
HandoverForecastError message with the Router_Notify object
including the current in use CoA as well as Code 0 and then send
the message to PAR directly. The MSESSION object in this message
is copied from the corresponding Path or Resv State but with the
"IPv6 DestAddress" field changed to MN's NCoA. MN MUST also
construct a HandoverForecastTear message containing the formerly
falsely predicted CoA and send the message to PAR directly. The
MSESSION object in this message is copied from the corresponding
Path or Resv State but with the "IPv6 DestAddress" field changed
to MN's NCoA. The 'B' flag in the Common Header of both the
HandoverForecastError and HandoverForecastTear message MUST be
set (see section 5.3) to inform PAR the reservation is
bidirectional.
If the handover event doesn't occur within a certain time, the mobile
IP module of MN MUST also construct a HandoverForecastTear message
containing the formerly falsely predicted CoA and send the message to
PAR directly. The MSESSION object in this message is copied from the
corresponding Path or Resv State but with the "IPv6 DestAddress"
field changed to MN's NCoA. The 'B' flag in the Common Header of
this HandoverForecastTear message MUST be set (see section 5.3) to
inform PAR that the reservation is bidirectional.
When receiving the HandoverForecastConfirm message, PAR SHALL check
the 'B' flag in Common Header to make sure it is set, then it MUST
construct a TunnelStateChange message and send it to NAR. The
MSESSION object in this message is copied from the
HandoverForecastConfirm message and the 'B' flag in the message MUST
be set. When NAR receives the TunnelStateChange message, it SHALL
check the 'B' flag in Common Header to make sure it is set, then NAR
MUST reply with a TunnelStateChange message with the 'B' flag unset
so that the intermediate routers on the bidirectional path can change
the reservation type (see section 5.4).
When receiving the HandoverForecastError message, PAR SHALL check to
make sure that the 'B' flag in Common Header is set and the Code in
Router_Notify object is filled with 0, then it MUST extract MN's
current in use CoA and send a new TunnelPath message with the 'B'
flag set to MN's current subnet (e.g. Correct NAR in Figure 8), the
MSESSION object in this message is copied from the
HandoverForecastError message. When receiving this TunnelPath
message, NAR MUST reply with a TunnelResv message. In addition, NAR
MUST also send a TunnelPath message on the reverse direction with the
same SENDER_TSPEC object but with the 'B' flag unset so that the
bidirectional resource reservation on the neighbor tunnel can be
established.
When receiving the HandoverForecastTear message, PAR SHALL check the
Yi, et al. Expires August 12, 2007 [Page 37]
Internet-Draft Fast RSVP February 2007
'B' flag in Common Header to make sure it is set, then it MUST
extract the MN's formerly falsely predicted CoA and send a
TunnelPathTear message with the 'B' flag set to MN's falsely
predicted subnet (e.g. Error NAR in Figure 8), the MSESSION object
in this message is copied from the HandoverForecastTear message.
When receiving this message, intermediate routers MUST remove the
corresponding Path State and Resv State. When NAR receivers this
message, it SHALL check to make sure that the 'B' flag in Common
Header is set, then NAR MUST send a TunnelPathTear message on the
reverse direction with the same SENDER_TSPEC object and with the 'B'
flag unset so that the bidirectional resources reserved in advance on
the falsely built tunnel can be released.
When MN is both the receiver and the sender of the session, the
resource reservation process on the optimized route can be divided
into two parts: the reservation from CN to MN and the reservation
from MN to CN. CN is responsible for the former part and MN is
responsible for the latter part.
When MN gets stable in the handover target subnet, it sends a BU
message to CN. After the mobile IP module of CN receives this BU
message, in addition to replying with a BA message to MN, the mobile
IP module of CN also takes the following actions:
1. extracts MN's home address and NCoA (included in the BU message)
and updates the corresponding entry of the MN in its Pending
Cache (see section 3.1.) to record the (home address, NCoA) pair.
2. sends a SessionHandover.req to the RSVP module inquiring whether
or not to redirect the session data to the new optimized route.
The SessionHandover.req MUST contain the (home address, NCoA)
pair of MN.
On receiving the SessionHandover.req, the RSVP module of CN MUST try
to lookup the matching Path or Resv State according to the home
address of MN. Then:
1. If matching Path or Resv State is not found, it means that MN
doesn't have any multimedia sessions requiring resource
reservation. Then the RSVP module MUST immediately send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
the MN.
2. If matching Path or Resv State is found, it means that MN does
have multimedia sessions requiring resource reservation. Then
the RSVP module of CN MUST initiate the resource reservation
process on the optimized route. The RSVP module of CN generates
Yi, et al. Expires August 12, 2007 [Page 38]
Internet-Draft Fast RSVP February 2007
the Path message with the 'B' flag unset and sends it to MN as
well as updates the corresponding Path state (especially updating
the IPv6 DestAddr field of the MSESSION with MN's NCoA). The
MSESSION object in the Path message MUST contain the NCoA as well
as the home address of MN. The SENDER_TSPEC in the Path message
MUST be extracted from the corresponding Path State of MN. After
an intermediate RSVP router on the transmission path receives the
Path message, it MUST check whether it already has the
corresponding Path State of the session according to the "IPv6
HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object.
If the corresponding Path State is found, the RSVP module on the
router only needs to update this state (especially updating the
IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise,
it MUST set up the corresponding Path State for the session. In
addition, the RSVP module on the router MUST send an
AddrNotify.ind to the mobile IP module to indicate MN's home
address and NCoA, so that the mobile IP module could fill these
addresses in "Type 2 Routing Header" and the IP header when re-
encapsulating the Path message. After the Path message
corresponding to the optimized route finally reaches MN, the RSVP
module of MN replies with the proper Resv message as well as
updates the corresponding Path and Resv state (especially
updating the IPv6 DestAddr field of the MSESSION with MN's NCoA).
After an intermediate RSVP router on the transmission path
receives the Resv message, it checks whether it already has the
corresponding Resv State of the session according to the "IPv6
HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object.
If the corresponding Resv State is found, the RSVP module on the
router only needs to update this state (especially updating the
IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise,
it tries to reserve resources for the session locally and set up
the corresponding Resv State. Finally, when the RSVP module of
CN receives the Resv message and updates the corresponding Resv
state (especially updating the IPv6 DestAddr field of the
MSESSION with MN's NCoA), the resource reservation process on the
optimized route from CN to MN is successfully completed. Then
the RSVP module MUST send a SessionHandover.ind to the mobile IP
module. The SessionHandover.ind MUST contain the (home address,
NCoA) pair of MN. If the reservation on the optimizated route
fails, CN SHOULD use a certain algorithm (e.g., the binary
exponential backoff algorithm) to retry the reservation process.
The choice of the appropriate algorithm is outside the scope of
this document. If the resource reservation on the optimized
route fails even after the ROPATH_RETRIES, CN MUST assume that
resources are not available on the optimized route. Then session
data from CN to MN SHALL be kept transmitting along the old
resource reservation path and the resource reservation neighbor
tunnel.
Yi, et al. Expires August 12, 2007 [Page 39]
Internet-Draft Fast RSVP February 2007
On receiving the SessionHandover.ind, the mobile IP module of CN MUST
update the proper entry in the Binding Cache according to the (home
address, NCoA) pair of MN which can be extracted from the
SessionHandover.ind, thus session data from CN to MN is redirected to
the optimized route from then on.
In addition, when MN receives the BA message from CN, the mobile IP
module of MN sends a SessionHandover.req to the RSVP module inquiring
whether or not to redirect the session data to the new optimized
route. The SessionHandover.req MUST contain the (home address, NCoA)
pair of the MN.
On receiving the SessionHandover.req, the RSVP module of MN MUST try
to lookup the matching Path or Resv State according to the home
address of MN. Then:
1. If matching Path or Resv State is not found, it means that MN
doesn't have any multimedia sessions requiring resource
reservation. Then the RSVP module MUST immediately send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
the MN.
2. If matching Path or Resv State is found, it means that MN does
have multimedia sessions requiring resource reservation. Then
the RSVP module of MN MUST initiate the resource reservation
process on the optimized route. The RSVP module of MN generates
the Path message with the 'B' flag unset and sends it to CN. The
SENDER_TSPEC in the Path message MUST be extracted from the
corresponding Path State of the MN. After an intermediate RSVP
router on the transmission path receives the Path message, it
MUST check whether it already has a corresponding Path State of
the session according to the "IPv6 HomeAddress" "DstPort" and
"Protocol Id" in the MSESSION object. If the corresponding Path
State is found, the RSVP module on the router only needs to
update this state; otherwise, it MUST set up the corresponding
Path State for the session. In addition, the RSVP module on the
router MUST send an AddrNotify.ind to the mobile IP module to
indicate MN's home address and NCoA so that the mobile IP module
could fill these addresses in "Home Address Option" [2] and the
IP header when re-encapsulating the Path message. When the Path
message corresponding to the optimized route finally reaches CN,
CN SHALL check the 'B' flag in Common Header to make sure it is
unset, then the RSVP module of CN replies with the proper Resv
message with the 'B' flag unset. After an intermediate RSVP
router on the transmission path receives the Resv message, it
checks whether it already has the corresponding Resv State of the
session according to the "IPv6 HomeAddress" "DstPort" and
Yi, et al. Expires August 12, 2007 [Page 40]
Internet-Draft Fast RSVP February 2007
"Protocol Id" in the MSESSION object. If the corresponding Resv
State is found, the RSVP module on the router only needs to
update this state; otherwise, it tries to reserve resources for
the session locally and set up the corresponding Resv State.
Finally, when the RSVP module of MN receives the Resv message,
the resource reservation process on the optimized route
successfully completes. Then the RSVP module MUST send a
SessionHandover.ind to the mobile IP module. The
SessionHandover.ind MUST contain the (home address, NCoA) pair of
MN. If the reservation on the optimizated route fails, MN SHOULD
use a certain algorithm (e.g., the binary exponential backoff
algorithm) to retry the reservation process. The choice of the
appropriate algorithm is outside the scope of this document. If
the resource reservation on the optimized route fails even after
the ROPATH_RETRIES, MN MUST assume that resources are not
available on the optimized route. Then session data from MN to
CN SHALL be kept transmitting along the old resource reservation
path and the resource reservation neighbor tunnel.
On receiving the SessionHandover.ind, the mobile IP module of MN MUST
redirect the session data to the optimized route and utilize Home
Address Option to send packets, thus session data from MN to CN is
redirected to the optimized route from then on.
Yi, et al. Expires August 12, 2007 [Page 41]
Internet-Draft Fast RSVP February 2007
5. Miscellaneous
5.1. RSVP Extensions Capability Exchange
The MN expects a HandoverForecastResponse message in response to its
HandoverForecast message. If the MN does not receive a
HandoverForecastResponse message even after HF_RETRIES, it MUST
assume that PAR (NAR) does not support the extensions proposed in
this document if MN is the receiver (sender) of the session. Then MN
MUST stop re-sending the HandoverForecast message.
Even if the access router to which MN sends the HandoverForecast
message is capable of the extensions, the other routers on the
neighbor tunnel may still be incapable of the extensions proposed in
this document. This is indicated to MN through the
HandoverForecastResponse message with a Code value of 1.
5.2. Distinguishing Handover Sessions and New Sessions
Experience shows that users are more sensitive to terminating an
ongoing session compared with blocking a new session. So the
extensions proposed in this document introduce a new mechanism to
distinguish resource reservation requests from different kinds of
sessions, giving handover sessions a higher priority, therefore
reducing the forced termination rate of sessions due to handover.
When the router receives a reservation request, it SHALL first check
whether the request is included in a Resv message or a TunnelResv
message, so as to distinguish whether the request is from a new
session or a handover session. Then the router SHALL use certain
algorithms (eg. Guard Channel) to allocate resources to handover
sessions with a higher priority. The allocation algorithm itself is
out of the scope of this document. Distinguishing handover sessions
and new sessions is a fundamental part of the extensions proposed in
this document and MUST be implemented in every access router that
supports the extensions.
5.3. Bidirectional Reservation
In some types of service (e.g. Voice over IP), bidirectional
communication is carried out and therefore, bidirectional reservation
is required. However, in traditional RSVP, two distinct sets of
message exchanges must be implemented to establish the bidirectional
reservation. This is troublesome, and may cause considerable delay
in setting up the resource reservation path. The extensions proposed
in this document solve this problem by adding a 'B' Flag in the
Common Header of the RSVP messages (see section 6.1.). When this bit
is set to 1, it indicates that it is a bidirectional reservation;
otherwise, it is a unidirectional reservation. When receiving a Path
Yi, et al. Expires August 12, 2007 [Page 42]
Internet-Draft Fast RSVP February 2007
(or TunnelPath) message, the session endpoint SHOULD check whether
the 'B' flag is set. If it is set, in addition to sending a Resv (or
TunnelResv) message, the node SHOULD also send a Path (or TunnelPath)
message with the same SENDER_TSPEC object and without the 'B' flag
set on the reverse direction. The 'B' flag in the Common Header can
also be meaningful in the messages such as TunnelPathTear and
TunnelStateChange. Similarly, when receiving these messages with the
'B' flag set, the receiver SHOULD consider that the reservation is
bidirectional and tear down or change the reservation type on the
reverse direction. Bidirectional Reservation is an optional
complement of the extensions proposed in this document and the 'B'
flag MUST be silently ignored if the node does not recognize it.
5.4. Utilization of Advanced Reservation before Handover
The resources reserved in advanced on the tunnel are wasted until the
handover occurs. To avoid this problem, the extensions proposed in
this document add an 'A' flag in the Common Header of the RSVP
messages (see section 6.1.). When receiving a TunnelPath (or
TunnelResv) message with the 'A' flag set, the intermediate routers
SHOULD create the corresponding Path State (or Resv State) and mark
the state as "advanced reservation" indicating that the resources are
reserved in advance and can be used temporarily by other applications
until the session which makes the reservation indeed hands over to
the target subnet. The routers can allocate the advanced reservation
to some applications with lower priorities (e.g. the Best Effort
application) or some short time packet bursts. How to allocate the
advanced reserved resources is out of the scope of this document.
When MN moves to the new subnet, it SHALL send a
HandoverForecastConfirm message to PAR or NAR, depending on whether
MN is the session receiver or the session sender. When receiving the
HandoverForecastConfirm message, PAR (NAR) SHOULD check whether the
reservation type corresponding to this session is "advanced
reservation". If it is, PAR (NAR) MUST send a TunnelStateChange
message to NAR (PAR). When intermediate routers receive the
TunnelStateChange message, they SHALL change the Path State and Resv
State from the "advanced reservation" to "normal reservation", so
that the resources SHALL be exclusively used by the handover session
of MN from then on. Utilization of Advanced Reservation is an
optional complement of the extensions proposed in this document and
the 'A' flag MUST be silently ignored if the intermediate routers do
not recognize it.
Yi, et al. Expires August 12, 2007 [Page 43]
Internet-Draft Fast RSVP February 2007
6. New Messages and Objects
6.1. Modified Common Header
The extensions proposed in this document introduce two flags in the
Common Header of the RSVP message to support bidirectional
reservation and the utilization of advanced reservation before the
handover.
If the session endpoint wants to establish bidirectional reservation,
it can set the 'B' flag in the Common Header of the Path (TunnelPath)
message. When receiving a Path (TunnelPath) message with the B flag
set, in addition to replying with the (TunnelResv) message, the
session endpoint SHALL send a Path (TunnelPath) message in the
reverse direction. The 'B' flag MAY also be set in the Common Header
of HandoverForecast, HandoverForecastConfirm, HandoverForecastError,
HandoverForecastTear, TunnelStateChange and TunnelPathTear messages
to indicate the bidirectional reservation.
If the access router decides that the advanced resource reservation
on the tunnel can be temporarily utilized by other sessions before
MN's handover event, it can set the A flag in the Common Header of
the TunnelPath message and then the intermediate routers SHOULD mark
the reservation state as "advanced reservation".
Yi, et al. Expires August 12, 2007 [Page 44]
Internet-Draft Fast RSVP February 2007
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL |B|A|Reserved | RSVP Length |
+-------------+-------------+-------------+-------------+
Vers See RFC 2205 [1].
Flags See RFC 2205 [1].
Msg Type See RFC 2205 [1].
RSVP Checksum See RFC 2205 [1].
Send_TTL See RFC 2205 [1].
B flag The B flag is set if the reservation is
a bidirectional reservation.
A flag The A flag is set if the reservation is
an advanced reservation.
RSVP Length See RFC 2205 [1].
Figure 12: Format of Common Header
6.2. New Objects
6.2.1. New MSESSION Object
The extensions proposed in this document define a new MSESSION object
to replace the SESSION object. Compared with the SESSION object,
MSESSION adds "IPv6 HomeAddress" field in the object. The "IPv6
HomeAddress" field is filled with the MN's home address and its value
is constant during handover, so we can utilize it to label the
session. In the mobile environment, the RSVP router MUST label a
session based on the content of the MSESSION and set up the
corresponding Path State and Resv State accordingly.
Yi, et al. Expires August 12, 2007 [Page 45]
Internet-Draft Fast RSVP February 2007
Class = To be allocated by IANA
C-Type = To be allocated by IANA
0 1 2 3
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol ID | Flags | DstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 HomeAddress (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 DestAddress
The IP unicast or multicast care of address of the
session. This field must be non-zero and may change
during the life time of the session.
Protocol ID See RFC 2205 [1].
Flags See RFC 2205 [1].
DstPort See RFC 2205 [1].
IPv6 HomeAddress
The IP unicast or multicast home address of the session.
This field must be non-zero and remain constant during
the life time of the session.
Figure 13: Format of MSESSION object
6.2.2. New Router_Notify Object
The extensions proposed in this document define a new Router_Notify
object. This object is included in the HandoverForecast message,
HandoverForecastError message and HandoverForecastTear message. The
Yi, et al. Expires August 12, 2007 [Page 46]
Internet-Draft Fast RSVP February 2007
Code in this object is to notify the access router whether it should
act as PAR or NAR. If MN is the session receiver, the tunnel
endpoint's IP address is MN's NCoA and if MN is the session sender,
the tunnel endpoint's IP address is PAR's IP address.
Class = To be allocated by IANA
C-Type = To be allocated by IANA
0 1 2 3
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ TunnelEndPointAddr (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Code | Reserved |
+-------------+-------------+-------------+-------------+
TunnelEndPointAddr
The IP address of the tunnel endpoint.
Code 0 The access router should act as PAR.
1 The access router should act as NAR.
Reserved See RFC 2205 [1].
Figure 14: Format of Router_Notify object
6.2.3. New Tunnel_Info Object
The extensions proposed in this document define a new Tunnel_Info
object. This object is included in the HandoverForecastResponse
message to indicate whether the resource reservation tunnel is
established successfully.
Yi, et al. Expires August 12, 2007 [Page 47]
Internet-Draft Fast RSVP February 2007
Class = To be allocated by IANA
C-Type = To be allocated by IANA
0 1 2 3
+-------------+-------------+-------------+-------------+
| Tunnel Code | Reserved |
+-------------+-------------+-------------+-------------+
Tunnel Code 0 Establishment of the RSVP tunnel is
successful.
1 Establishment of the RSVP tunnel fails.
Reserved See RFC 2205 [1].
Figure 15: Format of Tunnel_Info object
6.3. New Messages
6.3.1. HandoverForecast Message
When receiving the HandoverForecast.ind from the mobile IP module,
the RSVP module of MN would send a HandoverForecast message to PAR
(NAR) to indicate a handover event. If MN is the session receiver,
the Router_Notify object in the HandoverForecast message MUST contain
the care-of address that will be used in the predicted handover
target (NCoA) as well as Code 0. If MN is the session sender, the
Router_Notify object in the HandoverForecast message MUST contain the
PAR's IP address as well as Code 1. The information contained in
HandoverForecast message will be used by PAR (NAR) to establish the
resource reservation tunnel. If MN is the sender of the session, the
sender descriptor object MUST also be contained into this message.
If MN is the receiver of the session or MN is both the sender and
receiver of the session, the sender descriptor object need not be
included. The Msg Type of the HandoverForecast message needs to be
allocated by IANA.
Msg Type = To be allocated by IANA
<HandoverForecast> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <Router_Notify>
[<sender descriptor>]
<Router_Notify> ::= <TunnelEndPointAddr> <Code>
Yi, et al. Expires August 12, 2007 [Page 48]
Internet-Draft Fast RSVP February 2007
6.3.2. HandoverForecastResponse Message
No matter weather the establishment of the resource reservation
tunnel is successful or not, PAR or NAR MUST send a
HandoverForecastResponse message to MN. The new Tunnel_Info object
in the HandoverForecastResponse message contains a Tunnel Code to
specify the result of the resource reservation tunnel establishment
(we only define Code 0 and 1 right now). The Msg Type of the
HandoverForecastResponse message needs to be allocated by IANA.
Msg Type = To be allocated by IANA
<HandoverForecastResponse> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <Tunnel_Info>
<Tunnel_Info> ::= <Tunnel Code>
6.3.3. HandoverForecastConfirm Message
When receiving the HandoverForecastConfirm.ind from the mobile IP
module, the RSVP module of MN MUST send a HandoverForecastConfirm
message to PAR or NAR, depending on whether MN is the session
receiver or session sender. The Msg Type of the
HandoverForecastComfirm message needs to be allocated by IANA.
Msg Type = To be allocated by IANA
<HandoverForecastConfirm> ::= <Common Header> [<INTEGRITY>]
<MSESSION>
6.3.4. TunnelStateChange Message
When receiving the HandoverForecastConfirm message, PAR (NAR) MUST
send a TunnelStateChange message to NAR (PAR) so that the
intermediate routers can change the reservation type form "advanced
reservation" to "normal reservation".
Msg Type = To be allocated by IANA
<TunnelStateChange> ::= <Common Header> [<INTEGRITY>]
<MSESSION>
Yi, et al. Expires August 12, 2007 [Page 49]
Internet-Draft Fast RSVP February 2007
6.3.5. HandoverForecastError Message
When receiving the HandoverForecastError.ind from the mobile IP
module, the RSVP module of MN MUST send a HandoverForecastError
message to PAR or NAR, depending on whether MN is the session
receiver or session sender. If MN is the session receiver, the
Router_Notify object in the HandoverForecast message MUST contain the
current in use care-of address of MN as well as Code 0. If MN is the
session sender, the Router_Notify object in the HandoverForecast
message MUST contain the PAR's IP address as well as Code 1. The
information contained in HandoverForecastError messge will be used by
PAR (NAR) to re-establish the resource reservation tunnel. If MN is
the sender of the session, the sender descriptor object MUST also be
contained in this message. If MN is the receiver of the session or
MN is both the sender and receiver of the session, the sender
descriptor object need not be included. The Msg Type of the
HandoverForecastError message needs to be allocated by IANA.
Msg Type = To be allocated by IANA
<HandoverForecastError> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <Router_Notify>
[<sender descriptor>]
<Router_Notify> ::= <TunnelEndPointAddr> <Code>
6.3.6. HandoverForecastTear
When receiving the HandoverForecastError.ind from the mobile IP
module, the RSVP module of MN MUST send a HandoverForecastTear
message to PAR, and then PAR can release the resources reserved in
advance on the falsely built tunnel. The TunnelEndPointAddr field in
the Router_Notify object MUST contain MN's formerly falsely predicted
CoA and the Code field MUST be ignored. The Msg Type of the
HandoverForecastTear message needs to be allocated by IANA.
Msg Type = To be allocated by IANA
<HandoverForecastTear> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <Router_Notify>
[<sender descriptor>]
<Router_Notify> ::= <TunnelEndPointAddr> <Code>
Yi, et al. Expires August 12, 2007 [Page 50]
Internet-Draft Fast RSVP February 2007
6.3.7. TunnelPath Message
TunnelPath message is sent for each session on MN that requests the
establishment of a resource reservation tunnel. The MSESSION object
includes MN's home address, this address together with the "DstPort"
and "Protocol Id" can be used to uniquely label a session in the
mobile environment. If the bidirectional reservation is required,
the 'B' flag in the Common Header MUST be set and if the "advanced
reservation" type is supported, the 'A' flag in the Common Header
SHOULD be set. The Msg Type of the TunnelPath message needs to be
allocated by IANA.
Msg Type = To be allocated by IANA
<TunnelPath> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <RSVP_HOP>
<TIME_VALUES>
[<POLICY_DATA>...]
[<sender descriptor>]
6.3.8. TunnelResv Message
TunnelResv message is sent for each session on MN that requests the
establishment of a resource reservation tunnel. If the "advanced
reservation" type is supported, the 'A' flag in the Common Header
SHOULD be set. The Msg Type of the TunnelResv message needs to be
allocated by IANA.
Msg Type = To be allocated by IANA
<TunneResv> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <RSVP_HOP>
<TIME_VALUES>
[<RESV_CONFIRM>] [<SCOPE>]
[<POLICY_DATA>...]
<STYLE> <flow descriptor list>
6.3.9. TunnelPathTear Message
On receiving the TunnelPathTear message, the intermediate routers
MUST delete the corresponding Path State and Resv State that match
the MSESSION object. If the bidirectional reservation needs to be
removed, the 'B' flag in the Common Header of the TunnelPathTear
message SHALL be set. The Msg Type of the TunnelPathTear message
Yi, et al. Expires August 12, 2007 [Page 51]
Internet-Draft Fast RSVP February 2007
needs to be allocated by IANA.
Msg Type = To be allocated by IANA
<TunnelPathTear> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <RSVP_HOP>
[<sender descriptor>]
6.3.10. TunnelResvTear Message
On receiving the TunnelResvTear message, the intermediate routers
MUST delete the corresponding Resv State that matches the MSESSION
object. If the bidirectional reservation needs to be removed, the
'B' flag in the Common Header of the TunnelResvTear message SHALL be
set. The Msg Type of the TunnelPathTear message needs to be
allocated by IANA.
Msg Type = To be allocated by IANA
<TunnelResvTear> ::= <Common Header> [<INTEGRITY>]
<MSESSION> <RSVP_HOP>
[<SCOPE>]<STYLE>
<flow descriptor list>
Yi, et al. Expires August 12, 2007 [Page 52]
Internet-Draft Fast RSVP February 2007
7. Security Considerations
This document introduces a procedure and two related new RSVP
messages (HandoverForecast, HandoverForecastResponse) for MN to
inform PAR (or NAR) to establish the resource reservation tunnel. If
the HandoverForcast message is insecure, the resource may be stolen
because the resource reservation tunnel may be established for the
malicious node. Hence, the PAR MUST ensure that MN that sends the
HandoverForcast message is a legal node. Therefore, a Security
Association (SA) between MN and PAR (or NAR) must be established. A
lot of research work has already been done on the establishment of SA
in the mobile environment. Then IPsec could be utilized to ensure
the secure transmission of the messages.
This document introduces a procedure and four related messages
(TunnelPath, TunnelResv, TunnelPathTear, TunnelResvTear) for PAR (or
NAR) to establish and release the resource reservation tunnel. There
are no new security considerations beyond those already addressed in
the existing RSVP reservation establishment and release of RFC2205.
This document introduces a procedure and three related new RSVP
messages (HandoverForecastConfirm, HandoverForecastError,
HandoverForecastTear) for MN to inform PAR whether the handover
prediction is successful or fails. The security considerations are
similar to those in the establishment of the resource reservation
tunnel discussed above.
This document introduces a procedure for CN to establish the
reservation on the optimized route and there is no new security
considerations beyond those already addressed in the existing RSVP
reservation establishment of RFC2205.
Yi, et al. Expires August 12, 2007 [Page 53]
Internet-Draft Fast RSVP February 2007
8. IANA Considerations
8.1. RSVP Common Header Flags
This document requests that IANA manages the flags in the Common
Header of the RSVP message. Two new flags, the 'B' flag and the 'A'
flag are defined in section 6.1.
8.2. RSVP Objects
This document requests that IANA allocates three new Class-Num and
three new C-Types for the MESSION object, Router_Notify object and
Tunnel_Info object defined in section 6.2. Note that the MESSION
object only supports the IPv6 addressing now.
8.3. RSVP Messages
This document requests that IANA allocates ten new Msg Type for the
ten new RSVP messages defined in section 6.3.
Yi, et al. Expires August 12, 2007 [Page 54]
Internet-Draft Fast RSVP February 2007
9. Acknowledgements
Yi, et al. Expires August 12, 2007 [Page 55]
Internet-Draft Fast RSVP February 2007
10. References
10.1. Normative References
[1] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[2] Johnson, David B., Perkins, E., and BJari. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[3] Z. Kan, D Zhang, R. Zhang and J. Ma. QoS in Mobile IPv6. In
Proc. of International Conferences on Info-tech and Info-
net 2001, Vol. 2, pp 492-497.
[4] R. Koodli, Ed., Karim El Malki, Mohamed Khalil, Charles E.
Perkins, "Fast Handovers for Mobile IPv6", RFC 4068, July
2005.
[5] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP
Operation over IP Tunnels", RFC 2746, Janauary 2000.
10.2. Informative References
Yi, et al. Expires August 12, 2007 [Page 56]
Internet-Draft Fast RSVP February 2007
Authors' Addresses
Yi Sun
Institute of Computing Technology, Chinese Academy of Sciences
Mailbox 2704
Beijing, 100080
P.R. China
Phone: +86-10-62600711
Fax: +86-10-62533449
Email: sunyi@ict.ac.cn
Bin Feng
Beijing University of Posts and Telecommunications
Beijing
P.R. China
Phone: +86-13810106501
Email: fengbin8210@126.com
Yucheng Zhang
University of Electronic Science and Technology of China
Beijing
P.R. China
Phone: +86-13426339145
Email: zyc552@sohu.com
Rusong Zheng
Institute of Computing Technology, Chinese Academy of Sciences
Mailbox 2704
Beijing, 100080
P.R. China
Phone: +86-10-62600712
Fax: +86-10-62533449
Email: zhengrusong@ict.ac.cn
Yi, et al. Expires August 12, 2007 [Page 57]
Internet-Draft Fast RSVP February 2007
Wenxia Dong
SouthWest JiaoTong University of China
Beijing
P.R. China
Phone: +86-10-62600712
Fax: +86-10-62533449
Email: dongwenxia@ict.ac.cn
Jinglin Shi
Institute of Computing Technology, Chinese Academy of Sciences
Mailbox 2704
Beijing, 100080
P.R. China
Phone: +86-10-62600734
Fax: +86-10-62533449
Email: zsjl@ict.ac.cn
Eryk Dutkiewicz
University of Wollongong
Wollongong NSW 2522
Australia
Phone: +61-2-42214650
Fax: +61-2-42214464
Email: eryk@uow.edu.au
Yi, et al. Expires August 12, 2007 [Page 58]
Internet-Draft Fast RSVP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Yi, et al. Expires August 12, 2007 [Page 59]