Seamoby Working Group Cedric Westphal
INTERNET DRAFT Rajeev Koodli
13 July 2001 Charles E. Perkins
Communication Systems Laboratory
Nokia Research Center
Context Relocation of QoS Parameters in IP Networks
draft-westphal-seamoby-qos-relocate-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 document is an individual submission for the seamoby Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the SEAMOBY@DIAMETER:ORG mailing list.
Distribution of this memo is unlimited.
Abstract
Seamless offering of Quality of Service (QoS) to a Mobile Node during
handovers is considered crucial for enabling a variety of application
services in the Mobile Internet. In this document, we define the QoS
contexts and show how they could be transferred to enable seamless QoS
operation during handovers. We introduce the notion of QoS Profile
Types and the associated QoS Profiles, which together constitute QoS
contexts, that facilitate QoS inter-operability among the pariticipating
access routers. We also illustrate how these contexts can be used with
fast handover signaling.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page i]
Internet Draft QoS Context Relocation 13 July 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. QoS Profile and QoS Profile Types 4
3.1. QoS Profile Type . . . . . . . . . . . . . . . . . . . . 5
3.2. Examples of QoS Profile Data Structures . . . . . . . . . 6
3.2.1. Best Effort QoS Profile Type . . . . . . . . . . 6
3.2.2. ``Default'' Intserv QoS Profile Type . . . . . . 6
3.2.3. DiffServ trTCM QoS Profile Type . . . . . . . . . 8
3.2.4. Generic QoS Profile Type . . . . . . . . . . . . 9
4. QoS Context Transfer with Handover signaling 10
5. Message Formats 12
5.1. QoS Context Transfer Request ICMP Option . . . . . . . . 12
6. QoS Context Transfer Reply ICMP Option 13
6.1. QoS Context Transfer Request SHIN Suboption . . . . . . . 14
6.2. QoS Context Transfer SHAK Suboption . . . . . . . . . . . 14
7. Configurable Parameters 14
8. Security Considerations 15
9. IANA Considerations 15
A. QoS Acknowledgment Response Codes 17
A.0.1. QoS Profile Unavailable Acknowledgment Code Format 17
A.1. QoS Context Transfer Error SHAK Suboption . . . . . . . . 17
A.1.1. Resource Unavailable Error Data Format . . . . . 18
A.1.2. Bad Format Error Data Format . . . . . . . . . . 18
A.1.3. Context Unavailable Error Data Format . . . . . . 19
Addresses 20
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 1]
Internet Draft QoS Context Relocation 13 July 2001
1. Introduction
Over the past few years, Quality of Service (QoS) has emerged as a
crucial technology for IP networks. Considerable work has taken place
in IETF and in research circles to advance this technology leading to
a better understanding of its feasibility in a network the size of the
Internet. However, very little work has taken place considering QoS
with device mobility. Specifically, how to maintain and support QoS
for a mobile node's packet streams when it changes its access routers
is a problem of considerable interest, especially for those interested
in designing mobility protocols that offer seamless ``services'' across
handovers.
The QoS mechanism offered in a network could be based either on
Differentiated Services architecture (DiffServ)[9], or an Integrated
Services architecture (IntServ)[8], or a combination of Intserv in
the access network and DiffServ in the core network (Intserv over
DiffServ)[10]. It is also possible that QoS is simply a default
Best-Effort service as it is in today's Internet. In any case, prior
to handover, a Mobile Node (MN) attached to its Previous Router (Prtr)
receives certain amount of QoS from the network. When the handover
takes place, for seamless operation, the New Router (Nrtr) must receive
the appropriate QoS state. The failure to possess this state could
result in having to re-establish the QoS, potentially end-to-end, which
could delay the establishment of the proper connections throughout the
network.
We take the position that context transfer is one of the components
of seamless handovers. In any network, discovery of neighboring access
router capabilities is an important, independent process that provides
necessary information to effect seamless handovers. Once the target
access router capability is known, context transfer could transmit only
the required state information. When detailed capability information
regarding the target router is not available however, context transfer
has to be more generic, transferring the existing state assuming that it
would be useful at the receiver. In any case, this transfer of feature
contexts has to be synchronized with the actual handover of the mobile
node from one access router to another. It is important to bear in mind
that any feature context state is tightly related to packet forwarding.
This state could quickly get inconsistent if it does not intrinsically
follow the handover protocol which establishes basic packet forwarding.
While it is important to be able to effect context transfers with
handovers, it is also important that context transfers are not dependent
upon any particular handover mechanism.
Driven by the postulation in the preceding paragraph, we focus in
this document to define feature contexts for QoS which can be used
along-with handover signaling. We assume that a separate target
router selection process guides the context transfer protocol about
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 2]
Internet Draft QoS Context Relocation 13 July 2001
the destination of context transfer. We demonstrate how the context
definitions can be used with Fast Handover signaling for Mobile IPv6.
For this purpose, we make use of the new seamless handover options
defined in [3] and specific options for QoS defined in this document.
Using the introduction in [3], we define QoS Profile Types, which
capture the specific QoS state parameters present at an access router.
We define certain major profile types expected to be generally useful.
These definitions are provided in Section 3.
The mechanism described in section 4 closely follows the structure
in [7] for the transfer of Header Compression context.
In the rest of this document, we use Figure 1 as the reference for
discussion.
v +------------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (Prtr) | < \
MN | | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (Nrtr) | <
MN | |
+------------+
Figure 1: Reference Diagram
2. Terminology
We define the following terms for use in this document.
HAck Message
The ICMP Handover Acknowledgment message, sent from the
New Router to the Previous Router, and defined in [6].
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 3]
Internet Draft QoS Context Relocation 13 July 2001
HI Message
The ICMP Handover Initiate message, sent from the
Previous Router to the New Router, and defined in [6].
New Router (Nrtr)
The router to which the MN attaches after handover
Previous Router (Prtr)
The MN's default router prior to handover
New access address (Naddr) The access IP address of the Mobile
Node (MN) when attached to the link served by the New
Router
Previous access address (Paddr)
The access IP Address of the Mobile Node (MN) when
attached to the link served by the Previous Router
Context Identifier (CID)
A 16-bit unsigned integer that identifies a particular
QoS context.
Compression Profile Type (CPT)
A 16-bit unsigned integer that indicates the type of QoS
(see section 3).
SHAK Message
Any IPv6 message received by the mobile node containing
the SHAK Destination Option defined in [3].
SHIN Message
Any IPv6 message sent by the mobile node containing the
SHIN Destination Option defined in [3].
SHREP Message
The ICMP Smooth Handover Reply message, sent between
access routers, and defined in [3].
SHREQ Message
The ICMP Smooth Handover Request message, sent between
access routers, and defined in [3].
3. QoS Profile and QoS Profile Types
A QoS Profile specifies the structure of the state variables which
are used for QoS. The QoS Profile Type (QPT), on the other hand,
provides a way to indicate which kind of QoS is provided to a particular
packet stream. A QoS context thus includes QPT and the corresponding
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 4]
Internet Draft QoS Context Relocation 13 July 2001
QoS Profile. For seamless QoS establishment, the routers located at
separate network nodes must agree on the structure of these QoS state
parameters. When the New Router receives the QoS context, it will
instantiate a QoS state machine for the packet stream in question. That
new state machine will be created with the values of the state variables
taken from the QoS Profile contained in the appropriate message, and
interpreted according to the data structure and format defined by the
QPT.
3.1. QoS Profile Type
The following QPTs are currently defined.
10: reserved
11: Best Effort
12: IntServ Controlled-Load Service
13: IntServ Guaranteed Service
14: DiffServ default
15: DiffServ srTCM
16: DiffServ trTCM
17: Generic
Each QPT value is allocated an IANA type number. The size of each
QPT is well-defined and is fixed. A value of zero has special meaning
in suboption processing as outlined in Section 4. This list in not
exhaustive. For instance, there are different possible meters in a
DiffServ router architecture that would maintain different QoS states
and request different QPT.
Some discussion regarding flow monitoring and metering is in order.
The monitoring and metering of the microflow behavior is usually done
using token buckets or some averaging process. When token bucket
schemes are used, the only dynamic parameter is the token count. Thus,
this parameter should be provided to the relevant token bucket at the
New Router. If this parameter arrives after the service has started at
the New Router, then the new bucket count SHOULD be updated by taking
into account the value of the previous token count. For instance, for
a buffer of depth B with a bucket count b1 at Previous Router, and a
buffer of depth B with a bucket count b2 not taking into account the
history of the flow, then, upon arrival of the QoS context, the new
buffer count should be adjusted to b3 = max( b2 + (b1-B),0).
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 5]
Internet Draft QoS Context Relocation 13 July 2001
In the case of a moving average, the new rate at the New Router
SHOULD be initialized to the corresponding value in the QoS Profile.
If the value and the early computation of the moving average starts
before the arrival of the QoS context, then, upon arrival of the QoS
context, the value of the moving average SHOULD be updated by taking
into account the value of the previous rate. For instance, for a rate
r1 at the Previous Router, and a rate r2 at the New Router, then, upon
arrival of the QoS context, the new rate should be adjusted to r3 = p*r2
+ (1-p)*r1, with p = (time spent at New Router)/(total time length of
the connection).
In the case of an average rate, the dynamic state is this rate. The
rate at New Router has to be initialized to this value, with a weight
corresponding to the length of the connection. The Previous Router MUST
provide a QoS Profile that the New Router can use. This means that the
Previous Router must chose the format corresponding to the New Router
and attempt to fill it with its own data. If it does not understand the
format corresponding to the New Router, then it MUST provide a generic
QoS Profile.
3.2. Examples of QoS Profile Data Structures
We define a few example QoS Profile object formats. We expect other
QoS Profiles to be similar to these examples. Once again, the following
list is not exhaustive. However, we do not expect a large number of
such data structures either.
3.2.1. Best Effort QoS Profile Type
The QPT-BE is the context maintained by a router that does not
distinguish between the packet streams. It does not maintain any
information besides the fact that the router does not keep microflow
states.
It is the default QPT if no other one is provided. The QPT code for
BE is 11 (cf. Section 3.1).
3.2.2. ``Default'' Intserv QoS Profile Type
We present here the default IntServ QoS Profile. The QPT code for
this profile type is 12. It is to be used when the IntServ type is
Controlled-Load service or when it is not known.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 6]
Internet Draft QoS Context Relocation 13 July 2001
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 | Type (TBD) | Length | QPT-BE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Best-Effort QoS Profile Option
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 | Type (TBD) | Length | QPT-Default-Intserv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 |QoS Requirement(16-bit integer)| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Measured Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Initial Token Count at New Router (32 bit IEEE fl. pt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Connection Length (timestamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Flags (future use) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Composition of QoS Profile for default IntServ
The QoS Context for a Controlled-load IntServ connection uses
the single token bucket specified in [13]. There is only one state
variable, the current token count, that becomes the initial token count
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 7]
Internet Draft QoS Context Relocation 13 July 2001
at the New Router once context is established. If the Previous Router
is not an IntServ Router, then it is unable to fill this specific field.
It sets the field either to a infinite value, meaning that the New
Router would set it to the bucket size, or to the bucket size requested
by the Burstiness parameter, if this parameter is available.
The connection length field keeps track of the time the flow is in
use.
3.2.3. DiffServ trTCM QoS Profile Type
We present here the DiffServ two rates Three Color Marker QoS Profile
Type. It is one of the metering/marking devices introduced in the
DiffServ MIB (presented for instance in [11]). The QoS Context state
that has to be transferred is composed of the configuration state and
the monitoring state. Thus the state would be different for different
meters. The trTCM is defined in [12].
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 8]
Internet Draft QoS Context Relocation 13 July 2001
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 | Type (TBD) | Length | QPT-Diffserv-trTCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 |QoS Requirement(16-bit integer)| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Committed Information Rate (32-bit IEEE floating point number)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Burstiness:Committed Bucket Size(32-bit IEEE floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Peak Information Rate (32-bit IEEE floating point number)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Burst Size (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Minimum Policed Unit (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Maximum Packet Size (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | New Router initial Committed Token Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | New Router initial Peak Token Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Connection length (time stamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Flags (future use) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Composition of QoS Profile for Diffserv trTCM
3.2.4. Generic QoS Profile Type
The Previous Router uses this profile when it does not know the
capability of the New Router or when it does not understand the New
Router's capability.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 9]
Internet Draft QoS Context Relocation 13 July 2001
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 | Type (TBD) | Length | QPT-Generic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 |QoS Requirement(16-bit integer)| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Data Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Burstiness:Token Bucket Size(32-bit IEEE floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Peak Rate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Burst Size (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Minimum Policed Unit (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Maximum Packet Size (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Average Measured Data Rate (32-bit IEEE floating point number)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | New Router initial Burst Token Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | New Router initial Peak Token Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Connection length (time stamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Flags (future use) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Composition of Generic QoS Profile
4. QoS Context Transfer with Handover signaling
In this section, we provide an illustration of how the QoS Profiles
and QPTs defined in the previous section can be transferred along-with
handover signaling. Note that these QoS Contexts (i.e., QPT plus QoS
Profile) can be carried in other forms of messages as well, e.g.,
they could be carried in a Paging Message [14]. We use fast handover
signaling for Mobile IPv6 for our illustration here.
The Previous Router, in response to either the network-initiated
handover or the mobile-initiated handover, sends a HI message to
the New Router. In this HI message, it includes the Unsolicited
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 10]
Internet Draft QoS Context Relocation 13 July 2001
Seamless Handover Reply (U-SHREP) option defined in [3], which carries
the appropriate QoS contexts. The actual QPT and the QoS Profiles
carried may depend on the knowledge the Previous Router has regarding
the New Router's QoS capabilities. The Unsolicited SHREP option
carries an authentication token for the New Router to verify prior to
authorizing the feature contexts. This token uses the session key that
gets established when the MN first connects to the Previous Router.
Alternative to carrying the token, the Unsolicited SHREP message could
instead carry the session key itself as one of the sub options. In any
case, the network policy may require the New Router to authenticate the
MN prior to granting network access as well as feature contexts. In
such a case, the MN has to respond to an appropriate challenege from
the New Router providing its own token that must match the one that the
New Router possesses. The details of this mechanism described in [14]
for IP paging are applicable for our purposes here. Once authorized
(whenever enforced), the New Router makes QoS contexts available to the
MN. The New Router SHOULD include a SHREP-Ack option in the HAck message
to the Previous Router.
When fast handover signaling is either not available or fails, the
New Router fetches context subsequent to the MN's attachment to it.
The MN sends a SHIN message containing its Previous IP address and
Previous Router address to the New Router. This SHIN can be embedded
as an option in the network access authentication message [15]. In
response to the SHIN message, recognizing that the required state is not
available, the New Router transmits a Seamless Handover Request (SHREQ)
message with QoS sub options. And, the Previous Router responds back
with a Seamless Handover Reply (SHREP) message containing the actual
QoS context information. See [3] for the details. In this case, the
QoS context that is provided to the New Router is only the relevant
QoS context. For instance, the two routers providing IntServ QoS can
exchange a context that has an IntServ granularity.
Observe that even optimal handover procedures sometimes fail due
to the real-world dynamics including unpredictable physical terrains,
spotty coverage areas etc. For instance, due to unfavorable terrain
conditions, the MN may lose link connectivity with its current AR and
establish a new link with a new AR. In such a case, the New Router
does not necessarily know the MN's Previous Router and its Previous IP
address. However, the MN can supply this information, and it does this
by including it in the SHIN message. Since there is no established
means for a MN to be certain that the New Router has knowledge of its
Previous Router and its Previous IP address (which is necessary to
identify the contexts), we propose including the SHIN option in all the
handover scenarios. When context is already present at the New Router,
SHIN facilitates explicit authorization of feature contexts. When the
context is not present, it triggers reactive context transfer.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 11]
Internet Draft QoS Context Relocation 13 July 2001
5. Message Formats
QoS options and suboptions are defined for use in several different
protocol message types:
- as an option or a sub option to a HI, HAck, SHREQ, or SHREP
ICMPv6 messages.
- as a suboption of an IPv6 destination option.
- as an extension to a Mobile IPv4 registration request to be
processed by a Foreign Agent.
- as an extension to some other seamless handover message to be
defined in the future for mobile nodes using IPv4.
The general format for the options is the same in all cases, as shown
in Figure 6.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSOpt Type | QOSOpt Len | QOSOpt Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: QoS Options, Suboptions and Extension Format
5.1. QoS Context Transfer Request ICMP Option
The QOSReq suboption is sent by Nrtr to Previous Router in the SHREQ
message to obtain QoS context on behalf of the mobile node.
The New Router MAY request all of the relevant QoS context associated
with the mobile node, by sending QOSReq with suboption length equal to
zero.
Suboption Type: QOSReq-ICMP
Suboption Length: Variable
The processing of this ICMP option at the Previous Router depends on
the availability of required QoS state, and is done in accordance with
requirements outlined in Section 3.2. The New Router MUST respond with
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 12]
Internet Draft QoS Context Relocation 13 July 2001
the SHAK suboption defined in section 4.4. The New Router, possibly
using the information sent by the Previous Router, MAY include suboption
QOSErr (defined below) in the SHAK message.
6. QoS Context Transfer Reply ICMP Option
The QoS Context Transfer Reply suboption (QOSRep) suboption is
defined for Prtr to transfer state to Nrtr in the HI or SHREP ICMP
messages. The QOSRep suboption includes the necessary state for Nrtr to
seamlessly carry-over QoS.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | QPT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS State Variables ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: QoS Reply Data Element
The Option Type and Option Length fields of the QOSRep ICMP option
are followed by blocks consisting of [CID, QPT, QoS State variables]
tuple(s). Each block has the format illustrated in Figure 7.
CID Context Identifier
QPT QoS Profile Type
QoS State Variables
Values for QoS state variables, in the format defined by
the QPT
The CID and QPT are 16-bit fields. For a particular QPT, the size of
QoS state variables field is fixed; this allows inclusion of multiple
tuples without requiring a length indicator.
If the suboption length is zero, it indicates that Prtr cannot supply
the required QoS level to Nrtr. In case of errors, Prtr SHOULD include
the QOSErr suboption defined in section 4.5 in the SHREP message.
When the value of QPT is zero in a tuple, it indicates that the
Previous Router cannot supply state information for the associated
context identified by the CID. In this case also, Prtr SHOULD
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 13]
Internet Draft QoS Context Relocation 13 July 2001
include suboption QOSErr (e.g., to indicate that suboption QOSReq was
incorrectly formatted) in the packet.
6.1. QoS Context Transfer Request SHIN Suboption
When the mobile node wishes to continue receiving the same level
of QoS at Nrtr, it sends the QoS Context Transfer Request (QOSReq)
suboption in a message addressed to Nrtr containing a SHIN Destination
Option.
Suboption Type: QOSReq-SHIN
Suboption Length: Variable
When the QOSReq is present in a SHIN message and the suboption length
is zero (the default value), this suboption indicates the MN's desire to
continue with the same QoS features as prior to handover.
6.2. QoS Context Transfer SHAK Suboption
The QoS Context Transfer Acknowledge suboption (QOSAck) is defined
for inclusion in the SHAK IPv6 Destination Option, and is used by Nrtr
to respond to the mobile node. Note that SHAK is an optional message.
The MN SHOULD be prepared to accept packets treated with feature
contexts even when it does not receive a SHAK message.
Suboption Type: QOSAck-SHAK
Suboption Length: Variable
When the suboption length is zero (the default value), this suboption
indicates that MN's request to continue with the QoS level was accepted
at Nrtr without any modifications to the context parameters.
When the suboption length is non-zero, the QOSAck data has the format
shown in Figure 8.
Each acknowledgment code specifies the format of the QOSAck data
field, which contains the data associated with the acknowledgment. The
currently defined acknowledgment codes are described in the appendix.
7. Configurable Parameters
The nodes supporting mobility defined in this document SHOULD be able
to configure the parameters outlined below as well those in [4]. Each
table entry contains the name of the parameter and the default value.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 14]
Internet Draft QoS Context Relocation 13 July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSAck Code | QOSAck Len | QOSAck Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: QoS Context Transfer SHAK Suboptions (QOSAck) format
Parameter Name Default Value
-------------------------------------------------
QOS\_CONTEXT\_SAVE\_TIME 2 * SHREQ\_REXMIT\_TIME
QOS\_CONTEXT\_PURGE\_TIME 5 * SHREQ\_REXMIT\_TIME
SHIN\_WAIT\_TIME 1000 milliseconds
8. Security Considerations
All context transfer for QoS MUST be secured by use of the
Authentication suboption [4], or the IPv6 Authentication Header [2].
Thus, no additional vulnerability has been introduced.
9. IANA Considerations
The QoS Profile Type (QPT) defined in this document requires IANA
Type numbers.
References
[1] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) (work in progress). Internet Draft, Internet
Engineering Task Force, May 2000.
[2] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[3] R. Koodli and C. Perkins. A Context Transfer Framework for
Seamless Mobility (work in progress). Internet Draft, Internet
Engineering Task Force. draft-koodli-seamoby-ctv6-00.txt,
February 2001.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 15]
Internet Draft QoS Context Relocation 13 July 2001
[4] R. Koodli and C. Perkins. A Framework for Smooth Handovers
with Mobile IPv6 (work in progress). Internet Draft, Internet
Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt,
November 2000.
[5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[6] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in
progress). Internet Draft, Internet Engineering Task Force.
draft-designteam-fast-mipv6-01.txt, February 2001.
[7] R. Koodli, M. Tiwari, C. Perkins. Context Relocation
for Seamless Header Compression in IP Networks (work in
progress). Internet Draft, Internet Engineering Task Force.
draft-koodli-seamoby-hc-relocate-00.txt
[8] J. Wroclawski. The Use of RSVP with IETF Integrated Services.
RFC 2210, Internet Engineering Task Force.
[9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.
An Architecture for Differentiated Service. December 1998. RFC
2475, Internet Engineering Task Force.
[10] Y. Bernet et al., A Framework for Integrated Services Operation
over Diffserv Networks. RFC 2998, Internet Engineering Task
Force.
[11] Bernet et al., DiffServ Informal Management Model,
draft-ietf-diffserv-model-06.txt (work in progress)
[12] J. Heinanen, A two rate Three Color Marker, RFC 2698
[13] S. Shenker, J. Wroclawski, General Characterization Parameters
for Service Network Elements, RFC 2215.
[14] R. Koodli and J. T. Malinen. Idle-mode Context
Transfers in IPv6 Networks (work in progress).
Internet Draft, Internet Engineering Task Force.
draft-koodli-seamoby-idle-mode-ctv6-00.txt, July 2001
[15] N. Asokan, Patrik Flykt, C. Perkins and Thomas Eklund. AAA for
IPv6 Network Access (work in progress). Internet Draft, Internet
Engineering Task Force.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 16]
Internet Draft QoS Context Relocation 13 July 2001
A. QoS Acknowledgment Response Codes
In this section, we define the various error codes sent back to the
MN in response to its request for QoS context transfer.
A.0.1. QoS Profile Unavailable Acknowledgment Code Format
The QoS Acknowledgment Code block for QPT_UNAVAILABLE is as shown in
Figure 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSAck Code=2 | Length | [CID,New-CID] pairs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: QPT UNAVAILABLE acknowledgement Data format
Code: 02 (QPT_UNAVAILABLE)
Length: Variable
The data for the QPT_UNAVAILABLE acknowledgment code consists
of [CID, New-QPT] tuple(s), one for each requested QPT that was
unavailable. When the value of QPT is zero in a tuple, it indicates
that the associated context identified by the CID was not activated. In
this case, Nrtr MAY include suboption QOSErr with an appropriate error
code indicating the reason for failure to activate the context.
A.1. QoS Context Transfer Error SHAK Suboption
The QoS Context Transfer SHAK Error Suboption (QOSErr) allows the
access routers to supply error codes when activation fails for one or
more QoS level requests. The QOSErr data format is shown in Figure 10.
Suboption Type: QOSErr-SHAK
Suboption Length: Variable
Each error code specifies the format of the QOSErr data field, which
contains the data associated with the error condition. The currently
defined error codes are specified in the following sections.
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 17]
Internet Draft QoS Context Relocation 13 July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSErr Code | QOSErr Length | QOSErr Error Code Blocks...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: QoS Context Transfer Error Format
A.1.1. Resource Unavailable Error Data Format
The QoS Error Code block for RESOURCE_UNAVAILABLE is as shown in
Figure 11.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSErr Code=1 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: RESOURCE UNAVAILABLE error format
Code: 01 (RESOURCE_UNAVAILABLE)
Length: 0
The RESOURCE_UNAVAILABLE error has no associated error data. This
error is returned when no resources are available. This code indicates
that Nrtr does not have the resources required to set up QoS context(s)
for this MN. The MN MUST deactivate the previous QoS state. It MAY
either start sending packets expecting only Best Effort service in this
case, or it may re-negotiate with Nrtr to activate a new QoS level and a
QoS profile.
A.1.2. Bad Format Error Data Format
The QoS Error Code block for BAD_FORMAT is as shown in Figure 12.
Code: 02 (BAD_FORMAT)
Length: Variable
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 18]
Internet Draft QoS Context Relocation 13 July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSErr Code=2 | Length | Offending Suboption ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: BAD FORMAT error format
This error indicates that the context transfer request was poorly
formatted. If a router does not understand the format of a particular
suboption, it sends QOSErr with this code; and the data part contains
the
details of the suboption which caused this error. The Previous
Router SHOULD send this suboption to Nrtr whenever appropriate, and Nrtr
MAY send this suboption to the MN.
A.1.3. Context Unavailable Error Data Format
The QOS Error Code block for CONTEXT_UNAVAILABLE is as shown in
Figure 13.
Code: 03 (CONTEXT_UNAVAILABLE)
Length: Variable
The QOSErr data for this code contains the CIDs representing contexts
which are not available for transfer. This might happen because
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSErr Code=3 | Length | Unavailable CIDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: CONTEXT UNAVAILABLE error format
the context has already been removed at both the routers in the
fast handover case. Note that Nrtr MAY remove the state supplied
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 19]
Internet Draft QoS Context Relocation 13 July 2001
by Prtr if Nrtr does not receive a SHIN message from the MN within
QOS_CONTEXT_SAVE_TIME.
Addresses
Questions about this memo can also be directed to the authors:
Cedric Westphal Rajeev Koodli
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2247 Phone: +1-650 625-2359
EMail: cedric@iprg.nokia.com EMail: rajeev.koodli@nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Charles Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Westphal, Koodli, Perkins Expires 12 January 2002 [Page 20]