Subject: [seamoby] Idle-mode CT, QoS CT draft submissions

From: Rajeev Koodli <[email-masked]>
Date: Fri, 13 Jul 2001 14:23:15 -0700

Hello folks,

we have submitted the following drafts to the ID registrar. I am
attaching(sorry) them here for consideration by the group.

1. draft-westphal-seamoby-qos-relocate-00.txt.

2. draft-koodli-seamoby-idle-mode-ct-00.txt

Comments are welcome and will be appreciated.

Best Regards,

-Rajeev

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:  [email-masked]      EMail:  [email-masked]
      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:  [email-masked]
      Fax:  +1 650 625-2502

Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 20]

Seamoby Working Group                                      Rajeev Koodli
INTERNET DRAFT                                           Jari T. Malinen
13 July 2001                            Communication Systems Laboratory

              Idle Mode Handover Support in IPv6 Networks
                   draft-koodli-idle-mode-ctv6-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 mobile-ip 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

This document considers the problem of expediting authenticated network
access as well as enabling authorized context transfer during idle-mode
handovers.  In essence, this document addresses idle-mode context
transfers, so that an idle-mode Mobile Node (MN) can resume its sessions
in a seamless fashion.  We propose supplying the session key in the
paging message to the Access Router (AR) that locates the idle Mobile
Node.  Subsequently, the AR issues a local challenge in the router
advertisement, and the MN replies with a hash of session key, its
previous IP address and the local challenge.  The new AR grants network
access once its own hash matches that supplied by the MN. We demonstrate
how this simple procedure can be used for any generic context transfers.

Koodli, Malinen            Expires 13 January  2002             [Page i]

Internet Draft          Idle Mode Handover Support          13 July 2001

                                Contents

Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        3

 3. Idle Handover Considerations                                       4

 4. Protocol Messages                                                  6
     4.1. Key Distribution Extension to the Paging Message  . . . .    6
     4.2. Context Transfer Extension to the Paging Message  . . . .    7
     4.3. Router Advertisement with AAAv6 Local Challenge . . . . .    8
     4.4. AAAv6 Request for Idle Mode Handover Support  . . . . . .   10
     4.5. AAAv6 Reply for Idle Mode Handover Support  . . . . . . .   12

 5. Protocol Constants                                                14

 6. Security Considerations                                           14

Addresses                                                             15

Koodli, Malinen            Expires 13 January  2002             [Page 1]

Internet Draft          Idle Mode Handover Support          13 July 2001

1. Introduction

When a MN powers up in a visited domain and obtains link connectivity
with the network, a network policy may require that MN performs network
layer authentication prior to obtaining IP connectivity.  This is
critical in order to provide a mechanism for the network provider to
ensure unabused network access.  The specification in [1] outlines a
mechanism based on ICMP protocol that could be used in conjunction with
other protocols, such as IPv6 address auto-configuration and Mobile
IPv6, in order to provide this kind of network layer authentication.
Provided the MN is authorized to access the network, this protocol then
enables a security association between a MN and its default Access
Router (AR) and supplies both the entities the necessary security
keys.  The MN then uses the supplied key in securing its communication,
whenever necessary, with its AR.

             v                     +------------+
           +-+                     |  Previous  |
           ! ! -----------------   |  Access    |
           +-+                     | Router(PAR)|
               MN                  |            |
            |                      +------------+
            |                            |
            |                            | IP Paging Message
            |                            |
            |                            V
            |                ...........................
            |               .                           .
            |              .   Paging area multicast     .
            V             .           group               .
                         .                                 .
             v        +------------+  +------------+  +------------+
           +-+        |    New     |  |    New     |  |    New     |
           | | -------|  Access    |  |  Access    |  |  Access    |
           +-+        | Router(NAR)|  | Router(NAR)|  | Router(NAR)|
              MN      |            |  |            |  |            |
                      +------------+  +------------+  +------------+

          Figure 1: Reference Scenario for Idle-Mode Handover

Once authorized to use the network prefix advertised by the AR, the MN
may proceed to send IP packets.  For instance, the MN may send a Binding

Koodli, Malinen            Expires 13 January  2002             [Page 2]

Internet Draft          Idle Mode Handover Support          13 July 2001

