SEAMOBY Working Group M. Georgiades Internet Draft C. Politis 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 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Georgiades, Politis Expires-December 2003 [Page 13]