georgiades-seamoby-ctecip-01.txt

Internet DRAFT - draft-georgiades-seamoby-ctecip

draft-georgiades-seamoby-ctecip

Last Version:	draft-georgiades-seamoby-ctecip-01.txt	Tracker Entry
Date:	`02-Feb-2004`
Disposition:	removed
Previous Versions:	draft-georgiades-seamoby-ctecip-00.txt (diff) - 01-Jul-2003

SEAMOBY Working Group M. Georgiades
Internet Draft C. Politis
<draft-georgiades-seamoby-ctecip-01.txt> N. Akhtar
R. Tafazolli
University of Surrey, UK

June 2003
Expires: December 2003

Context Transfer Extension to Cellular-IP

Status of This Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.

Abstract
This Internet draft enhances cellular-IP mobility protocol with a
Context Transfer mechanism aiming to further optimise the handoff
operation in mobile networks. During the handoff operation from one
cellular-IP base station to another, cellular-IP packets could be
used to initiate and transfer authorised context from the previous
cellular-IP base station via the cellular-IP gateway(s) to the new
cellular-IP base station. This draft presents how the context
transfer extensions introduced could facilitate in reducing latency
and packet loss by avoiding the signalling required between the
mobile node and the new base station in re-establishing the desired
state information.

Georgiades, Politis Expires-December 2003 [Page 1]

INTERNET-DRAFT Context Transfer Extension to CIP March 2003

1. Introduction

The cellular-IP protocol has been designed to provide local mobility
and handoff support for frequently moving mobile hosts. Cellular IP
can interwork with other mobility protocols like Mobile IP [8] and
SIP [9] to support wide area mobility. During or immediately after
handoff, packet losses may occur due to delayed propagation of the
new location information.

The aim of cellular-IP is to minimize these packet losses in order to
avoid a degradation of service quality as handoffs become more
frequent.

When a mobile host moves to a new base station it also needs to
establish certain context transfer candidate services that have
already been established at the previous base station and left
behind. Such services include header compression, multicast group
membership number, QoS policy, AAA profile and IPsec state. Re-
establishing these services at the new base station will require a
considerable amount of time for the protocol exchanges and as a
result time-sensitive real-time traffic will suffer during this time.
On the contrary preserving the context of the IP flows can contribute
towards the seamless operation of the handoff.

The extensions to cellular-IP proposed in this draft are to offer
extra functionality for forwarding the desired state information at
the new base station. This context transfer mechanism will
result in quick re-establishment of context transfer-candidate
services at the new base station and interoperability with any layer
two radio access technology [1]. It would contribute to the seamless
operation of application streams and would reduce susceptibility to
errors. Re-initiation of services to and from the mobile node will be
avoided and hence latency will be reduced.

1.1 Terminology

Cellular-IP Gateway
A cellular-IP node which acts as an interface between a cellular-
IP network and a regular IP network.

Context
The information on the current state of a service associated with
the mobile host which is heavily dependant on the location of the
mobile host.

Context Cache
A cache maintained by all Cellular-IP leaf nodes, used to store
context information of the mobile nodes attached to them.

Georgiades, Politis Expires-December 2003 [Page 2]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

Context Transfer
The procedure for passing contexts from one base station to
another in order to avoid re-establishing specific services from
scratch.

Context Transfer Candidate Service
A service whose state can be considered in being forwarded using
the context transfer mechanism.

Context-update packet
A control packet transmitted from the cellular IP gateway to the
new base station in order to update its context cache.

New Base Station
The base station to which the mobile node will attach to, after
handoff.

Paging-cache [6]
A cache maintained by some cellular-IP nodes, which is used to
route packets to mobile hosts.

Paging-update packet [6]
A control packet transmitted by Cellular IP mobile hosts in order
to update paging cache

Previous Base Station
The base station to which the mobile node is attached prior to
handover.
Route cache
A cache maintained by all Cellular-IP nodes, used to route packets
to mobile hosts.

Route-update packet
A control packet transmitted by cellular IP mobile host in order
to update paging cache.

1.2 Abbreviations

BS Base Station

CIP-GW Cellular-IP Gateway

CT Context Transfer

CU Context-update packet

NBS New Base Station

nCIP-GW New Cellular-IP Gateway

Georgiades, Politis Expires-December 2003 [Page 3]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

PBS Previous Base Station

pCIP-GW Previous Cellular-IP Gateway

RU Route-update packet

2. Cellular-IP protocol extensions