Update to its Home Agent to inform about its new location.  Note that
for performance reasons, it is possible to combine the Binding Update
with network authentication messages, as proposed in [1].  Here, we
assume a logical separation between the two protocols.  Nevertheless,
the MN may then engage in active packet transmission and reception, or
it may remain idle.  Observe that the MN may establish feature contexts
for its packet streams and then enter idle-mode.  For example, the MN
may establish QoS context for its `www' traffic, engage in active data
communication, and then transition to idle state.  Furthermore, the MN
may enter idle mode even while engaged in active communication due to
the bursty nature of packet data communication.  Subsequently, the MN
undergoes a handover while remaining in idle-mode.  See Figure 1

The purpose of this document is to address the problem of expeditiously
authenticating network access (for the MN) as well as authorizing feature
contexts (to the MN) during idle-mode handovers.  In essence, this
document addresses idle-mode context transfers, so that an idle-mode
Mobile Node (MN) can resume its sessions in a seamless fashion.  We
propose a solution using simple extensions to paging messages that would
allow us to meet our objectives without the need for a dedicated paging
server or additional entries in the routing tables.

2. Terminology

      Mobile Node       A host that attaches to a network, untethered or
                        otherwise, and changes its point of attachment
                        due to host mobility.

      Idle mode         A state internal to a Mobile Node in which the
                        MN is not in active packet transmission or
                        reception.  This definition assumes that it is
                        possible for a MN to enter idle mode, e.g., due
                        to silence intervals, when it has an active
                        traffic channel.

      Paging            A mechanism by which a network locates a MN
                        in idle mode, in order to, e.g., deliver an
                        incoming packet [3].

      (Access) Authentication The process by which an Access Router
                        (AR) verifies the MN's credentials and grants
                        (authorizes) network access [1].

      Context Transfer  The process by which state information
                        pertaining to a MN is transferred from one AR
                        to another, perhaps to facilitate seamless
                        operation of applications running on the MN [6].

Koodli, Malinen            Expires 13 January  2002             [Page 3]

Internet Draft          Idle Mode Handover Support          13 July 2001

3. Idle Handover Considerations

We begin with a set of assumptions.  First, we assume that each paging
area is uniquely identified by an IP multicast group called ``all access
router's multicast group'', whose members are the ARs that constitute
the paging area.  Second, a Mobile Node does not perform paging area
registrations when inside the same paging area.  The mechanisms by which
a MN determines that it is within the boundary of the same paging area
are beyond the scope of this document.  It may make use of any known
mechanism; for example, it may make use of the paging area identifier
typically advertised on the broadcast channel to determine its location
with respect to the paging area.  Third, an AR originates an IP paging
message when it determines that it cannot deliver an IP packet to its
MN. The mechanism by which an AR determines that a MN that was attached
to it is no longer visible is not specified in this document.  An
AR may be able to realize this by, for example, explicit idle mode
registrations or (implicitly) via timer expirations.  Note that because
of this assumption, we see no reason for a specialized paging server in
our discourse.  Note also that there is no need for additional routing
table entries in this model.  Finally, we assume that all the members of
the all access routers multicast group share security association with
each other.

We consider the two idle mode scenarios outlined earlier.  We start
with the case where the MN moves without having initiated active data
communication.

Recall that the MN first establishes network connectivity.  This means,
at the very least, the state corresponding to security association
should be present at both the MN and its default AR. Now, let us assume
that the MN moves to a subnet controlled by a different AR, yet within
the same paging area.  As mentioned earlier, we assume that the MN does
not send a paging area registration message if operating within the
same paging area.  This assumption is necessary since a paging area
registration may entitle the MN to IP connectivity, in which case, the
routing of IP packets follows normal Mobile IP procedures.  Now, if a
packet arrives at the previous AR for the MN, the previous AR has to
locate the MN in order to deliver the packet.  We assume that an IP
paging message would be available for this purpose.  Whereas the exact
form and nature of such a message is not standardized yet, we will
assume the message outlined in [9], and identify extensions needed.

In [9], the PAR uses a well-known multicast address, the ``all access
routers multicast group'', to send the paging request, which we call
the ``IP paging message''.  All the ARs within the paging area are
members of this multicast group, and thus receive the paging request
packet.  Each AR then sends an unsolicited router advertisement that
contains the MN's IP address established while connected to PAR. This
message may trigger Layer 2 (L2) paging, when present, on each AR in

Koodli, Malinen            Expires 13 January  2002             [Page 4]

Internet Draft          Idle Mode Handover Support          13 July 2001

order to wake up the sleeping MN. The MN, once paged, has to determine
that it has changed its AR by verifying the source address in the router
advertisement, begin to formulate a new IP address, and then respond to
the IP paging request.

When the MN wakes up and realizes that it has changed its AR, it may be
required to perform network access authentication described earlier.
This procedure is time-consuming given the delays in accessing the MN's
home network AAA and the Home Agent.  In order to minimize this delay,
we propose to transfer the key from PAR to all the potential access
routers which are members of the ``all access routers multicast group''
in the IP paging message.  We assume that the MN first established
authenticated network access with PAR.

In the unsolicited router advertisement message that follows the IP
paging message, each AR sends and caches a random number in a local
challenge requiring the MN to return a token that is a hash of network
prefix advertised, the random number in the local challenge and the key
that the MN possesses.  Each AR uses the key supplied in the IP paging
message to compute its own hash and allows network access if the token
supplied by the MN matches its computation.  The MN uses the Embedded
Data Option in the AAAv6 Request message in [1] to include this token
as well as other information, such as the Binding Update message.  When
the AR receives the AAAv6 Request, it determines that the AAAv6 Request
message corresponds to the unsolicited router advertisement (sent in
response to the paging message) by inspecting the Embedded Data Option
containing the above-mentioned hash.

The above key transfer concept can indeed be applied to handle generic
feature contexts.  The MN's contexts at PAR are transferred gratuitously
to all the ARs in the paging area multicast group.  When the network
policy requires explicit authorization of these contexts, each AR
mandates that the MN presents a separate access authentication token
such that the AR can verify authenticity of the feature context request.
This token is generated according to HMAC-MD5-96 [7] using the random
number advertised in the Local Challenge as an input parameter.  The
details of this token computation are specified in the description of
Seamless Handover Initiate (SHIN) option [5].

We propose using the SHIN option as an embedded data in the AAAv6
request for explicit authorization of the feature context requests.
The new AR verifies that the token present in the SHIN matches its
own computation and makes the contexts available to the MN. It then
generates a SHREQ message to the PAR that originated the IP paging
message in order to set up a forwarding path for packets arriving at
PAR. The PAR SHOULD generate a SHREP message indicating the response
for the SHREQ message.  The new AR MAY send a SHAK message indicating
authorization of contexts to the MN. The MN SHOULD be prepared to handle
packets treated with feature contexts without expecting a SHAK message.

Koodli, Malinen            Expires 13 January  2002             [Page 5]

Internet Draft          Idle Mode Handover Support          13 July 2001

Note that context transfer could happen reactively following paging.
That is, the AR that locates the MN would initiate the transfer of
contexts from the PAR in response to successfully authenticating the MN
and (optionally) processing the SHIN option.  In such a scenario, only
the session key is transferred from the PAR to the members of the paging
area.  The net effect is that fewer bytes are sent in the access network
since context transfer only happens between the AR that locates the MN
and the PAR.

4. Protocol Messages

In this section, we describe new protocol messages or options used
in the protocol extensions described earlier.  When paging occurs, a
session key is passed along with the paging message.  A paging message
triggers a router advertisement which is required to contain a Local
Challenge (LC) as in AAAv6.  The router advertisement invokes the mobile
node to perform a localized AAAv6 request and reply exchange with the
AR.

4.1. Key Distribution Extension to the Paging Message

We assume that a paging entity sends a paging message containing the
IP address of the MN to a multicast group specific for the paging
area.  A paging message can be, e.g., a Paging Request Message as
specified in [9].  Since the exact form of a Paging Message has not been
standardized yet, we define a generic session key option which is shown
in Figure 2.  This option can be carried (with suitable padding whenever
necessary) in an appropriate paging message.  The receiving AR extracts
the session key from this option, where the key is encrypted using
pre-existing shared key between the originator of the paging message and
the receiving access router.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |      Alg      |   Key Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SPI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Key...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Session Key Option

Koodli, Malinen            Expires 13 January  2002             [Page 6]

Internet Draft          Idle Mode Handover Support          13 July 2001

      Type       TBD (skippable), one for key request, one for key reply

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.

      Alg        8-bit algorithm indication as specified for the
                 Authentication Header [4].

      Key Length

                  8-bit unsigned integer.  The length of the key in
                 units of 4 octets.

      SPI        32-bit Security Parameter Index value.

      Key        Encrypted key.

4.2. Context Transfer Extension to the Paging Message

A paging entity may use this option to gratuitously supply the contexts
established at PAR to all the members of the paging area.  Such an
action could provide performance benefits, since data communication
typically follows paging.  The option is shown in Figure 3.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +             One or more feature contexts                      +
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Context Transfer Option

Koodli, Malinen            Expires 13 January  2002             [Page 7]

Internet Draft          Idle Mode Handover Support          13 July 2001

      Type       (skippable) Gratuitous Context Transfer.

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.

As with the Session Key option, this option is also carried in an
appropriate paging message.  The AR that locates the MN then authorizes
the use of received contexts after successfully processing the SHIN
option from the MN.

4.3. Router Advertisement with AAAv6 Local Challenge

The paging message is received by access routers in the paging area.  A
subsequent router advertisement message, described in this section, is
sent out by each Access Router.  The router advertisement as specified
by Neighbor Discovery [8] is modified to include the local challenge as
specified in [1].  The AR uses the value in local challenge in computing
the access authentication token.

The extension appears as a Router Advertisement option shown in 4.

Koodli, Malinen            Expires 13 January  2002             [Page 8]

Internet Draft          Idle Mode Handover Support          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}|   Router Advertisement Options                                |
   |    . . .                                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type          |    Length     |  Sequence no  | Rsvd          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Challenge                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: Router Advertisement with AAAv6 local challenge

{1} Router Advertisement Options

A paging option contains the IP address of the paged MN. It is possible
to send a page to a group of dormant mobiles by associating a multicast
address with that group.  In such a case, this option includes the IP
addresses of all the paged mobiles.  May also include target Link-layer
address, Prefix Information Options, etc.

{2} AAAv6 Challenge Option in the router advertisement

      Type

         9 = ICMPv6 Router Advertisement Local Challenge Option

      Length

         1 = Length in 8 octets including the type and length fields

      Sequence Number

         a monotonically increasing integer that associates the IP
         address, Challenge and the Key tuple.  The MN supplies this
         value in addition to the hash it generates to aid the AR in
         verifying the checksum computation.

      Reserved

         0 = Ignored on reception

      Challenge

         This is a 32-bit random number generated by the access router
         and used to prevent replay attacks.

Koodli, Malinen            Expires 13 January  2002             [Page 9]

Internet Draft          Idle Mode Handover Support          13 July 2001

4.4. AAAv6 Request for Idle Mode Handover Support

This section describes the message the mobile node sends in response to
the paging router advertisement which contains an AAAv6 local challenge.
This response includes a token to facilitate expedited network access
authentication and also request for context transfer authorization.

The message the MN sends is an ICMPv6 message of AAAv6 request
type.  This AAAv6 message contains one or more Embedded Data Options.
Each Embedded Data Option (EDO) may contain sub types for various
purposes.  The two new sub types used by this extension are the access
authentication token and Seamless Handover Initiate (SHIN). The SHIN
subtype is optional if the network policy allows context authorization
based only on network access authentication.

The access authentication token contains a hash over mobile node's
previous IP address and the challenge sent in the router advertisement.
Since the paging message from the paging router to the access routers
distributes the key known to the MN and the paging router, this key is
now known by the new router which can verify whether the hash received
is valid.  If not, the packet is dropped and a diagnostics AAAv6 reply
with status AAAV6_INVALID_CREDENTIALS in the Code field is returned.

Koodli, Malinen            Expires 13 January  2002            [Page 10]

Internet Draft          Idle Mode Handover Support          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}|                                                               |
   |                         IPv6 Header...                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req  |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   (AAAv6 Request Options) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO      |Subtype=AAToken|      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |             Network Access Authentication Hash                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type=EDO      |Subtype=SHIN   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        SHIN (optional)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 5: AAAv6 request for Idle Mode Handover Support

{1} IPv6 Header

SRC = MN's new IP address; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6)

{2} ICMPv6 Header [2]

      Type

         151 (97h) [TBD] = AAAv6 Request

      Code

         0 - For AAA request, not defined

      Checksum

         Calculated as defined in [2].

Koodli, Malinen            Expires 13 January  2002            [Page 11]

Internet Draft          Idle Mode Handover Support          13 July 2001

{3} AAAv6 Embedded Data Option [1] for access authentication

      Type

         8 (unskippable) = Embedded Data Option

      Subtype

         5 = AAToken

      Length

         4 = Length of Network Access Authentication Hash in octets.

      Network Access Authentication Hash

          A 16-byte result of a pseudo-random function, such as
         HMAC-MD5-96, computed over the identity-providing old CoA,
         freshness-providing random number (LC), and the session key.

{4} AAAv6 Embedded Data Option [1] for SHIN

      Type

         8 (unskippable) = Embedded Data Option

      Subtype

         6 = SHIN

      Length

         4 = Length of SHIN in octets.

      SHIN

         Seamless Handover Initiate message.

4.5. AAAv6 Reply for Idle Mode Handover Support

In this section, we provide the extended AAAv6 reply to the AAAv6
request for idle mode context transfer support.  Note that the request
for context transfer was embedded to an EDO containing the SHIN message.
Here a similar new and optional EDO contains the optional SHAK.

{1} IPv6 Header

Koodli, Malinen            Expires 13 January  2002            [Page 12]

Internet Draft          Idle Mode Handover Support          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}|                                                               |
   |                         IPv6 Header...                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req  |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   (AAAv6 Reply Options) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO      |Subtype=SHAK   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        SHAK (optional)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 6: AAAv6 reply for Idle Mode Handover Support

SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6)

{2} ICMPv6 Header [2]

      Type

         [TBD] = AAAv6 Reply

      Code

         The success code for AAAv6 Reply.

      Checksum

         Calculated as defined in [2].

{3} AAAv6 Embedded Data Option [1] for SHAK

      Type

         8 (unskippable) = Embedded Data Option

Koodli, Malinen            Expires 13 January  2002            [Page 13]

Internet Draft          Idle Mode Handover Support          13 July 2001

      Subtype

         7 = SHAK

      Length

         Length of SHAK in octets.

      SHAK

         Seamless Handover Acknowledgment.

5. Protocol Constants

Three new sub-types for AAAv6 Embedded Data Option are needed, one
for access authentication token, and one for SHIN, and SHAK options,
respectively.

6. Security Considerations

This protocol assumes that when the mobile node arrives at a visited
domain, it performs a secure initial registration, after which there
is a mobile-visited domain session key in both the mobile node and the
first visited-domain router.  Also, there is a pre-existing common
security association between all nodes in a paging area multicast group.

Using the assumed associations, the paging causes the session key to
be provided to the new access router which can use it to verify both
authenticity of the received AAAv6 request as well as the authorization
token present in the SHIN message.  These mechanisms used together with
AAAv6 provide authorized idle mode context transfers.

Koodli, Malinen            Expires 13 January  2002            [Page 14]

Internet Draft          Idle Mode Handover Support          13 July 2001

References

   [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund.  AAA for
       IPv6 Network Access (work in progress).  Internet Draft, Internet
       Engineering Task Force, March 2000.

   [2] A. Conta and S. Deering.  Internet Control Message Protocol
       (ICMPv6) for the Internet protocol version 6 (ipv6)
       specification.  Request for Comments (Draft Standard) 2463,
       Internet Engineering Task Force, December 1998.

   [3] J. Kempf.  Dormant mode host alerting (ip paging) problem
       statement.  Request for Comments (Informational) 3132, Internet
       Engineering Task Force, June 2001.

   [4] S. Kent and R. Atkinson.  IP Authentication Header.  Request for
       Comments (Proposed Standard) 2402, Internet Engineering Task
       Force, November 1998.

   [5] R. Koodli, , and C. Perkins.  A context transfer framework for
       seamless mobility (work in progress).  Internet Draft, Internet
       Engineering Task Force, July 2000.

   [6] et al. Levkowetz, O. H.  Problem description:  Reasons for
       performing context transfers between nodes in an ip access
       network (work in progress).  Internet Draft, Internet Engineering
       Task Force, June 2001.

   [7] C. Madson and R. Glenn.  The Use of HMAC-MD5-96 within ESP and
       AH.  Request for Comments (Proposed Standard) 2403, Internet
       Engineering Task Force, November 1998.

   [8] 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.

   [9] B. Sarikaya, J. Haverinen, H.and Malinen, and V. Magret.  Mobile
       ipv6 regional paging (work in progress).  Internet Draft,
       Internet Engineering Task Force, November 2000.

Addresses

Questions about this memo can also be directed to the authors:

Koodli, Malinen            Expires 13 January  2002            [Page 15]

Internet Draft          Idle Mode Handover Support          13 July 2001

     Rajeev Koodli                   Jari T. Malinen
     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-2359         Phone:  +1-650 625-2355
     EMail:  [email-masked] EMail:  [email-masked]
     Fax:  +1 650 625-2502           Fax:  +1 650 625-2502

Koodli, Malinen            Expires 13 January  2002            [Page 16]