NSIS Working Group Xiaoming Fu
Internet-Draft Holger Karl
Expires: July 16, 2002 Andreas Festag
Guenter Schaefer
Technical University Berlin
Changpeng Fan
Cornelia Kappler
Mirko Schramm
Siemens AG
January 15, 2002
QoS-Conditionalized Binding Update in Mobile IPv6
draft-tkn-nsis-qosbinding-mipv6-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 16, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This draft presents a scheme for QoS support in Mobile IPv6. A QoS
hop-by-hop option piggybacked in the binding messages is used for QoS
signaling. A handoff takes place only upon the availability of
sufficient resources along the new transmission path. This QoS-
conditionalized scheme builds upon the hierarchical modbile IPv6
Fu, et al. Expires July 16, 2002 [Page 1]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
protocol and is especially fit for local mobility, where the
signaling overhead is reduced. It also enables the mobile node to
flexibly choose among a set of available access points so that the
mobile node can transmit packets through a route which offers
satisfying QoS.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Format of QoS option . . . . . . . . . . . . . . . . . . . . 11
5. Detailed description of QoS-conditionalized binding
update procedure . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Mobile node . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Comparison of our scheme with the requirements draft . . . . 15
6.1 Performance requirements . . . . . . . . . . . . . . . . . . 15
6.2 Interoperability requirements . . . . . . . . . . . . . . . 15
6.3 Exception condition requirements . . . . . . . . . . . . . . 15
6.4 Miscellaneous requirements . . . . . . . . . . . . . . . . . 16
6.5 Obvious requirements . . . . . . . . . . . . . . . . . . . . 16
7. Further discussion . . . . . . . . . . . . . . . . . . . . . 18
7.1 QoS control in entities unaware of the BU/BA options . . . . 18
7.2 Sending QoS-conditionalized binding messages via a
non-default route . . . . . . . . . . . . . . . . . . . . . 18
7.3 Signaling downstream QoS requirements . . . . . . . . . . . 18
7.4 Upgrading the level of QoS . . . . . . . . . . . . . . . . . 19
7.5 Possibility of changing from a hop-by-hop option to
destination option . . . . . . . . . . . . . . . . . . . . . 20
7.6 Handling intermediate reservations . . . . . . . . . . . . . 20
7.6.1 Optimistic reservation . . . . . . . . . . . . . . . . . . . 21
7.6.2 Postponed reservation . . . . . . . . . . . . . . . . . . . 21
7.7 Handling large signaling packets over the wireless link . . 21
8. Security considerations . . . . . . . . . . . . . . . . . . 23
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
Fu, et al. Expires July 16, 2002 [Page 2]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
1. Introduction
With the advent of various radio access technologies and increasing
deployment of sophisticated applications in mobile end systems, IPv6-
based networks will increasingly have to support Quality of Service
(QoS) in mobile environments. Mobile IPv6 ensures correct routing of
packets to a mobile node when the mobile node changes its point of
attachment with the IPv6 network. However, it is also required to
provide proper QoS forwarding treatment to the mobile node's packet
streams at the changed route in the network due to node mobility in a
fast, flexible, and scalable way, so that QoS-sensitive IP services
can be supported over Mobile IPv6 [2]. A QoS scheme for Mobile IPv6
should (i) be able to localize the QoS (re-) establishment to the
affected parts of the packet path in the network, and (ii) in cases
where more than one access technology or access router (AR) is
available, it may be desirable for the MN to choose an appropriate AR
that can satisfy its QoS requirements among several potential new ARs
when the MN moves into such a region (especially since in vertical
handoff scenarios, choosing a "good" access router might be more
important than the mere speed of reestablishing a QoS path). In
these cases, a handoff should not be performed if the MN's QoS
requirement is not met; yet if the QoS can be met, handoff should be
performed as quickly as possible.
In reference [7] a new IPv6 option called "QoS option" is introduced.
One or more QoS objects are included as a hop-by-hop option in IPv6
packets carrying Binding Update (BU) and Binding Acknowledgement (BA)
messages. When one packet for this purpose traverses different
network domains in the end-to-end path, the QoS option is examined at
these intermediate network domains to trigger QoS support for the
MN's data packets.
The mechanism described in reference [7] outperforms RSVP [8][12] in
that its signaling overhead is decreased. However, it does not allow
to check whether the QoS requirements are satisfied along the new
route before performing the handoff. We therefore introduce a QoS-
conditionalized binding update. The node at which old and new paths
diverge ("switching router") makes the final decision whether or not
to update the binding, depending on the result of QoS checks. A
binding update will only take place (in the sense of modifying the
route) if all nodes along the route between the AR and the switching
router are capable of complying with the QoS request, otherwise, the
old route will still be used and a negative acknowledgement will be
returned to the MN.
Our scheme is based on the architecture of Hierarchical Mobile IPv6
(HMIPv6) [6] to localize the QoS-conditionalized bindings. In
HMIPv6, a new entity, the Mobility Anchor Point (MAP), is introduced
Fu, et al. Expires July 16, 2002 [Page 3]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
and a MN only needs to perform one Local BU through MAP when changing
its layer 3 access point within the MAP domain. Hence the MAP is a
reasonable place for the switching router. However HMIPv6 is not
able to express QoS requirements, let alone to provide feedback
regarding the success of such request. We built on the work
described in reference [7] to overcome these limitations.
In this scheme, a QoS hop-by-hop option is carried in the message
containing the BU option to the MAP - this message is called BU+QoS
message. Each node concerned with QoS management between the MN and
the MAP (including the MAP) will pass the QoS requirement represented
by the QoS option to internal QoS mechanisms and check its resource
availability. If resources are available locally, they are reserved
and the message will be forwarded along its route. If specified in
the BU+QoS message, reservations covering less than the desired
amount of resources are also be possible; the request in the BU+QoS
message is then updated accordingly. If resources are not
available, negative feedback will be provided to the MN. Upon
receiving the BU+QoS message, the MAP also checks resource
availability and, if successful, will update the binding status and
respond with a positive BA+QoS message, including the actual amount
of reserved resources, if different from the requested amount.
Otherwise, no binding update is performed and a negative BA+QoS
message is returned to the MN.
By way of this scheme, QoS (re-)establishment due to local handoffs
is managed locally and transparently to the CNs, while in the worst
case (global mobility) it is managed with Mobile IPv6 and [7]. Only
if all routers along the new path find that sufficient resources are
available will a handoff (switching from old to new path) take place.
In this sense, the handoff process is conditional on the availability
of QoS resources and our scheme can take advantage of HMIPv6. The
additional advantage, however, is that mobile nodes will only perform
a handoff to an AR that can fulfill the QoS requirement (if there are
multiple ARs to choose from; in case there is only a single AR able
to serve the mobile node, even best-effort service would likely be
acceptable, however, this is an application-level concern).
The rest of this document provides a detailed description of the QoS-
conditionalized binding update procedure(s) for Mobile IPv6. The
document is organized as follows:
o Section 2 gives the terminology used in the document.
o Section 3 gives an overview of the scheme.
o Section 4 gives the message format used for the scheme.
Fu, et al. Expires July 16, 2002 [Page 4]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
o Section 5 describes the scheme in more detail.
o Section 6 compares our scheme with the requirements for a QoS
solution for Mobile IP as described in [2].
o Section 7 presents a few important issues brought up by our
scheme and gives the reasons for choosing a particular
solution among different possibilities within our scheme.
o Section 8 addresses the security considerations.
Fu, et al. Expires July 16, 2002 [Page 5]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
2. Terminology
This document uses the following terms in addition to those defined
in the Mobile IPv6 protocol [4] and Hierarchical Mobile IPv6
protocol [6]:
QoS option: A Hop-by-Hop option introduced in reference [7]. A
QoS option contains zero or more QoS objects in Type/Length/
Value (TLV) format.
QoS object: An object introduced in reference [7].
Essentially, QoS OBJECT is an extension of RSVP QoS and
FILTER_SPEC objects, and contains certain parameters
representing QoS requirements and traffic characteristics for
a QoS flow.
QoS entity: An entity responsible for QoS negotiation and
establishment. Examples are RSVP daemons in RSVP/IntServ, a
Bandwidth Broker in a DiffServ domain, or a Label Edge Router
in an MPLS domain. From the perspective of MIPv6, QoS
(re)establishment is treated transparently in QoS-capable
routers or hosts; the IPv6 nodes MAY ask QoS entities to check
the QoS requirements included in the QoS option, and afterwards
the latter SHOULD perform such a reservation and respond with
an acknowledgement possibly along with (possibly modified) QoS
parameters.
Switching router/MAP: The node at which old and new paths diverge
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 [1].
Besides, the following acronyms and abbreviations are used in this
document:
MIP/MIPv6/HMIPv6: Mobile IP/Mobile IPv6/Hierarchical Mobile
IPv6
MAP: Mobility Anchor Point
MN: Mobile Node
CN: Correspondent Node
QoS: Quality-of-Service
CoA: Care-of-Address
Fu, et al. Expires July 16, 2002 [Page 6]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
RCoA/LCoA: Regional/On-Link CoA
HoA: Home Address
AR: Access Router
BU/BA: Binding Update/Binding Acknowledgement
ER: Edge Router of network domain
IR: Interior Router of network domain
MPLS: Multi-Protocol Label Switching
LSP: Label Switched Path
DiffServ: Differentiated Services
IntServ: Integrated Services
RSVP: Resource ReSerVation Protocol
Upstream(UP)/Downstream(DW) direction: From MN/Towards MN
Fu, et al. Expires July 16, 2002 [Page 7]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
3. Overview
The all-IP network is assumed to consist of routers which may also be
responsible for the management of QoS resources, in which case we
call them QoS entities. For the purpose of this paper, such a QoS
entity acts as a black box to which QoS requests for a certain path
can be sent, which checks resource availability (resources would
typically include link bandwidth, buffer space in the router, CPU
resources, etc.) along the particular part of the path it is
responsible for, and either grants the request (and reserves the
resources), denies it, or, optionally, grants a reduced version of
the request. Typically, such QoS entities may be located at least in
the access routers and the agents which perform binding updates,
additional entities are of course possible. How to implement such
QoS entities and how to enforce such reservations is beyond the scope
of this paper; here, the mechanisms of conditionalizing the binding
update is discussed.
Since most handoffs are assumed to be local, a QoS solution
minimizing the time for QoS (re)establishment may take the advantage
of the regional mobility solutions. Furthermore, Hierarchical Mobile
IPv6 (HMIPv6) protocol is assumed to be the regional mobility
solution within our work.
The operation of QoS-conditionalized binding update is as follows. A
QoS hop-by-hop option is carried in the message containing the BU
option to the MAP -- this message is called BU+QoS message. Each QoS
entity between the MN and the MAP (including the MAP) will pass the
QoS requirement represented by the QoS option to internal QoS
mechanisms and check its resource availability. If resources are
available locally, they are reserved and the message will be
forwarded along its route. If resources are not available, negative
feedback will be provided to the MN by means of an extended Binding
Acknowledgement (BA+QoS) message. If a BU+QoS message has reached
the switching MAP and passed the local QoS test as well, the binding
update will take place (the binding cache in the MAP is updated to
reflect the new LCoA) and a positive BA+QoS message is returned to
the MN. Otherwise, no handoff is performed and a negative BA+QoS
message is returned to the MN. When observing a negative BA+QoS
message, intermediate QoS entities can release reservations that
could not be granted further upstream.
Fu, et al. Expires July 16, 2002 [Page 8]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
____________
| |
| CN |
|____________|
/\ /\ /\
/ | \
/ _____\/_____ \
/ | | \
/ | MAP | \
/ |____________| \
/ /\ /\ \ \
/ / (2)\ \(3) \
data / / BU+QoS\ \BA+QoS \ data
path1/ _______\/__ ___\_\/____ \path2
| | | | | |
| | AR1 | | AR2 | |
| |___________| |___________| |
| /\ /\ / |
\ \ (1)/ /(4) /
\ \ BU+QoS/ /BA+QoS /
\ \/_______/__\/ /
\ | | /
--> | MN | <--
|____________|
<--------------->
Node Mobility
Figure 1 - An Example of a QoS-Conditionalized Binding Procedure
Figure 1 shows an example of a QoS-conditionalized binding update in
a MAP domain. In this figure, the MAP is the switching router, the
ARs and the MAP are the only nodes concerned with QoS control.
Suppose the data packets between the MN and the CN is sent through
AR1 and QoS-guarranteed. Now due to node mobility, a second AR, AR2,
is reacheable while AR1 is still available. The MN can then send a
so-called QoS-conditionalized Binding Update message (BU+QoS) toward
the MAP through AR2, and the MAP will reply with acknowledgement
message (BA+QoS). If both AR2 and the MAP are able to fulfil the QoS
requirements embedded in the BU+QoS message, the BA+QoS message will
be positive and the resources will be reserved in its transmission
path. Otherwise it will be negative and the resources will be
released. In general, the path between the switching router and the
AR may contain several MAPs, as well as DiffServ/MPLS domains and/or
IntServ nodes, or combinations of both. QoS entities in such nodes or
domains should make admission control decisions based on the QoS
option. The QoS Option is a hop-by-hop header extension option and
treated as described below. (As an optimization, the new AR could
Fu, et al. Expires July 16, 2002 [Page 9]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
obtain QoS information from the old AR via context transfer
protocols in order to save wireless bandwidth - see discussion in
Section 7.7.)
In HMIPv6, outside the MAP domain, destination address or source
address of any packet to and from MN is marked as the MAP's IP
address or MN's RCoA in the MAP domain, not the HoA or LCoA of the
MN. Hence, the CN is oblivious of the BA, and a QoS (re-)
establishment procedure due to handoff only happens inside the MAP
domain. here we only discuss the case of the basic mode of HMIPv6
and the treatment in the extended mode of HMIPv6 needs more
investigation.
Fu, et al. Expires July 16, 2002 [Page 10]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
4. Format of QoS option
1. The format of the QoS object (see Figure 2) follows [7].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Reserved | Object Length |QoS Requirement|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Max Delay (16-bit integer) ms |Delay Jitter (16-bit integer)ms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Average Data Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Peak Data Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Minimum Policed Unit (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Maximum Packet Size (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | |
~ Values of Packet Classification Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Composition of a QoS OBJECT
2. Format of QoS Option - follows [7], except that 3 bits of
"Reserved" bits are used to specify whether QoS requirement
indicated by this option can be met, how to include desired
and/or accepted QoS and up- and/or downstream QoS. (see
Figure 3):
1. If the "F" bit is set, this means "QoS can not be met",
otherwise "(up to current node) QoS can be met".
2. If the "D" bit is set, this means "only downstream QoS
are specified", otherwise "both upstream and downstream
QoS are specified.
3. If the "A" bit is set, this means "both acceptable QoS
and desired QoS are specified", otherwise "only
desired QoS is specified".
Fu, et al. Expires July 16, 2002 [Page 11]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |0|0|1| Opt Type| Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 |F|D|A| Reserved| DW- Desired QoSObj {, UP- Desired QoSObj} ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | |
~ {, DW- Accepted QoSObj}{, UP- Accepted QoSObj} in TLV format ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Composition of QoS OPTION
Fu, et al. Expires July 16, 2002 [Page 12]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
5. Detailed description of QoS-conditionalized binding update procedure
5.1 Mobile node
The MN in our scheme behaves different to the one in the HMIPv6 basic
mode when responding to a few events: detecting connectivity to a new
AR, loosing connectivity to an existing router, and the arrival of
BA+QoS. As a simplification, the processing here assumes that
whenever a new AR becomes available, a binding update to this AR
should be attempted. In reality, more sophisticated schemes may be
implemented (e.g., only sending BU+QoS messages when the link quality
to the old AR is deteriorating, keeping track of a list of
prospective ARs, etc.); also, immediately obtaining an IP address
from any new AR might not be cost-efficient, these are out of the
scope of this draft. Note that the treatment of acceptable/desirable
QoS is also not discussed here; the necessary modifications are
reasonably straightforward.
The MN detects the connectivity to a new AR either by listening to
Router Advertisements or performing Router Solicitation as specified
in [4]. After MN acquires new local IP address (LCoA), it should
compose a BU+QoS message and send it towards MAP (via new AR).
If the MN receives a BA+QoS message, it should check whether the "F"
bit is set in the QoS Option. If not set, the AR which this BA+QoS
message passing through should be set as the default route for future
data transmission. Otherwise no action is required: either still use
old AR, or go with no QoS guarantees.
To optimize the QoS-conditionalized binding update procedure, the MN
may maintain at least two lists of LCoA-AR-QoS pairs for which are
available in connectivity and for which the MN has received positive
BA+QoS messages. Once a BU+QoS message is responded with a negative
BA+QoS, the QoS requirements embedded in the next BU+QoS message may
differ from the previous one, e.g., the desired level of QoS could be
reduced. There are several possibilities of how the number of
available access routers could influence the setting of lowest
acceptable QoS. E.g., acceptable QoS could be a function of the
number of available ARs and/or the MN's speed.
5.2 Router
Upon receiving a BU+QoS message, a router should check whether the
"F" bit is set. If not set, it should ask QoS entity for resources.
If sufficient resources are not available, this router should set "F"
bit in QoS packet. If this router is the switching MAP, the MAP
should compose a BA+QoS packet from the BU+QoS packet, with "F" bit
set as in the BU+QoS packet and return the BA+QoS message to the MN.
Fu, et al. Expires July 16, 2002 [Page 13]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
If "F" bit is not set, the switching MAP should update the MN's
binding to the new LCoA. It may compose a negative BA+QoS message
and send it along the old path to release reservations. A MAP with
MAP functionalities, but is not the switching MAP, behaves like a
normal router.
Upon receiving a BA+QoS message, a router should check whether the
"F" bit is set. If set, it should ask QoS entity for releasing any
possibly reserved resources. Note that a router MUST NOT interpret
the QoS option inside a BA+QoS as request for new resources, even
when the "F" bit is not set. Rather, this QoS option is interpreted
as providing more up-to-date information about a flow for which
reservations have already been made.
Note that in order to correctly process the BA+QoS message, all
routers concerned with QoS management, such as MAPs, ARs, and
possibly DiffServ and MPLS edge routers (ER), as well as IntServ
nodes need to maintain state for each flow. However, this is not an
additional burden to these entities as they need to maintain this
same state anyway: MAPs must maintain the binding cache, and also the
AR has to keep information, including QoS information, for each MN.
ERs typically act as aggregation routers, i.e. they (as opposed to
interior routers) still know individual flows, just as IntServ nodes
do. Nevertheless, this constitutes an argument in favor of
restricting QoS control to AR and MAP.
There are two ways to release the resources that have been re-
served. One is to release them explicitly via a message carrying a
QoS option with "F" bit set. Another is to use soft-state for the
QoS reservations and to rely on time-out of the reservation along an
unused path. The timer of QoS option may differ from that for the BU
option; optimal choices for these values are unknown as of this
moment.
Fu, et al. Expires July 16, 2002 [Page 14]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
6. Comparison of our scheme with the requirements draft
In [2], a number of requirements are listed which a QoS solution for
Mobile IP has to satisfy. The following sections discuss how the
conditionalized binding update presented in this draft compares with
these requirements.
6.1 Performance requirements
A QoS solution
o MUST minimize the interruption in QoS at the time of handoff -
our scheme minimizes this interruption, because it provides the
possibility to check for and reserve resources simultaneously
with the binding update, and also allows for negotiating with
several ARs to find one that can meet the QoS required.
o MUST localize the QoS (re)programming to the affected parts of
the packet path in the network - satisfied with HMIPv6.
o MUST provide means to release any QoS state along the old path
that is not required after handoff - one possibility is to let
the MAP initiate the release request for the old path; the
other is timing-out: as BUs time out, the QoS state along the
old path will be released.
6.2 Interoperability requirements
A QoS solution
o MUST be interoperable with other mobility protocols related to
mobile IP. This is an open issue, however, the scheme as such
could be applicable to other mobility protocols as well.
o MUST be interoperable with heterogeneous QoS paradigms. As
discussed in Section 5 above, our scheme interoperates with
DiffServ, IntServ and MPLS. Since its task is just carrying
QoS information which is then used by QoS entities to do
whatever the QoS paradigm requires, it should in fact interwork
with any QoS paradigm.
6.3 Exception condition requirements
A QoS solution
o MUST provide means to handle a situation in which the old QoS
Fu, et al. Expires July 16, 2002 [Page 15]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
agreement cannot be supported after handoff - our scheme
informs the MN the old QoS requirements cannot be met via a
negative BA. The MN may initiate another BU with another AR or
the same AR with lowered QoS requirements or stay attached to
the old AR.
6.4 Miscellaneous requirements
A QoS solution
o SHOULD be able to support QoS along different potential paths,
such as route-optimized path between the MN and the CN,
triangle route via HA, temporary tunnels between old and new
access router. This is an open issue and requires additional
investigation.
o MAY provide information to link layer to support required QoS,
such as acceptable IP packet loss ratio for wireless link. Not
supported, extensions are conceivable.
6.5 Obvious requirements
A QoS solution MUST satisfy
o scalability: the major scalability concern in this scheme is
the need to maintain state in intermediate entities. However,
as most of the are MAP and hence must maintain binding update
mappings, they do keep state on a per-flow level anyway.
Hence, this scheme does not introduce any new scalability
problems.
o security - see Section 8
o conservation of wireless bandwidth - apart from obtaining a new
LCoA address from a new basestation/access router, wireless
bandwidth is used only to send BU+QoS and to receive BA+QoS.
It can, however, be decreased further by transferring context
from old AR to new AR as described in [3] and as discussed
later in Section 7.7
o low processing overhead on mobile terminals - MN need to insert
QoS object into BU and must be able to interpret negative BAs
(but compare discussion about the use of context transfer in
Section 7.7).
o hooks for authorization and accounting - needs further
Fu, et al. Expires July 16, 2002 [Page 16]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
investigation
o robustness against failure of any MIP-specific QoS component in
the network - since we use the QoS option in a context of HMIP,
if (one) MAP fails, the QoS option will be delivered further
without any treatment for QoS option (esp. if a destination
option for QoS option is used). This needs further
investigations.
Fu, et al. Expires July 16, 2002 [Page 17]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
7. Further discussion
7.1 QoS control in entities unaware of the BU/BA options
In our discussion, we distinguish two kinds of QoS-controlling
entities. Both of them are able to interpret the QoS object. While
one kind is capable of recognizing the BU/BA options in order to
decide what kind of message arrived, and are also capable of
generating (negative) BAs, the other kind of QoS-controlling entity
do not know about BUs and BAs. Such an entity bases its behavior
only on the QoS option along with the QoS objects, but cannot use the
BU/BA option to decide how to handle a message. In particular, it
must be able to distinguish a QoS option for a flow that has not yet
established any reservations at this particular entity from a flow
that already has a reservation.
As described in detail in Section 5, our mechanism works correctly
with both kinds of QoS-controlling entities.
7.2 Sending QoS-conditionalized binding messages via a non-default route
To minimize the latency of QoS re-establishment interval, the MN
should send the BU+QoS messages via the "trial" access router while
the previous access router is still used. In case a negative BA+QoS
is generated by the MAP it is also necessary to send via the non-
default route (towards the MN via the "trial" access router). IPv6
specification [5] doesn't specify this usage. To overcome this,
routing header may be used. The MN may add a routing header (the MAP
address as destination address) in its BU+QoS messages while setting
the destination address as the "trial" access router; and when
necessary, the MAP may send its negative BA+QoS messages towards the
MN.
7.3 Signaling downstream QoS requirements
One concern is how to include QoS requirement for downstream traffic
into a message carrying Binding options. In an end-to-end signaling
scenario, e.g., when using standard Mobile IP, the QoS information
for the downstream traffic can easily be provided by the CN. When
using a hierarchical architecture, however, the downstream traffic
information must still be available for the new path between the MAP
and the MN. Requesting this information from the CN would defeat the
purpose of using hierarchical mobility schemes in the first place.
On the other hand, making this information available in the router
might be feasible with some QoS paradigms that provide per-flow QoS,
yet QoS schemes that only work on aggregated traffic schemes should
not burden intermediate nodes with maintaining information about
individual traffic flows (rendering the entire idea of aggregate flow
Fu, et al. Expires July 16, 2002 [Page 18]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
treatment useless) - and this information would have to be present in
every router that would potentially be a MAP.
Hence, the downstream QoS description cannot be obtained from the CN,
neither can intermediate routers be expected to store this
information for every flow. Rather, the downstream traffic QoS
requirements should be provided along with the upstream requirements
in the BU+QoS message. The MN could know this information (e.g.,
from some application-level negotiation of QoS) but how to get it is
out of the scope of this document.
The main disadvantage of this approach is that the BU packets become
larger. While this should not pose much of a problem in the wired
backbone network, it could be considered a serious drawback when the
BU+QoS message has to be communicated over the wireless link. There
are some possible remedies to this problem which will be discussed
later.
Therefore, it is reasonable to assume that the MN also specifies the
downstream QoS requirements in the BU+QoS (the MN should be capable
of providing this information, e.g., derived from application-level
negotiation protocols). While this does increase the amount of
protocol data of the solution proposed here, the possibility to
reduce state information in the network appears to be the outweighing
concern - mechanisms like transferring context from old to new AR
(e.g., [3], see discussions later) can additionally reduce wireless
bandwidth requirements. The treatment of up- and downstream QoS
information in the routers directly follows [7].
7.4 Upgrading the level of QoS
Another concern is which level of QoS requirements is appropriate for
a MIPv6 QoS solution. When the MN requests (in preparation of a
handoff) a QoS along the new path that is larger than the one used on
the old path, the switching router alone can no longer decide whether
or not this request should be accepted (assuming that it would be
possible to provide this level of QoS on the new path). This
inability is partly caused by the need to contact the CN to check
whether it agrees as well, whether the CN's access network can
provide such an increased capacity (otherwise, upgrading the MN's
local reservation would make little sense), and it may also involve
inter-domain QoS (re-)negotiation out of the (highest) MAP domain.
Therefore, we suggest to consider during a handoff only the problem
of maintaining the currently used QoS (and possibly specifying an
acceptable lower limit) and to treat the problem of upgrading to
higher service levels separately (the main points involved here would
be authorization/charging, providing indication of the availability
of more resources to the application, and application-level QoS
Fu, et al. Expires July 16, 2002 [Page 19]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
renegotiation).
7.5 Possibility of changing from a hop-by-hop option to destination
option
The feature of hop-by-hop option for the QoS option obviously will be
a drawback for a fast handoff. Hence, a solution trying to use a
destination option may be favorable. If the AR is also a MAP, the MN
may specify a destination for the QoS option (destined to the AR) and
the AR may relay it as the destination option (destined to the next
hop MAP) again, and so forth. Then the QoS option can be carried as
a destination option in the whole QoS-conditionalized binding
procedure.
Using such a destination option is straightforward if the MAPs are
the only entities concerned with QoS control. Typically, at least
the AR would also perform QoS control without necessarily being a
MAP as well. An important case would be when the AR is the only QoS
control entity besides the MAPs. Here, the QoS option can be
transmitted from the MN to the (switching) MAP in a hop-by-hop way,
but it would be possible for the AR to change the QoS option from a
hop-by-hop option to a destination option, destined to the next
upstream MAP. Upon receiving this destination option and necessary
work regarding QoS management, a MAP between AR and the highest MAP
may encapsule the BU message again to destine it to the
hierarchically next higher MAP. When the highest MAP finally
receives the BU+QoS message, it will issue a BA+QoS message and
follow a reverse procedure (from destination option to a hop-by-hop
option).
7.6 Handling intermediate reservations
As the process of accepting a binding update is a distributed one in
which several routers can participate, it is necessary to further
specify in detail how this decision process should take place.
Specifying such distributed processing is further complicated by the
fact that multiple binding updates from different MNs could be
processed at the same routers with only small temporal offset.
The main issue is how a router handles a BU+QoS message that it could
serve, but that also has to be passed upstream onto other routes in
order to check whether they can also provide the requested QoS. In
general, this is a distributed commit problem and can be solved with
well-known techniques, requiring a number of message exchanges e.g.,
[10]. Here we are interested in faster approaches that should
ideally work using only one round trip from MN to switching router
and back; sacrificing some optimality aspects is unavoidable in such
schemes. Two main schemes are conceivable: optimistic or postponed
Fu, et al. Expires July 16, 2002 [Page 20]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
reservation.
7.6.1 Optimistic reservation
An intermediate router considers the requested QoS as actually being
reserved, optimistically assuming that all other routers along the
way can also grant the request. Reserving the capacity is the
correct decision if all upstream routers can also grant the request.
If any upstream router cannot comply with the request, a NACK is
returned and the "lower" routers have to release the spuriously made
reservation. This optimistic reservation approach can be problematic
if a lower router made a reservation that will later be denied and
has had to reject other reservation requests that could have been
granted upstream.
However, if the round-trip time for BUs is short (which is
reasonable in an access network using HMIPv6) and if there is less
traffic (relative to the available capacity) towards the core than
there is at the edges of the network, this situation should be
rather improbable and might hence be regarded as an acceptable risk
(in typical networks, the bottlenecks are likely to be closer to the
edge than towards the core).
7.6.2 Postponed reservation
In order to circumvent the problems of optimistic reservations, one
possibility would be to postpone the actual reservation: when
receiving a BU, a router only checks the instantaneous availability
of resources, without actually reserving anything when forwarding the
BU. Actual reservation only takes place when positive
acknowledgements are returned from upstream routers.
The problem with such postponed reservations is that a BA+QoS might
not be able to actually reserve capacity because of overlapping BU/
BA messages from different MNs. In such a case, the switching MAP
has incorrectly reserved capacity and, even worse, performed a
handoff to a path that is not QoS-guaranteed. This is a rather
serious drawback, and we hence propose to use an optimistic
reservation scheme.
7.7 Handling large signaling packets over the wireless link
At the beginning of an application, QoS information needs to be
transported over the wireless link in order to enable end-to-end
application-level negotiation of QoS requirements. However, as both
wireless communication capacity and processing power on mobile
terminals are precious resources, once this QoS information has been
established, it would be desirable to minimize the amount of QoS
Fu, et al. Expires July 16, 2002 [Page 21]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
information traversing the wireless link and the amount of processing
the MN has to perform. A number of different approaches exist for
this problem in general: compression schemes, moving protocol
functionality away from MNs onto proxies that reside in the wired
network; in the present context, context transfer schemes appear to
be particularly useful [3].
In particular, it should be feasible to assume that the old AR has
the QoS requirement information for each of its MNs. When an MN
wishes to associate itself with a new AR, it could simply inform the
new AR of the old AR's identity as well as of its own address
(permanent and temporary address should work). The new AR then
fetches the QoS requirement description from the old AR and initiates
the BU process on behalf of the MN; acknowledgements would still have
to be provided eventually to the MN.
Alternatively, the binding update process could also be initiated by
the old AR. Here, the MN (or even the new AR) becomes aware of a new
address it wants to use. The MN asks the old AR to initiate a
binding update procedure for this new address. The old AR contacts
the corresponding new AR, providing QoS requirements, and the new AR
constructs a BU message to be sent in the usual fashion. As soon as
the BA arrives, the new AR informs the MN that the new address is no
valid and that this new link should now be used. Negative feedback
should be provided via the old AR. This scheme is particularly
attractive if the MN is not capable of maintaining two different link
layer bindings (i.e., communicate with both old and new AR
simultaneously).
Choosing between directly transmitting BU/QoS information and
transferring context from another AR depends on a number of factors
(delay, bandwidth and cost of both the wired and the wireless link
and the respective weights assigned to them). Additionally, applying
context transfer is orthogonal to different ways of initiating the
actual handoff (controlled by the MN, the old or the new AR).
However, this question requires additional investigations.
Fu, et al. Expires July 16, 2002 [Page 22]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
8. Security considerations
The QoS scheme described in this document raises the following
threats, mainly concerning the integrity of BU/BA and QoS options:
o An attacker might possibly try to forge or replay BU messages
with specific QoS options in the name of another entity in
order to either just harm that entity or to even gain economic
benefits as QoS reservations may imply some form of billing
consequences.
o An attacker might try to delay, delete, or modify passing
BU+QoS messages (especially, the QoS options), e.g. in order
to reduce the desired QoS specification of another entity which
might possibly affect its own QoS requests or the QoS requests
of a third entity it wants to support in a positive manner.
The above threats SHOULD be averted by protecting the integrity of
BU+QoS messages with some kind of cryptographic signature, e.g. as
it is done with Mobile IP registration messages. However, this
requires the availability of appropriate key material in the signing
and the checking entities. It is out of the scope of this
specification and for further study if this can be realized with a
hop-by-hop approach, that is every intermediate node that processes
BU+QoS messages or just the QoS options checks their integrity and
signs the outgoing BU+QoS / QoS options, or an end-to-end approach
which could, for example, require the last MAP to check the integrity
of the mobile node's original BU+QoS message and its QoS option(s).
Fu, et al. Expires July 16, 2002 [Page 23]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
9. Acknowledgement
The authors are grateful to Tianwei Chen, Axel Neumann, Hemant
Chaskar and Hesham Soliman for their valuable comments to an
earlier version of this draft.
Fu, et al. Expires July 16, 2002 [Page 24]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC (Best Current Practice) 2119, March 1997.
[2] Chaskar(Ed.), H., "Requirements of a QoS Solution for Mobile
IP", Internet Draft, work in progress, draft-ietf-mobileip-qos-
requirements-01.txt, July 2001.
[3] Koodli, R. and C. Perkins, "Context Transfer Framework for
Seamless Mobility", Internet Draft, work in progress, draft-
koodli-seamoby-ctv6-00.txt, February 2001.
[4] Johnson, D. and C. Perkins, "Mobility Support in IPv6",
Internet Draft, work in progress, draft-ietf-mobileip-ipv6-
15.txt, November 2001.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Soliman, H., Castelluccia, C., El-Malki, K. and L. Bellier,
"Hierarchical MIPv6 mobility management", Internet Draft, work
in progress, draft-ietf-mobileip-hmipv6-04.txt, July 2001.
[7] Chaskar, H. and R. Koodli, "A Framework for QoS Support in
Mobile IPv6", Internet Draft, work in progress, draft-chaskar-
mobileip-qos-01.txt, March 2001.
[8] Thomas, M., "Analysis of Mobile IP and RSVP Interactions",
Internet Draft, work in progress, draft-thomas-seamoby-rsvp-
analysis-00.txt, Feburary 2001.
[9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[10] Lyon, J., Evans, K. and J. Klein, "Transaction Internet
Protocol Version 3.0", RFC 2371, July 1998.
[11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[12] Braden, B., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[13] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
Fu, et al. Expires July 16, 2002 [Page 25]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
Authors' Addresses
Xiaoming Fu (corresponding author)
Technical University Berlin
Sekr.FT 5-2, Einsteinufer 25
Berlin 10587
Germany
Phone: +49-30-314-23827
EMail: fu@ee.tu-berlin.de
Holger Karl
Technical University Berlin
Sekr.FT 5-2, Einsteinufer 25
Berlin 10587
Germany
Phone: +49-30-314-23826
EMail: karl@ee.tu-berlin.de
Andreas Festag
Technical University Berlin
Sekr.FT 5-2, Einsteinufer 25
Berlin 10587
Germany
Phone: +49-30-314-79171
EMail: festag@ee.tu-berlin.de
Guenter Schaefer
Technical University Berlin
Sekr.FT 5-2, Einsteinufer 25
Berlin 10587
Germany
Phone: +49-30-314-23836
EMail: schaefer@ee.tu-berlin.de
Fu, et al. Expires July 16, 2002 [Page 26]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
Changpeng Fan
Siemens AG
ICM N MC ST3
Berlin 13623
Germany
Phone: +49-30-386-36361
EMail: changpeng.fan@icn.siemens.de
Cornelia Kappler
Siemens AG
ICM N MC ST3
Berlin 13623
Germany
Phone: +49-30-386-32894
EMail: cornelia.kappler@icn.siemens.de
Mirko Schramm
Siemens AG
ICM N MC ST3
Berlin 13623
Germany
Phone: +49-30-386-25068
EMail: mirko.schramm@icn.siemens.de
Fu, et al. Expires July 16, 2002 [Page 27]
Internet-Draft QoS-Conditionalized Binding Update in MIPv6 January 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fu, et al. Expires July 16, 2002 [Page 28]