INTERNET DRAFT Satish Jamadagni March 2002 Satish D Shiva Raman Pandey Sasken Communication Technologies Ltd A combined Context Transfer and Candidate Access Router Discovery protocol draft-satish-car-ct-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 [1]. 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 to the Seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to seamoby@diameter.org mailing list. Distribution of this memo is unlimited. Abstract Protocols being designed for seamless IP-level handovers, such as fast handover, context transfer (CT) and Candidate Access Router (CAR) discovery protocols will have to go hand in hand for any meaningful seamless handover implementation. The CAR discovery and subsequent Target Access Router (TAR) discovery is achieved through L3 QoS parameters, user preferences and application level QoS parameter match between the geographically adjacent access routers (GAAR). It is asserted in this draft that the primary consideration for fast handover and CAR discovery will still be layer 3 QoS parameters as supported by the ARs. The TAR selection demands that the capability set of the CARs is available and should necessarily meet the MN's requirements. While the TAR selection process can happen at the time of handover, the GAARs which have the capabilities to meet the MN's requirements can be identified in advance. Whether the CAR and subsequently the TAR identification is done in advance of at the time of handover there will have to be a constant exchange of capabilities between the current AR Satish et Al [Page 1] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 and the GAARs. This motivates us to propose a CAR discovery protocol using CT messages thus resulting in signaling advantages. Our protocol qualifies to be what is called the CAR discovery protocol. Table of Contents 1. Introduction 2 1.1. Conventions Used In This Document 4 1.2. Terminology 4 2. The CAR Discovery Protocol 5 2.1. Capability exchange between GAARs - From GAARs to CARs 6 2.1.1. Capability list in the PPCT 6 2.2. Target Access Router (TAR) Selection 7 3. Modified Messages used by the CAR Discovery Protocol 8 3.1. Modified PCT for GAAR identification 8 3.2. CT Messages to aid in TAR identification 10 4. Mobile Node (MN) Operation 10 5. Access Router (AR) Operation 10 6. Security Considerations 11 7. References 11 8. Author's Addresses 12 1. INTRODUCTION There are existing solutions [1, 2] that enable mobile nodes (MNs) to execute IP-level handovers between the points of attachment (called access routers or ARs) to IP network. Additionally, work is underway [3, 4, 5, 6, 7], to define protocols that would allow seamless, i.e., low latency and low packet loss, handovers of MNs between ARs. These seamless handover solutions assume that the identity of the target AR TAR) for the MN's handover is known to the current AR. It is required to develop a protocol that would allow an AR to identify the TAR for MN's handover. We identify two important components in the problem of TAR selection. They are as follows: 1) Identifying the neighboring or geographically adjacent ARs sufficiently in advance of the handover, which have the capability set required to meet the MN's requirements. This process leads to a set of CARs, which not only are geographically adjacent but also meet any initial context based filtering criteria that can be used. Such initial filtering to identify CARs based on a critical, common feature set as required by all or a subset of the MNs attached to an AR is briefly discussed in a later section. 2) Choosing the TAR either at the time of handover from the set of CARs, or much earlier if possible with the help of additional Satish et Al [Page 2] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 information such as any additional context information, local policy, MN's preferences etc. Three approaches, namely, anticipated, dynamic and hybrid, have been outlined in [8] for CAR discovery. In the "anticipated" approach, the current AR identifies the CARs for handover prior to the handover process. At the time of handover, the TAR is identified by the current AR from the set of CARs. If CAR selection is "dynamic", the MN is actively involved in the CAR discovery process. The MN identifies the neighboring ARs as well as their capabilities and selects the TAR. This information is then forwarded to the current AR. A "hybrid" approach lies in between these two. In this draft, we argue that any AR that embarks on the CAR discovery process to aid in seamless handover can achieve identification of geographically adjacent access routers at a high level and as a further step can identify those ARs that cover in some sense an aggregate of the QoS supported by the discovery initiating AR. We also argue that the process of specifically identifying the target access router should involve the MN or the MN specific QoS and policy considerations. We specify a protocol where the discovery initiating AR initially identifies the GAARs and then uses CT messages as described in [10] with the "aggregate QoS" to identify a broad set of CARs. Then the actual identification of the TAR from the CARs can involve the use of CT messages by the specific MN or the initiating AR. The identification of the TAR given a set of CARs can be initiated by the MN or can be proactively achieved by the AR on behalf of the MN. Here the initiating AR can use triggers as specified in the fast handover draft [3] to initiate a MN specific TAR identification based on the MNs context state in that AR. In our protocol we assume that the MN may not be in a position to listen to a neighboring beacon i.e. the MN may not have or might not prefer to have (due to power, interference considerations) two L2 connections UP simultaneously. The protocol should cater to this situation well. In case a MN has the capability to listen to advertisements over two L2s simultaneously A MN can listen to beacons from neighboring access points and forward the information in the beacon to the AR it is currently attached to. The TAR selection protocol can then take this as an initiation to identify the TAR. Our protocol can cater to both the cases though we believe that the former should be given more consideration because of power and other interference constraints that might arise with two L2s being UP simultaneously. TAR selection will have to consider other parameters like user preferences and policies along with CARs to uniquely identify the TAR. The algorithms (like distance measures between the QoS descriptors etc) used in TAR selection, however is out of scope for this document. Satish et Al [Page 3] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1.2. Terminology Access Point (AP) : A layer 2 device to which the MN connects to through a wireless link. An AP may connect to one or more ARs. An AR may be connected to connected to APs belonging to different technologies. Access Router (AR) : An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MN. When dealing with IPv4 based networks running Mobile IPv4, Foreign Agents (FAs) take the place of ARs. Geographically Adjacent AR (GAAR) : An AR whose coverage area is such that an MN may move from the coverage area of the AR currently serving the MN into the coverage area of this AR. Physical Neighborhood List (PNL) : The set of GAARs along with their capabilities maintained at an AR. Candidate AR (CAR) : This is an AR that is a candidate for MN's handover. Candidate AR is "physically adjacent" to the AR currently serving the MN, and has the capability set required to serve the MN. Target AR (TAR) : This is an AR with which the procedures for MN's handover are initiated. Border Router (BR) : Globally IP addressable router through which a privately addressable network connects to the Internet. IP-level Identity of an AR : This is the IP address of an AR if the address is globally routable. However, if an AR resides in a private IP address space, this is a tuple (border router's globally routable IP address, AR identifier recognized by the BR). Satish et Al [Page 4] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 2. THE CAR DISCOVERY PROTOCOL A basic requirement for a new AR to be considered as a CAR for a MN is that the coverage area of the new AR be "geographically adjacent" to that of the AR currently serving the MN. Note that, the geographical adjacency of two ARs is not necessarily implied by their "logical" adjacency [9]. Manually configuring this physical neighborhood at each AR as described in [8] has disadvantages and in many cases, may not be feasible. We describe a dynamic mechanism to identify GAARs for each AR. It is described with reference to Figure 1. MN +-----------+ +-+ | Current | < | | ---------- | AR | ------ > ----\ +-+ | | < \ +-----------+ \ | +--------+ Handover | Capability ^ IP | Corr. | | Exchange | Network |Node(CN)| V (PPCT message) | +--------+ v / MN +-----------+ / +-+ --------> | New | < / | | ---------- | AR | ------ > ----/ +-+ | | < +-----------+ Figure 1: Reference Scenario for Handovers In Figure 1, the current AR broadcasts the "physical coverage area" to all its logically adjacent ARs and the new AR adds this identity to its Physical Neighborhood List (PNL) if this entry does not already exist and associates a lifetime to it. The lifetime field is refreshed if the entry already exists. This "Router Identity" message can be sent to the new AR as an ICMP option. The "Partial Proactive CT (PPCT)" is derived from the PCT message defined in [10] and this can be broadcast by an edge device or a border gateway or by the AR itself to the new AR. The PPCT broadcast SHOULD essentially be an edge device function. If the MN can detect the identity of the new AR by listening to its beacon while still connected to the old AR, then the MN MUST forward this identity to the old AR. It again uses the Router Identity message for this purpose. Satish et Al [Page 5] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 If the MN receives the L2 identity of the AP in the AP's beacon it forwards this information to the current AR also through the Router Identity message. A Physical Neighborhood List (PNL) [9] is maintained at an AR and there is one entry in the PNL for each GAAR of an AR that has been identified so far. The capability set maintained is not elaborate in the sense that a minimum but essential set is identified. The objective is just to be able to identify CARs from the GAARs. 2.1. Capability exchange between GAARs - From GAARs to CARs In future IP networks, the GAARs will be heterogeneous in administrative control, function, capability, link layer technology and resources available for packet sessions. Further the MN will have specific requirements as regards these parameters. The knowledge of GAARs' capabilities allows the current AR to choose CARs from GAARs. Hence, the current AR needs to identify the capability set of each of its GAARs to arrive at the CAR set. The PPCT message is sent to a new GAAR over the wired Internet enlisting the AR's capabilities. On receiving this message, the recipient GAAR responds with another PPCT message detailing its own capabilities. The capability information obtained via this message is used to populate the "Capability Set" field in the PNL. GAARs MAY also exchange the status of capabilities periodically or on-demand. 2.1.1. Capability list in the PPCT Capabilities can broadly be divided into dynamic and static. Static capabilities do not change over time, while dynamic capabilities do. Some of the capabilities are specific to a particular MN, and MAY be exchanged on demand. There may be other capabilities which are more generic and which may specify information relevant to all MNs. The capability exchange is achieved through the use of CT [10] messages. The CAR discovery protocol SHOULD make a distinction between that set of capabilities that can be used by the AR in choosing CARs from GAARs independent of the MN considerations and those that are used in the actual TAR identification. Some of the context parameter considerations that the RIM should support in order to help in CAR identification by any AR are listed below. - Administrative parameters: ISP name, organizational ownership, device authentication and authorization data, policy information; - Cost of access: Dollar cost per QoS class; Satish et Al [Page 6] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Available radio interfaces that are geographically adjacent to given AR: 802.11, WCDMA, GSM; - Availability of application logic: Multicast support, playout buffer hosting for streaming applications, TCP performance enhancing proxies (PEPs), media transcoding functionality, header compression functionality; - Internet connectivity parameters: NAT traversal for connectivity; - Resource parameters: Existing load, available bandwidth are some of the resource parameters that can be used. - Identities of APs (layer 2 identities) that are served by the AR. Once GAARs are identified through the PPCT messages, the current AR identifies the CARs for a particular MN as GAARs whose capabilities meets either a broad set of MNs grouped together based on the applications or services that they are running or the MN's capability requirements. 2.2. Target Access Router (TAR) Selection Assuming that the current AR has done a good job of identifying a minimal set of CARs from which the MN has to choose a TAR, the actual TAR selection can be based on explicit MN triggers (MN initiated) or the AR initiated. The TAR selection algorithm can reside in the MN or at the AR. The following figures (2 and 3) depicts the scenarios mentioned above. +----------+ +----------+ | | 3. SHREQ | | | |-----------------| | 2. Trigger | Prtr | 4. SHREP | Nrtr | ------> | | | | | | <-------------> | | | | 1. PPCT (CARs) | | +----------+ +----------+ | ^ ^ | | | | | 5. Proxy router | | | ~~ solicitation v | | V V +-+ +-+ | | 6. movement | | +-+ ---------------> +-+ Figure 2: CAR discovery protocol (AR initiated handover) Satish et Al [Page 7] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 In anticipated CAR discovery the AR can help find the exact TAR for the mobile node and then notify the MN about the new AR for handover. This can be the case under certain load conditions when the AR wants to force some MNs to new ARs. +----------+ +----------+ | | 3. SHREQ | | | Prtr |-----------------| Nrtr | | | 4. SHREP | | | | | | | | <-----------> | | +----------+ 1. PPCT (CARs) +----------+ ^ ^ | | | | 2. Trigger | | ~~ | | V V +-+ +-+ | | 5. movement | | +-+ ---------------> +-+ Figure 3: CAR discovery Protocol (MN initiated handover) In the case of the dynamic CAR discovery the MN initiates the TAR discovery. The process of identifying the TAR for the MN's handover forms the final step of the TAR selection process. This step is performed at the time of handover. The TAR selection algorithm selects a unique TAR from the set of CARs. For this it also uses the AR reachability information for the MN at the time of handover. In addition, other aspects such as local policy and MN's preferences are also applied during the decision- making. The details of TAR selection algorithm are not within the scope of CAR discovery protocol. The TAR selection is aided through the CT messages like SHREQ and SHREP [10] where the exact list of context parameters are exchanged on a per MN basis and the TAR selection algorithm run over these parameters. The MNs can be an active or a passive participant in the TAR selection process. 3. MODIFIED MESSAGES USED BY THE CAR DISCOVERY PROTOCOL 3.1. Modified PCT for GAAR identification We are using a modified PCT message [10] as mentioned below to achieve the GAAR list and further the CAR list from a given set of GAARs. We call this message the PPCT (Partial proactive context transfer). Satish et Al [Page 8] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 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=PPCT | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Multicast or broadcast IP Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit AR IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographic coverage information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Data... (Initial capability set) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthTken| Sub-Option Len| Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Partial Proactive Context Transfer Option Format Option Type Partial Proactive Context Transfer (PPCT) Option Length Variable Geographic coverage information Covers the Geographic coverage area information (either coordinates or through symbolic means) Context Transfer Options Data Individual feature contexts in the form of sub options. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message [10]. Algorithm 8-bit algorithm indication for computing the Authentication Token [10]. Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. Key Encrypted key. The Key is encrypted using a pre-existing shared key between the Access Routers. Satish et Al [Page 9] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 The identification of the GAARs and CARs should be done independently of the MN as this reduces delays for a MN during handover, to inform the AR about the identities of GAARs. The motivation is that the AR SHOULD provide the MAXIMUM support for any seamless handover. This is motivated by the fact that the MN can be constrained by power and over the air signaling issues. The SEAMOBY WG SHOULD lay more emphasis on evolving protocols that reduce the over-the-air signaling. The increase in the wire-line signaling is acceptable. 3.2. CT Messages to aid in TAR identification In our protocol (refer figure 2 and 3) we suggest the use of the SHREQ and SHREP [10] messages for the complete context exchange on a per mobile basis. This helps the MN or the AR in identifying the TAR. The TAR selection algorithm can be resident in the AR or the MN. During the TAR identification process a partial context transfer would have occurred. This can be used to reduce the signaling during the CT operation. 4. MOBILE NODE (MN) OPERATION The following item summarizes the operations at the MN: - Maintains information about current AR's IP Identity. - Listen to L2 triggers or any other triggers for the MN initiated TAR identification. - Sends the SHIN [10] message to the AR to initiate the TAR identification process. If the new AR field in the SHIN message is left blank, the AR initiates TAR selection process. - When a MN moves to a new AR it forwards the previous AR's IP Identity to the new AR. 5. ACCESS ROUTER (AR) OPERATION The following items summarize the operations at the AR: - The AR maintains a PNL. - Upon receiving a PPCT message containing the identity of a GAAR, the AR checks to see whether the entry for this GAAR exists in the PNL. If it does, the AR refreshes the lifetime of the entry. Satish et Al [Page 10] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Identifies CARs based on the MN's requirements and capability parameters of GAARs recorded in the PNL. The current AR may solicit any MN-specific requirements from the GAARs. - The AR solicits the complete context information of the CARs through the SHREQ and SHREP messages on a per MN basis on receipt of a trigger either at AR or at the MN. 6. SECURITY CONSIDERATIONS In our protocol the use of CT messages during the CAR discovery provides for some level of security as some security features are in built in the CT messages [10]. Further it is required to discuss the security considerations involved in performing GAAR discovery. The security association between GAARs for the exchange of capability information can be established using standard methods for device authentication, key exchange and encryption. 7. REFERENCES [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [2] Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000. [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handovers-v4-00.txt, work in progress, February 2001. [4] Fast handovers for Mobile IPv6, MIPv6 handover Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001. [5] Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network, O. H. Levkowetz et. al., draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in progress, May 2001. [6] General requirements for a context transfer framework, H. Sayed et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May 2001. [7] Buffer Management for Smooth handovers in Mobile IPv6, G. Krishnamurthi, R. Chalmers, C. Perkins, draft-krishnamurthi-mobileip-buffer6-01.txt, work in progress, March 2001. Satish et Al [Page 11] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 [8] Issues in Candidate Access Router Discovery, D. Trossen, G Krishnamurthi, H. Chaskar, J. Kempf, draft-ietf-seamoby-CARdiscovery-02.txt, work in progress, November 2001. [9] Protocol for Candidate Access Router Discovery for Seamless IP- level Handovers, Dirk Trossen, Govind Krishnamurthi, Hemant Chaskar, Eunsoo Shim, Richard D. Gitlin, draft-trossen-seamoby-cardiscovery-00.txt, work in progress, November 2001. [10] R Koodli, C.E. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-02.txt, November 2001. 8. AUTHOR'S ADDRESSES Satish Jamadagni, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Satish D, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3164 Fax: +91 80 5351133 Email: satishd@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3296 Fax: +91 80 5351133 Email: shiva@sasken.com Satish et Al [Page 12]