SEAMOBY Working Group M. Georgiades Internet Draft C. Politis R. Tafazolli University of Surrey, UK D.Gatzounas Intracom S.A., Greece March 2003 Expires: August 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. Within a cellular-IP domain, during the handoff 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 to the new cellular-IP base station. This draft presents how the context transfer extension 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-August 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-August 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 Georgiades, Politis Expires-August 2003 [Page 3] INTERNET-DRAFT Context Transfer extension to CIP March 2003 PBS Previous Base Station RU Route-update packet 2. Cellular-IP protocol extension 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 packet * Introduction of Context cache at each cellular-IP leaf node. * Re-configure the cellular-IP Route-Update 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: 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 Georgiades, Politis Expires-August 2003 [Page 4] INTERNET-DRAFT Context Transfer extension to CIP March 2003 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 updating 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. 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. Georgiades, Politis Expires-August 2003 [Page 5] INTERNET-DRAFT Context Transfer extension to CIP March 2003 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 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. ------------------------------------------------------------------------ Context Cache ------------------------------------------------------------------------ refreshed by context-update packets updated by context-update packets updated when mobile host moves to a NBS scope active mobile hosts purpose maintain context information relating to the mobile hosts location CIP-GW and leaf nodes ------------------------------------------------------------------------ Georgiades, Politis Expires-August 2003 [Page 6] INTERNET-DRAFT Context Transfer extension to CIP March 2003 2.3 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 is set to 1, the CIP-GW will send a context-update packet towards the Mobile Host. 2.4 Routing Route-update packet transmitted by the mobile host reach 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, by 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. Georgiades, Politis Expires-August 2003 [Page 7] INTERNET-DRAFT Context Transfer extension to CIP March 2003 2.5 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. .............................................. . . . 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. 2.5 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 2.4 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. Georgiades, Politis Expires-August 2003 [Page 8] INTERNET-DRAFT Context Transfer extension to CIP March 2003 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. 3. 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 handff. 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 send a context-update packet to the NBS. 4. Timing Considerations The addition of the context transfer mechanism to the cellular-IP protocol should not add any disruption to the loss prone services. 5. 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. 6. 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. Georgiades, Politis Expires-August 2003 [Page 9] INTERNET-DRAFT Context Transfer extension to CIP March 2003 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. Cellular-IP was intended to provide mobility and handoff support locally and thus the context transfer extension provides only intra-domain support. 8. Acknowledgements The authors would like to acknowledge the contributions and comments of their colleagues Mr Kar Ann Chew and Mr Nadeem Akhtar. This work has been funded by the IST-2001-32449 EVOLUTE project, which is funded by the European Community. 9. 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-August 2003 [Page 10] 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 Christos Politis Centre of Communication Systems Research (CCSR) University of Surrey, Guildford GU2 7XH Surrey, UK Tel: +44 1483 689491 Fax: +44 1483 686011 Email: c.politis@surrey.ac.uk Rahim Tafazolli University of Surrey Centre of Communications Systems Research Surrey, GU2 7XH, UK Tel: +44 1483 689834 Fax: +44 1483 686011 Email: r.tafazolli@surrey.ac.uk Dionisios Gatzounas INTRACOM S.A. Development Programmes Department Panepistimiou 254 26443 Patras GREECE Tel: +30 61 465168 Fax: +30 61 465070 Email: dgat@intracom.gr Georgiades, Politis Expires-August 2003 [Page 11]