DNA BOF Eunsoo Shim Kyungtae Kim Jens-Peter Redlich Richard D. Gitlin Internet Draft NEC Labs America, Inc. Document: draft-shim-dna-proactive-00.txt January 2004 Category: Informational Proactive Approach for DNA 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. Abstract We propose a Proactive Approach for Detecting Network Attachment (DNA). In the approach, the mobile node caches information about adjacent access points and access routers using the Candidate Access Router Protocol and uses the cached information to check the new subnet after the mobile node establishes a new air link. This enables the mobile node to determine immediately after the new link setup whether the mobile node needs to proceed further for new IP configuration for the link. 1. Introduction The ôCandidate Access Router Discovery (CARD) Protocolö allows the mobile node to get information about candidate access routers while the mobile node is attached to the current access router. Shim, et al. Expires July 2004 1 Internet Draft Proactive Approach for DNA January 2004 We notice that the CARD protocol can be a useful tool for Detecting Network Attachment (DNA). We introduce the CARD protocol briefly and present how it can be used for DNA. Also we propose what should be done to incorporate the CARD protocol for DNA. 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 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. Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. Capability of an 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. 2. Overview of the CARD Protocol It is assumed that each AR has a CAR Table which contains information about the Candidate AR(CAR)s. The most important information in the CAR Table is the IP addresses of the CARs and the L2 IDs of the APs Shim, et al. Expires July 2004 2 Internet Draft Proactive Approach for DNA January 2004 associated with each CAR. Also the CAR Table can contain capability of each CAR. How the CAR Table at the AR is built is out of scope of the current CARD Protocol specification but there are two proposed mechanisms in the appendices of the specification [3]. Defining capability of an AR is out of scope of the current CARD Protocol specification. Therefore, it is open what can be included as a capability attribute in the CAR Table. Also defining the presentation format of each capability attribute is out of scope of the CARD Protocol specification except that information of each capability attribute is presented as a type-length-time-value structure in the CARD Protocol messages. The MN can get information about CARs from the current AR in two ways: Solicited Reply and Unsolicited Reply. That is, the current AR can provide information about CARs not only as a reply to the request from the MN but also as a multicasted (or broadcasted) Unsolicted Reply. The two ARs which are a CAR to each other can exchange also request- reply messages to get information about each other or one AR can send Unsolicited Reply to the other AR to update information about itself. The CARD Request and Reply messages can replace Router Solicitation Proxy and Proxy Router Advertisement proposed for fast handoff in [4] 3. Problem of Detecting Network Attachment (DNA) A MN needs two phases of processes to be able to support IP communication: link establishment between the MN and an AP and IP- level connectivity establishment. The link establishment requires discovery of the AP and link-specific procedures. It may include configuration of the link or physical layer parameters and authentication and authorization. The IP connectivity establishment requires discovery of the access router and configuration of IP layer parameters such as the IP address for the MN and the netmask proper for the network. Also it may include authentication and authorization separate from the authentication and authorization for the link establishment. Following Mobile IP, this consists of acquiring Router Advertisement, acquiring care-of-address if necessary and registration with the home agent, at least. There are already protocols for the above aspects. The problem to optimize the above processes in the IP level includes optimizing the following aspects but not exclusively: a. Detecting when a link is established b. Determining whether the process for establishing new IP connectivity is necessary or not Shim, et al. Expires July 2004 3 Internet Draft Proactive Approach for DNA January 2004 c. Acquiring information for new IP connectivity establishment, if necessary 3.1 Detecting when a link is established Ultimately the most rapid way to detect the event that a link was established should be based on interaction with the link layer. It depends on the implementation of individual system how this interaction is achieved. It should be possible to define an abstraction of the notification from the link layer or L2 hint. The L2 hint should contain the L2 ID of the AP with which the MN got attached. The details of the L2 hint are related to defining the interface or the API between the link layer and the IP layer network control stack. 3.2 Determining necessity of a new IP connectivity establishment Once the MN got informed that it got a new link established, it needs to determine whether a new IP connectivity establishment process should be performed for the link. If the IP layer for the link has not been configured yet (e.g. when the MN just booted up), certainly the IP connectivity establishment process should be initiated. If the IP layer for the link has already been configured (e.g. when the MN did a L2 handover or recovered the link after a loss), a few things should be considered. A. Checking the new subnet a. IP addresses of the ARs b. Network addresses or submasks If the MN finds out that the new subnet is different from the subnet for which the MNÆs existing IP was configured, the MN should start the IP connectivity establishment process. If the new subnet is the same as the old subnet, the MN should check the following. B. Checking the validity of the current IP address a. The lease term if the IP address was leased by DHCP b. The registration period if the IP address was picked from the care-of-addresses advertised by the Foreign Agent c. Duplicity of the IP address (for IPv6) The lease term or the registration period can be checked locally inside the MN but not the duplicity of the IP address (for IPv6). The DAD (Duplicate Address Detection) requires interaction with other nodes on the link and can take a noticeable amount of time. How to optimize the DAD process is already a well-recognized issue. Shim, et al. Expires July 2004 4 Internet Draft Proactive Approach for DNA January 2004 3.3 Acquiring information necessary for a new IP connectivity establishment Once the MN determined to establish a new IP connectivity, the MN may need to get information before starting the actual establishment procedure. Receiving the Router Advertisement from the current AR is one example. The Router Solicitation is already defined to expedite reception of the Router Advertisement in Mobile IP. 4. Our Proposal: Using CARD for DNA We notice and propose that the CARD protocol can be used to optimize the step A of the section 3.2, that is, checking the new subnet. A simple scenario is as the following: +----+ | AR | +----+ | +-----+--------+ | | +----+ +----+ |AP 1| |AP 2| +----+ +----+ A MN was attached with AP 1 initially. While the MN was attached with AP 1, the MN got information about adjacent APs and ARs via tha CARD protocol. The information contains the L2 ID of each adjacent AP and the associated ARÆs IP address and network address. In this scenario, AP 1 and AP 2 are associated to the same single AR. The MN stored the information in its memory (local CAR Table). Sometime later, due to a certain reason, the MN handed over to the AP 2 which was connected to the same AR as AP 1. The MN got notified of the L2 handover from the link layer and also informed of the L2 ID of AP 2. From the local CAR Table, the MN knew that the AP 2 was associated with the same AR as AP 1 and its current IP address configuration was valid. So the MN does not bother itself with any new IP establishment. To repeat, the CAR information distributed by the CARD protocol contains mapping between the L2 ID of an adjacent (or reachable from the MN) AP and the IP address of the AR serving the AP. The mapping could be one-to-one or one-to-many. In principle, there is no limitation on the types of attributes of the AR that can be distributed by the CARD protocol. Therefore, by adding any information necessary for checking the current subnet and/or checking the validity of the existing IP configuration of the MN, the local Shim, et al. Expires July 2004 5 Internet Draft Proactive Approach for DNA January 2004 CAR Table can be used to determine whether the MN needs to proceed to the next step toward a new IP establishment. Also the local CAR Table is helpful for the task of section 3.3, that is, acquiring information necessary for a new IP connectivity establishment. As described in the appendices of the CARD specification and mentioned earlier, the CARD protocol can replace the Router Solicitation Proxy and the Proxy Router Advertisement by simply adding all the information contained in the Proxy Router Advertisement as the attributes of the ARs in the CARD messages. Such a scenario is described in the appendices of the CARD specification. An alternative approach is inserting information about IP layer into beacons of the link layer as suggested in [5]. Certainly it enables the MN to be able to check the new subnet as soon as it finishes the establishment of the new link. The effect is almost the same. We donÆt oppose to the approach. But we notice that it is not easy to coordinate every link layer protocol for the air interface to allow such integration of IP layer information with the link layer beacons. Considering this practical difficulty in relying on the link layer beacons for IP layer information, we believe there should be a solution in the IP layer. As a summary, the cached local CAR Table by the CARD Protocol enables the MN to check the new subnet immediately after the new link is established. Also it provides the MN with the information about the new AR even before the MN receives a Router Advertisement message from the new AR. Since the local CAR Table should be filled before the MNÆs air link is terminated, we call it a Proactive Approach for DNA. 5. What needs to be done The CARD Protocol specification has been worked out by the SeaMoby working group. It is about to be submitted to the IESG for the experimental RFC track. The current CARD Protocol specification defines the message formats to send a request and distribute the CAR information between the MN and the AR or between two ARs. But it does not define the attributes of the AR or the format of each attribute value. To realize the proposed approach, the following should be specified, at least: - Types and value formats of the attributes that should be filled with in the local CAR Table of the MN - When and/or how the attributes should be distributed by the CARD protocol 6. Security Considerations Shim, et al. Expires July 2004 6 Internet Draft Proactive Approach for DNA January 2004 The security for this approach is how to secure the distribution of the CAR information. It should be resolved by the CARD protocol specification. For the solicited mode of the CAR information distribution, the messages should be protected using IPsec ESP according to the specification. But the security measure for the unsolicited CARD Reply messages is an open issue. 7. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8. Informative References [3] Liebsch, M, et al., "Candidate Access Router Discovery",Work in Progress, December 2003. [4] Koodli, R, et al., "Fast handoffs for Mobile IPv6", Work in Progress, October 2003. [5] Tan, P., ôRecommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networksö, Work in Progress, February 2003. 9. Author's Addresses Questions about this memo can also be directed to the authors: Eunsoo Shim NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540 USA Email: eunsoo@nec-labs.com Kyungtae Kim NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540 USA Email: kyungtae@nec-labs.com Jens-Peter Redlich NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540 USA Shim, et al. Expires July 2004 7 Internet Draft Proactive Approach for DNA January 2004 Email: redlich@nec-labs.com Richard D. Gitlin NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540 USA Email: rich@nec-labs.com Shim, et al. Expires July 2004 8 Internet Draft Proactive Approach for DNA January 2004 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 Shim, et al. Expires July 2004 9