Within a cellular-IP domain, during a handover from one BS to
another, cellular-IP control packets could be used to initiate
and transfer authorised context from the CIP-GW to the NBS. The
context information will be stored at the CIP-GW and a copy of this
context (state information) will be forwarded to the NBS.

One of the main advantages of using cellular-IP is the distinction it
makes between idle and active users. This separation allows the
network to follow a mobile node in active state from BS to BS and
deliver packets without searching for the mobile host. By separating
the caches for active and idle mobile hosts only a smaller cache
needs to be searched for most of the packets which results in faster
lookups and better scalability [6]. This CIP advantage of separating
active hosts from idle mobile hosts is also a benefit to the context
transfer mechanism since it also targets active mobile hosts.

In order to incorporate this context transfer mechanism in the
cellular-IP protocol the following enhancements are required:

* Introduction of a Context-Update (CU) packet
* Introduction of Context cache at each cellular-IP leaf node.
* Re-configure the cellular-IP Route-Update packet.
For inter-domain handoff:
* Introduction of a Context-Update request (CU-Req) packet
* Introduction of a Context-Update reply (CU-Rep) packet

In what follows, we present a description of each of these extensions.

2.1 Context-update packet

Similarly to the Route update and paging update packets defined in
[6] the context update packet will also be an ICMP packet. The basic
format of an ICMP packet is shown below:

Georgiades, Politis Expires-December 2003 [Page 4]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ICMP packet format

