IETF Seamoby Working Group CARD Design Team Internet Draft Marco Liebsch Ajoy Singh (Editors) Hemant Chaskar Daichi Funato draft-ietf-seamoby-card-protocol-00.txt Expires: April 2003 October 2002 Candidate Access Router Discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN or the MN's current AR is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, that CAR, whose capabilities are a good match to the preferences of the MN, may be chosen as the target AR (TAR) for handover. This draft describes a solution to perform CARD. CARD Design Team Expires û April 2003 [Page 1] Internet-Draft Candidate Access Router Discovery October 2002 TABLE OF CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of CARD Protocol. . . . . . . . . . . . . . . . . . . . 4 3.1 Reverse Address Translation. . . . . . . . . . . . . . . . . 4 3.2 Discovery of CAR Capability. . . . . . . . . . . . . . . . . 5 4. Protocol Design Considerations . . . . . . . . . . . . . . . . . 6 4.1 Mobile Node Types. . . . . . . . . . . . . . . . . . . . . . 6 4.1.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.3 MN Type 3 . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Availability of Security Association . . . . . . . . . . . . 6 4.2.1 Availability of SA between AR(s). . . . . . . . . . . . 7 4.2.2 Availability of SA between AR and MN. . . . . . . . . . 7 4.3 Location of TAR Selection Algorithm. . . . . . . . . . . . . 7 4.3.1 TAR Selection at the MN . . . . . . . . . . . . . . . . 7 4.3.2 TAR Selection at the Current AR . . . . . . . . . . . . 7 5. Modes of Protocol Operation. . . . . . . . . . . . . . . . . . . 8 5.1 Mobile Node orchestrated mode. . . . . . . . . . . . . . . . 8 5.1.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Network Assisted Mode. . . . . . . . . . . . . . . . . . . . 9 5.2.1 MN Type 1 . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2 MN Type 2 . . . . . . . . . . . . . . . . . . . . . . .10 6. Protocol Messages and Operation. . . . . . . . . . . . . . . . .11 6.1 CARD Messages for the interface MN - AR. . . . . . . . . . .11 6.2 CARD Messages for the interface between ARs. . . . . . . . .14 7. Security Considerations. . . . . . . . . . . . . . . . . . . . .14 8. Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .15 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 [1]. CARD Design Team Expires û April 2003 [Page 2] Internet-Draft Candidate Access Router Discovery October 2002 1. Introduction IP mobility protocols enable mobile nodes (MNs) to execute IP-level handover between access routers (ARs). CAR discovery (CARD) enables acquiring information about the ARs that are candidates (CARs) for the MN's handover. In future wireless networks, there will be cases when a MN has a choice of performing IP-level handover to different CARs. The MN would then choose one of them as a target access router (TAR) for handover, based on a match between a MN's requirements and CARs' capabilities. The MN requires some means of obtaining information about the CARs so that the best decision about the TAR can be made. The CARD protocol enables this. The problem statement and requirements for CARD are discussed in [2] and [3] respectively. In this draft, we describe a solution to perform CARD. We begin by describing two main functional blocks of the CARD protocol. Then, we identify a number of factors that affect the operation of the CARD protocol in different handover scenarios. These factors include: MN communication capabilities, security association between network elements, location of execution of TAR selection algorithm as well as performance aspects. Then, we describe two modes of protocol operation that we think cover most of the important handover scenarios. This first version of the document is intended to expose the factors required to be considered, and alternatives available for the design of CARD protocol. The intent of the design team is to get working group consensus on these issues, so as to define the scope of CARD protocol design. 2. Terminology Mobile Node (MN) A Mobile Node is an IP host capable of moving its point of attachment to the Internet. Access Point (AP) A radio transceiver by which a MN obtains Layer 2 connectivity with the wired network. Access Router (AR) An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs. CARD Design Team Expires û April 2003 [Page 3] Internet-Draft Candidate Access Router Discovery October 2002 Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. This implies that the MN has the right radio interface to connect to an AP that is served by this AR, as well as the coverage of this AR overlaps with that of the AR to which the MN is currently attached to. Capability of AR A characteristic of the service offered by an AR that may be of interest to a MN when the AR is being considered as a handover candidate. L2 ID Identifier of an AP, that uniquely identifies that AP. For example, in 802.11 PCF, this could be a MAC address of an AP. Target AR (TAR) An AR with which the procedures for the MN's IP-level handover are initiated. The TAR is selected after running a TAR Selection algorithm that takes into account the capabilities of CARs, preferences of the MN and any other local policies. 3. Overview of the CARD Protocol A CARD protocol consists of the following main functional building blocks. 3.1 Reverse Address Translation This functionality refers to mapping the L2 ID of a new AP that the MN can connect to, to the IP address of the CAR that connects to the new AP. In cases where the MN can acquire IP connectivity with CARs prior to making handover decisions, this functionality is trivially realized. However, if a MN can only listen to L2 IDs of new APs prior to making decision about IP-level handover to CARs, a special mechanism is needed for reverse address translation. This could be realized via cached information in the MN. Alternatively, the MN may seek the help of the current AR, wherein the MN sends L2 IDs of new APs to the current AR and expects it to resolve the L2 IDs to the IP address of CARs. CARD Design Team Expires û April 2003 [Page 4] Internet-Draft Candidate Access Router Discovery October 2002 Note: In some networks, such as cellular networks, link-layer technology may be capable of delivering the L2 ID of the new AP to the current AR. Finally, few comments are in order. First, note that the new AR can be in a different subnet than that of the current AR (even far away from the current AR in terms of IP hops). Second, when the MN delivers L2 IDs of APs to the reverse address translation module, implicit is the assumption that MN is satisfied with the signal strength of the new APs. Lower level criteria such as signal strength are out of scope of capabilities that we refer to in the next section. Finally, establishment of a L2 security association between a MN and individual AP(s) is assumed to be performed in accordance with the relevant L2 mechanism, and is outside the scope of the CARD protocol. 3.2 Discovery of CAR Capability Information about capabilities of CARs can assist the MN in making optimized handover decisions. This capability information serves as input to the TAR selection algorithm. Some of the capability parameters of CARs can be static, some others can change only on a long time scale, while the rest can be highly dynamic. For the capability parameter that changes over time, a lifetime can be associated. Format and definition of capabilities is out of scope of the CARD protocol design. If the MN can establish solid IP connectivity with CARs before making handover decisions, the MN can directly ask for capability information from the CARs. Alternatively, certain capabilities may be periodically transmitted over downlink broadcast channels. In either case, it is natural to execute TAR selection algorithm on the MN. On the other hand, if the MN cannot establish IP connectivity with CARs before making handover decisions, the current AR can assist the MN in retrieving capability information from the CAR. Then the TAR selection algorithm may be executed on the current AR (assuming the current AR knows the MN's preferences) or on the MN. If TAR selection is performed on the MN, capability information about CARs may need to be transmitted to the MN. CARD Design Team Expires û April 2003 [Page 5] Internet-Draft Candidate Access Router Discovery October 2002 4. Protocol Design Considerations The CARD protocol design highly depends upon the characteristics of the underlying access technologies, MN communication capabilities, as well as the roaming and security policies of the network access service providers. This section identifies a set of parameters that can vary across various access technologies (or across various deployments of the same access technology) and MN capabilities, and are also important enough to be considered by the CARD protocol to ensure its wider deployment. 4.1 Mobile Node Types The design of the CARD protocol is dependent upon the communication characteristics of the MNs. We have classified the MNs in the following three categories namely, type 1, type 2 and type 3. 4.1.1 MN Type 1 This type of MN provides IP layer connection with the current AR only. However, the MN is capable of listening to the L2 beacons from the neighboring AP(s) and thereby deducing their L2 ID(s). For example, 802.11 families of MN or cellular handsets with the mobile assisted handover capability are capable of performing the aforementioned functions. 4.1.2 MN Type 2 This type of MN can support multiple IP layer connections simultaneously: one with the current AR and at least one with the CAR. MNs with multiple network interface cards can be classified as type 2 mobiles. 4.1.3 MN Type 3 This type of MN supports single IP layer connection with the current AR. Unlike type 1, either they are not able to receive L2 beacons from the neighboring AP(s) or deduce the link layer ID(s) of the AP(s) from the received beacons. It is very difficult to design the CARD protocol to support this type of MN. We currently do not consider this type of MNs during CARD protocol design. 4.2 Availability of Security Association The design of the CARD protocol is also dependent upon the availability of the SAs among various access network elements and the MN. This section describes such security options. CARD Design Team Expires û April 2003 [Page 6] Internet-Draft Candidate Access Router Discovery October 2002 4.2.1 Availability of SA between AR(s) Depending upon the deployment scenarios of access networks, SA may or may not be available between current AR and the CAR(s). It is reasonable to assume availability of SA between ARs belonging to the same domain, but the same assumption may not be valid for ARs belonging to different domains. 4.2.2 Availability of SA between AR and MN It is implicit that the MN will have a SA with the current AR. However, it may or may not have the required SA(s) or ability to establish SA(s) with the CAR(s). This has implications on whether the MN can directly obtain capability information from CAR(s) in a secure manner. 4.3 Location of TAR Selection Algorithm The design of the CARD protocol should also take into consideration the various options for the location of the TAR selection algorithm, so that capability information gathered by the CARD protocol can be provided to the TAR selection algorithm. The TAR selection algorithm can either be located at the MN or the current AR. For instance, the TAR selection algorithm can be located at the MN when a type 2 or type 1 MN, by utilizing the available SAs between the MN and CARs, can obtain the capability information from the CARs. Alternatively, the TAR selection can be performed at the current AR when the current AR, upon receiving a request from the MN, can obtain the capability information from the CARs. 4.3.1 TAR Selection at the MN In this case, the MN receives capability information from CARs and selects one from the list with the best matching capabilities as the TAR. Depending upon the MN type, the MN can receive capability information directly from CARs either over the Internet and the current access link or over the new access link. This mode of operation may cause large capability traffic on access links and drain on MN battery power. 4.3.2 TAR selection at the Current AR In this case, the current AR gathers capability information about CARs and matches it with the MN's preferences to determine the TAR. Unlike the previous case, over the air capability traffic associated with this type of TAR selection strategy may not be large. CARD Design Team Expires û April 2003 [Page 7] Internet-Draft Candidate Access Router Discovery October 2002 5. Modes of Protocol Operation This section describes two different operational modes for the CARD protocol, namely the "MN Orchestrated Mode" and the "Network Assisted" Mode. The purpose of specifying two operational modes is to cover different handover scenarios dictated by factors described in section 4. During a given handover event, the operational mode used for CARD is necessarily governed by the physical restrictions imposed by access networks and MN communication capabilities. When choice is possible, factors such as efficiency and local policy should also be considered in deciding about the right CARD mode to be used in a given handover event. 5.1 Mobile Node Orchestrated mode This mode assumes that all the control for executing CARD functionality, such as reverse address translation and capability discovery, resides in the MN. CARs merely provide MNs with the capability information over IP connectivity on demand. This mode requires that the MN is able to establish IP connectivity with CARs while keeping the link to its current AR. In this mode it is most natural to perform TAR selection in the MN, as the capability information required for the TAR selection algorithm is readily available in the MN. The advantage of this mode is that it allows CARD to be performed without protocol interactions between a MN's current AR and CARs, since the MN directly interacts with CARs for the purpose of CARD. This mode requires availability of SAs between the MN and its CARs. SAs between the MN and CARs can either be pre-established or established on demand. This operational mode entails the transmission of capability information over the access link, which may be suboptimal with regard to meeting the requirement on efficient usage of access link resources as well as minimizing the drainage of a MN's battery energy. The following subsections evaluate the MN orchestrated mode for the different types of MNs, as addressed in section 4.1. CARD Design Team Expires û April 2003 [Page 8] Internet-Draft Candidate Access Router Discovery October 2002 5.1.1 MN Type 1 For the type 1 MNs to be able to use this CARD mode, it is necessary to perform reverse address translation on the MN without any support from its current AR. After having the IP addresses of CARs resolved, capability discovery can be performed between the MN and the CARs over the current access link. Details on how to perform reverse address translation with type 1 mobile nodes are out of the scope of this document. 5.1.2 MN Type 2 The type 2 MNs can perform CARD using this operational mode. This is because type 2 MNs can engage in simultaneous communication with the current AR as well as CARs on IP level. After connections and SAs have been established to CARs, CARD can be performed from the MN to individual CARs in parallel with the existing connection to the current AR. Access link bandwidth consumption may not be a problem for low cost and low traffic access links such as personal bluetooth link or private WLAN hot spots. For other types of access links such as cellular or public WLAN, this may be undesirable. 5.2 Network Assisted Mode This operational mode requires support from the current AR for CARD. Some CARD functional entities can be associated with ARs to support reverse address translation and discovery of CAR capabilities when being the current AR of the MN. This mode also requires protocol interactions and hence availability of trust relationship between the current AR and CARs. For the discovery of CARs within the same administrative domain as that of the current AR, security associations between AR and CARs could be taken for granted. In case of the current AR and CARs being located in different domains, roaming agreement may be a way to allow for security associations between the current AR and CARs. In any case, the security association between the MN and its current AR can be taken for granted. The TAR selection algorithm can be implemented either in the (current) ARs or in the MN. 5.2.1 MN Type 1 The type 1 MN is capable of scanning other APs and obtaining their L2 IDs. This information is provided to the MN's current AR. The current AR performs reverse address translation and obtains the capability information from the corresponding CARs. This information is conveyed back to the MN in case of implementing the TAR selection CARD Design Team Expires û April 2003 [Page 9] Internet-Draft Candidate Access Router Discovery October 2002 in the MN. In case of implementing the TAR selection function on the current AR, the MN gets information on the TAR from its current AR. Optionally, the TAR's capability information can be conveyed to the MN after TAR selection has been performed by the current AR. 5.2.2 MN Type 2 The type 2 MNs can perform Network Assisted CARD in exactly the same manner as type 1 MNs. Then, the feature of type 2 MNs of being able to establish IP connectivity with CAR(s) is not utilized. Capability pre-filtering: In case of implementing TAR selection in the MN, CAR capabilities are required to be conveyed to the MN as input to the TAR selection algorithm. The following approaches can be used for this purpose: (A) Providing full capability set for TAR selection The MN receives the full set of capability information from the sender of capabilities. In the MN orchestrated mode, this sender is the CAR, while in the network assisted mode it is the current AR. Since no MN preferences for capabilities are to be transmitted to the current AR, but the full set of capability information is to be conveyed to the MN, this approach is "uplink optimized". (B) Providing partial capability set for TAR selection The MN sends its preferences for capabilities to the current AR. In response, the AR sends a pre-filtered subset of the CARs' capabilities to the MN to be used as input for the TAR selection function. Since this approach considers a reduced set of capabilities to be sent to the MN but assumes a set of preferences to be sent previously to the current AR, this approach is "downlink optimized". As an enhancement to approach (B), context transfer (CT) framework [4,5] can help to avoid sending the MN's preferences for pre- filtering the capability information to the current AR for each handover event. After the MN's preferences for pre-filtering have been provided to the current AR once, this information can be transferred to the selected TAR by means of CT mechanisms. CARD Design Team Expires û April 2003 [Page 10] Internet-Draft Candidate Access Router Discovery October 2002 6. Protocol Messages and Operation The process of selecting the TAR for the MN's IP-layer handover can be performed in two steps: Identifying the CARs along with their capabilities and then selecting the appropriate AR from the CAR list as TAR. The AR or MN invokes the CARD process when it receives an indication about the discovery of a new AP ID by the MN during L2 scan process. The CARD process can take place before the L3 handover event, whereas the TAR selection process is invoked when the current AR or MN receives indication of imminent L3 handover via some L2 triggers. For the sake of efficiency, it should be possible to piggyback CARD messages over IP-layer handoff signaling, whenever possible. At the same time, to cater to timing issues, when piggybacking is not feasible, it should be possible to send CARD messages independent of IP-layer handoff signaling and to allow for stand-alone deployment of CARD. A way to achieve this is to encode CARD messages as generic TLV-encoded ICMP options. These options can be piggybacked over other ICMP messages of IP-layer handoff signaling or can be send in separate ICMP messages. It is necessary to identify two main interfaces across which CARD messages would be sent. These are: interface between MN and AR and interface between AR and AR. Note here that the interface between the MN and AR can either be between a MN and the MN's current AR or between a MN and a CAR. 6.1 CARD Messages for the interface MN - AR The MN periodically listens to the beacons from neighboring AP(s) and sends a CARD request message containing the L2 ID(s) of the newly discovered AP(s) to the current AR, when using network assisted CARD. When using the MN orchestrated mode, there is no need to carry L2 IDs of AP(s), but preferences for capabilities need to be conveyed to CAR(s) by means of an appropriate parameter option in case of pre-filtering of capabilities at CAR(s) is deployed. While performing TAR selection on the current AR in network assisted mode, the MN needs to send its requirement to the current AR. CARD Design Team Expires û April 2003 [Page 11] Internet-Draft Candidate Access Router Discovery October 2002 Message Format: One ICMP main header is defined to allow for stand-alone CARD operation as described above. Then two TLV-encoded ICMP options, namely CARD REQUEST and CARD REPLY, are defined. These two options carry the parameters for CARD as sub-options. ICMP main header ---------------- - ICMP basic format, contains Type-Length-Checksum. This carrier is needed for CARD protocol stand-alone deployment. The main header does not appear for CARD protocol piggybacking. Encoding: ICMP standard header 32 bit (Type-Length-Checksum) Valid options: CARD ICMP options and appropriate sub-options as described below. Valid ICMP options for CARD --------------------------- CARD signaling is based on the following 2 ICMP options: - CARD REQUEST option, sent from a MN to the current AR or to CARs. Encoding: ICMP option, contains -> o Sequence Number o Flags Sequence Number: To allow correlation of replies with requests. Flags: To indicate the operational mode and the interface where the protocol message is deployed. Various sub-options can be attached to the CARD REQUEST option, as described below. - CARD REPLY option, sent from the AR(s) to the MN. Encoding: ICMP option, contains -> o Sequence Number o Flags Meaning of Sequence Number and Flags is the same as above. CARD Design Team Expires û April 2003 [Page 12] Internet-Draft Candidate Access Router Discovery October 2002 Various sub-options can be attached to the CARD REPLY option, as described below. Valid sub-options for CARD -------------------------- The CARD protocol specifies 5 sub-options for CARD: - L2 ID: Conveys the AP identifier from MN to current AR - PREFERENCES: Conveys MN preferences for pre-filtering of capabilities from the MN to the current AR or CAR - REQUIREMENTS: Conveys MN requirements for TAR selection from the MN to the current AR - CAPABILITY: Container to carry CAR capabilities from the current AR or CAR to the MN - TAR ADDRESS: Carries the selected TAR's address Encoding: All sub-options are TLV-encoded and can be attached to the message options according to the protocol operation. Details on the use of sub-options with CARD options: The following table indicates the use of individual sub-options with CARD options, dependent on the operational mode and the location of the TAR selection function. For network assisted CARD operation, the table additionally indicates a sub-option's presence by "" in case of having the TAR selection implemented in the MN. When TAR selection is performed on the current AR, a parameter's presence is indicated by "". CARD Design Team Expires û April 2003 [Page 13] Internet-Draft Candidate Access Router Discovery October 2002 | Network Assisted | MN Orchestrated | +-----------------------+----------------------+ | CARD REQ | CARD REPL | CARD REQ | CARD REPL | -------------+-----------+-----------+----------+-----------+ L2 ID | x | | | | PREFERENCES | x | | x | | REQUIREMENTS | x | | | | CAPABILITY | | x | | x | TAR ADDRESS | | x | | | 6.2 CARD Messages for the interface between ARs (AR - AR) In general, for the interface between ARs, same messages and parameters can be deployed. Distinction of the interfaces, where the protocol message is deployed, is considered to be done in the flags field of the ICMP option. To take additional requirements for ensured reliability of control message transport into consideration, appropriate transport mechanisms are to be evaluated. This is TBD and to be discussed with the WG. 7. Security Considerations Related issues on the availability of security associations are discussed in section 4.2. For additional security concerns, the reader is referred to [3]. 8. References [1]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2]Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. ôIssues in candidate access router discovery for seamless IP-level handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in progress, October 2002. CARD Design Team Expires û April 2003 [Page 14] Internet-Draft Candidate Access Router Discovery October 2002 [3]Krishanmurti, G., ôRequirements for CAR Discovery Protocolsö, draft-ietf-seamoby-card-requirements-02.txt, a work in progress, October 2002. [4]Kempf, J.,"Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. [5]Kenward, B.,"General Requirements for Context Transfer", draft- ietf-seamoby-ct-reqs-05.txt, a work in progress, October 2002. Authors' Addresses Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: 781 993 3785 Email: Hemant.Chaskar@nokia.com Daichi Funato NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110, USA Phone: +1 408-451-4736 EMail: funato@docomolabs-usa.com Marco Liebsch NEC Network Laboratories Adenauerplatz 6, 69115 Heidelberg Germany Phone: +49/(0)6221 1370811 Email: marco.liebsch@ccrle.nec.de Ajoy Singh Motorola Inc 1501 West Shure Dr Phone: 847 632 6941 Email: asingh1@email.mot.com CARD Design Team Expires û April 2003 [Page 15] Internet-Draft Candidate Access Router Discovery October 2002 CARD Design Team Expires û April 2003 [Page 16]