For the context update packet the source address will be the address
of the CIP-GW and the destination address will be the NBS address.
The type is a Cellular IP control packet and the code is context-
update. The payload of the context update packet carries
authentication information in the same format as the route and paging
update packets but carries control information in a different
format. The payload of the context-update packet carries
authentication and control information in the following format [6].

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp (64 bits long) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CU |S| AType | Auth. Length | CU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Control information (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp Contains a timestamp used to determine the order in which
update packets are sent. The timestamp field is formatted
as specified by the Network Time Protocol [7].

CU Currently Unused. Must be set to 0.

S flag Set to 1 to indicate semi-soft handoff. Default value is
0. Any Cellular IP node that does not support semi-soft
handoffs may ignore this bit.

Atype Denotes the authentication method used. The default
authentication is described in [10]. All authentication
methods must utilize the timestamp field.

Georgiades, Politis Expires-December 2003 [Page 5]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

Auth. Length
Denotes the length of the authentication information in
bytes.

Authentication Contains the authentication information.

Alternatively the Authentication Header [10] could be used for
authenticating control packets. This is for further study.

Control information is encoded in the following Type-Length-Value
format:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+-+-+-
| Context Type | Length | Context Data | Context Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+-+-+-

Context Type Indicates the type of context information.

Length Indicates the length (in bytes) of the following data
field within. The length does not include the Type and
Length bytes.

Context Data Contains the context information of a single context
type.

2.2 Context-update Request Packet (CU-Req)

Similarly to the context-update packet the CU-Req will also be an
ICMP packet. The source address will be the address of the new CIP-GW
and the destination address will be the address of the previous
CIP-GW. The type is a Cellular IP control packet and the code is
CU-Req. The payload of the CU-Req packet carries a list of the
desired context information.

2.3 Context-update Reply Packet (CU-Rep)

CU-Rep is also an ICMP packet. The source address will be the address
of the previous CIP-GW and the destination address will be the
address of the new CIP-GW. The type is a Cellular IP control packet
and the code is CU-Rep. The payload of the context update packet
carries the context information.

2.4 Context Cache

Cellular IP nodes will need to be upgraded to maintain a Context
Cache. Context Cache will maintain context information relating to
each of the mobile hosts attached to that BS. The operation of
Context Cache is summarised in the following table.

Georgiades, Politis Expires-December 2003 [Page 6]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

------------------------------------------------------------------------
Context Cache
------------------------------------------------------------------------

refreshed by context-update packets or candidate protocol(s)
packets

updated by context-update packets or candidate protocol(s)
packets

updated when mobile host handoffs to a NBS or when candidate
protocol(s) renegotiate(s)

scope active mobile hosts

purpose maintain context information relating to the mobile
hosts

location CIP-GW and leaf nodes

------------------------------------------------------------------------

2.5 Re-configuring the Route-Update packet

One of the currently unused (CU) bits could be used as a flag which
when set will indicate that the route-update packet was spawned due
to a handoff. The payload of the ICMP packet will be
changed to the following:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp (64 bits long) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CU |H|S| AType | Auth. Length | CU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Control information (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H flag Set to 1 to indicate handoff. Default value is 0.

When the route-update packet is received by the CIP-GW, if the H flag

Georgiades, Politis Expires-December 2003 [Page 7]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

is set to 1, the CIP-GW will send a context-update packet towards the
Mobile Host.

3 Routing

3.1 Intra-domain handoff (i.e. handoff within a single Cellular-IP
domain)

Route-update packet transmitted by the mobile host reaches the CIP-GW
using shortest path hop-by-hop routing. Cellular IP nodes monitor
these passing data packets and use them to create and update Route
Cache mappings. These map mobile host IP addresses to downlink
neighbours of the Cellular IP node. Packets addressed to the mobile
host are routed along the reverse path, on a hop-by-hop basis,
according to these Route mappings [6]. When the route-update packet
reaches the CIP-GW, if the H flag of the route-update packet is set
to 1, the CIP-GW will send a context-update packet towards the mobile
host. The context-update packets will be routed along the reverse
path on a hop-by-hop basis towards the mobile host. When the context-
update arrives at the NBS, the NBS stores the context data in its
context cache and it discards the packet.

3.2 Inter-domain handoff (i.e. Cellular-IP to Cellular-IP domain handoff)

This is similar to the Intra-domain handoff process (section 2.5) with
additional messages to request and forward the desired context
information from the previous CIP-GW to the new CIP-GW. When the
route-update packet reaches the new CIP-GW, if the H flag is enabled
and the GW identifies the MH as a newcomer to its domain, it requests
the context information from the previous CIP-GW by sending a CU-Req
packet. On reception of the CU-Req the previous CIP-GW forwards the
desired context information to the new CIP-GW using a CU-Rep packet.
The new CIP-GW in turn stores the context at the context cache and
creates a CU packet containing the context. The CU packet, carrying
the feature contexts, will be routed along the reverse path on a hop-
by-hop basis towards the mobile node. When the context update arrives
at the NBS the NBS stores the context data in its context cache and
discards the packet.

3.3 Basic handoff procedure

Handoff is initiated from the mobile host by sending a route-update
packet towards the cellular-IP gateway. When an active host
approaches a new BS, it transmits a route-update packet and redirects
its packets from the PBS to the NBS. The route-update packet will
configure Route Caches along the way from the NBS to the CIP-GW. In
most cases the paths leading to the PBS and NBS may overlap. In
nodes where the two paths coincide, the route-update packet simply
refreshes the old mapping and the handoff remains unnoticed.

Georgiades, Politis Expires-December 2003 [Page 8]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

. Internet Backbone with Mobile IP .
. .
..............................................
|
+---+
|GW |
+---+
|
+------------------------------+
| |
| Cellular IP |
| Network |
| ___ ___ __ |
+--|PBS|-----|NBS|------|BS|---+
--- --- --

MH ---> [MH]

Whether the context transfer procedure takes place during or after
the handoff procedure, will depend on whether the cellular-IP handoff
used, was "semi-soft" or not.

3.4 Semi-soft handoff

One of the extensions proposed in [6] aims to improve the performance
of loss sensitive applications by introducing another type of handoff
called "semi-soft" handoff. The handoff procedure described in 3.3
is known as "hard" handoff and is where the mobile host switches from
the PBS to the NBS all at once. With "semi-soft" handoff the mobile
host maintains communication with the PBS while establishing
connection with the NBS. Packets intended to the mobile host are
sent to both Base Stations, so when the mobile host eventually
handoffs it continues to receive packets without interruption [6].
The mobile host initiates the semi-soft handoff by sending a route-
update packet with the S flag set to 1 towards the CIP-GW via the NBS
while continuing to listen to the PBS.

This handoff procedure will not only result in a smoother change over
between base stations but it is also favoured by the context transfer
extension since it provides us with a context transfer trigger
(route-update packet) prior to handoff. If the context transfer
procedure completes before the mobile node attaches to the NBS, the
NBS will have a copy of the desired state information prior to
handoff and consequently this will be the ideal case.

Georgiades, Politis Expires-December 2003 [Page 9]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

4. Trigger Considerations

Knowing when to initiate context transfer is very important in order
to get the timing right and forward the context seamlessly with the
handoff. Trigger signals are thus crucial in achieving exactly this.
As mentioned in [1] the context transfer solution must define the
characteristics of these trigger mechanisms used to initiate context
transfer.

As mentioned earlier in this draft the re-configured Route-Update
message will be the trigger used at the Cellular-IP gateway to
initiate Context Transfer from the Cellular-IP gateway to the new
base station . When the route-update packet is received by the CIP-
GW, if the H flag is set to 1, the CIP-GW will initiate context
transfer. In the case of an intra-domain handoff the CIP-GW will send
a context update packet to the NBS (see section 3.1). In the case of
an inter-domain handoff the CIP-GW will request for a copy of the
context from the previous CIP-GW prior to sending a send a context-
update packet to the NBS.

5. Timing Considerations

The addition of the context transfer mechanism to the cellular-IP
protocol should not add any disruption to the loss prone services.

6. Transport Consideration

In this Internet draft, we have proposed an extra packet to the
cellular-IP protocol, the context-update packet, which will be used
as a carrier to forward a copy of the context information from the
PBS via the CIP-GW to the NBS. The context update packet proposed is
an ICMP packet.

7. Zone of Operation

Since the context transfer mechanism proposed in this draft is an
extension to the cellular-IP protocol the zone of operation will
depend entirely on the coverage of cellular-IP. Although cellular-IP
was intended to provide mobility and handoff support locally the
context transfer extensions proposed in this draft provide both intra
-domain (see section 3.1) and inter-domain (see section 3.2) handoff
support.

Georgiades, Politis Expires-December 2003 [Page 10]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

8. Security Issues

As with the rest of the cellular-IP control packets the context-
update packets will carry mandatory authentication information.

In general since the context transfer extension proposed in this
draft is an extension to the cellular-IP protocol the security
proposed for cellular-IP [6] covers the security requirements for a
context transfer mechanism [1][2]. This will avoid the need of using
security mechanism such as IPsec and TLS which will create additional
overhead on the header.

9. Message flow diagrams

9.1 Intra-domain context transfer

MN nBS CIP-GW
T | | |
I |-----RU---->| |
M | |-----RU---->|
E | |<----CU-----|
: | |---CU-Ack-->|
: | | |
V | | |

9.2 Inter-domain context transfer

MN nBS nCIP-GW pCIP-GW
T | | | |
I |-----RU---->| | |
M | |-----RU---->| |
E | | |---CU-Req-->|
: | | |<--CU-Rep---|
: | |<----CU-----| |
V | |---CU-Ack-->| |
| | | |

10. Acknowledgements
This work has been funded by the IST-2001-32449 EVOLUTE project,which is
funded by the European Community.

Georgiades, Politis Expires-December 2003 [Page 11]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

11. References

[1] J. Kempf et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC
3374, Internet Engineering Task Force, September 2002.

[2] G. Kenward et al., "General Requirements for Context Transfer",
Internet Draft, Internet Engineering Task Force, Work in
Progress.

[3] R. Koodli, C.E.Perkins, "Context Transfer Framework for
Seamless Mobility", Internet Draft, Internet Engineering Task
Force, Work in Progress.

[4] J. Loughney et al., "Context Transfer Protocol", Internet
Draft, Internet Engineering Task Force, Work in Progress.

[5] Madjid Nakhjiri, Ajoy Singh, "Time Efficient context Transfer
(TEXT)", Internet Draft, Internet Engineering Task Force, Work
in Progress.

[6] A. Campbell et al., "Cellular IP", Internet Draft, Internet
Engineering Task Force, October 1999.

[7] C. Perkins Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

[8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002

[9] "IP Authentication using Keyed MD5", P. Metzger, W. Simpson,
IETF RFC 1828, August 1995.

[10] "IP Authentication Header, "R. Atkinson, IETF RFC 1826, August
1995

Georgiades, Politis Expires-December 2003 [Page 12]

INTERNET-DRAFT Context Transfer extension to CIP March 2003

Authors' Addresses

Michael Georgiades
Centre of Communication Systems Research (CCSR)
University of Surrey, Guildford
GU2 7XH Surrey, UK
Tel: +44 1483 683605
Fax: +44 1483 686011
Email: m.georgiades@surrey.ac.uk

Nadeem Akhtar
Centre of Communication Systems Research (CCSR)
University of Surrey, Guildford
GU2 7XH Surrey, UK
Tel: +44 1483 683605
Fax: +44 1483 686011
Email: n.akhtar@surrey.ac.uk

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Georgiades, Politis Expires-December 2003 [Page 13]