MIPSHOP Working Group Heejin Jang Internet-Draft Alper Yegin Expires: August 30, 2006 Xiaoyu Liu Samsung-AIT February 27, 2006 Mobile and Wireless Neighborhood Discovery by Using DHCP draft-jang-mipshop-nhdisc-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet-Draft will expire on August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft suggests a mechanism for proactively discovering capability and configuration of handover candidate networks in the neighborhood of a mobile node. Jang, et al. Expires August 30, 2006 [Page 1] Internet-Draft Neighborhood discovery by using DHCP February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DHCP options for Mobile and Wireless Neighborhood Discovery . 5 2.1. Neighborhood Request Option . . . . . . . . . . . . . . . 5 2.2. Neighborhood Reply Option . . . . . . . . . . . . . . . . 6 3. EEE 802.21 MIIS and Heterogeneous Neighborhood Information . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Jang, et al. Expires August 30, 2006 [Page 2] Internet-Draft Neighborhood discovery by using DHCP February 2006 1. Introduction Internet's mobile nodes (MNs)are expected to discover and select their handover targets repeatedly. Once the target is selected, generally a sequence of network authorization, attachment, and configuration steps are executed. In some case, a subset of these steps may be pro-actively executed prior to the handover in order to expedite the post-handover process. In today's heterogeneous deployments mobile nodes and access networks present great variability in terms of the capabilities they need and present. For example, a mobile node may require IPv6 access but not all networks in its neighborhood may support that. A given access network may require IEEE 802.11i support that is not implemented by all nodes today. Such potential mismatches necessitate a proper network discovery and selection process with the expectation that both the selected network and the mobile node will satisfy the needs of each other. A mobile node that has discovered a potential target network has two options to gather the information needed for the selection process. First possibility is that the mobile node is pre-configured with the identifier of the access network that maps to the network information. Network, operator, or access point IDs present in beacons are possible identifiers to be used. While this is the most common option used today, it has practical limitations due to its reliance on mobile node side configuration. For example, when an operator's network has homogeneous capabilities across the deployment, simple mapping between the operator ID and the network capabilities is sufficient. If there is heterogeneity (e.g., only some parts have migrated to IPv6), then the issue becomes harder. Second possibility is that the mobile node takes the "trial-and- error" approach to find an appropriate access network. This is also not a practical approach due to the length of this process when there is more than few networks in one's neighborhood. Pro-active actions, such as pre-authorization, assume that the mobile node knows configuration information pertaining to the target network. The configuration information is typically very specific to the target network (e.g., NAS IP address) and it cannot be easily pre-configured on the mobile nodes for all possible networks. Given the importance of target network information discovery and the practical limitations of the current solutions, a dynamic solution is proposed in this document. The solution relies on using DHCP [1][2]. While DHCP is commonly used for learning configuration information of the currently serving network, an implementation of this proposal allows a node learning configuration information about the Jang, et al. Expires August 30, 2006 [Page 3] Internet-Draft Neighborhood discovery by using DHCP February 2006 neighboring networks. It is assumed that the DHCP server implementing this proposal is pre- configured with the information pertaining to the neighbor networks. Dynamic discovery mechanisms may be developed, but they are outside the scope of this document. An access network may not know about all the others due to practical or business reasons. This is a deployment consideration outside the scope of this protocol design. Location of the DHCP relays and servers does not change with the implementation of this proposal. Mobile node acting as the DHCP client can either request information about all of the neighbor networks or a specific one. The former yields a list of networks and their associated configuration information. The latter assumes the mobile node knows the ID of the specific network (e.g., learned from beacons). Jang, et al. Expires August 30, 2006 [Page 4] Internet-Draft Neighborhood discovery by using DHCP February 2006 2. DHCP options for Mobile and Wireless Neighborhood Discovery This section introduces two DHCP options used for wireless and mobile neighbor discovery. For an MN to acquire the necessary configuration/capabilities information of adjacent networks, it requests to DHCP server by using new DHCP option, Neighborhood Request option. An MN can either request neighbor information on all possible networks in neighborhood or on selected target networks by specifying one or more of the target networks. In the latter case, the MN may identify the neighbor networks by their MAC addresses such as BSSID (Basic Service Set Identification) used by the access points or the base stations. Since the MAC addresses are readily available (e.g. via beacon) once the MN is in the coverage of the neighbor network, this identifier is the best suited one for rapid recognition. As a response to the Neighborhood Request option, the DHCP server retrieves the requested information from its database and replies with Neighborhood Reply option. It is assumed that the DHCP server of the current network maintains a database of other networks in its neighborhood. 2.1. Neighborhood Request Option This option is used to request neighborhood information to DHCP server. This option may carry one or more parameters in the info- request field to identify the specific target networks and the requested parameters that the MN wants to get from the server. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NHReq | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + info-request + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jang, et al. Expires August 30, 2006 [Page 5] Internet-Draft Neighborhood discovery by using DHCP February 2006 option-code OPTION_NHReq (TBD) option-len Total length of the option in octets. info-request This field is the MIHF (Media Independent Handover Function) header. The specific format of this header is described in section 8.3.1 of IEEE 802.21 document [3]. The SID (Service Identifier) value in the MIHF header shall be set to 4 (Information Service) and Opcode (Operation Code) set to 1 (Request). 2.2. Neighborhood Reply Option This option is used to carry the requested neighbor information from a DHCP server to an MN. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NHReq | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + info-reply + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jang, et al. Expires August 30, 2006 [Page 6] Internet-Draft Neighborhood discovery by using DHCP February 2006 option-code OPTION_NHReq (TBD) option-len Total length of the option in octets. info-reply This field is the MIHF (Media Independent Handover Function) header. The specific format of this header is described in section 8.3.1 of IEEE 802.21 document [3]. The SID (Service Identifier) value in the MIHF header shall be set to 4 (Information Service) and Opcode (Operation Code) set to 2 (Response). The info-request/reply fields include Information Elements (IEs) which take a format of TLV. A complete list of such information has been defined in 802.21 [3] and the document categorizes the Information Elements into three groups; General IE, Access Network Specific IE, POA (Point of Attachment) Specific IE. General/Access Network Information elements give a general overview of the different networks providing coverage within an area such as list of available networks and their associated operators, roaming agreements between different operators, cost of connecting to the network and network security and quality of security capabilities. PoA elements provide information about different PoAs for each of the available access networks. These IEs include PoA addressing information, PoA location, data rates supported, the type of PHY and MAC layers and any channel parameters to optimize link layer connectivity. This may also include higher layer services and individual capabilities of different PoAs. For the more detailed information about IE, the Section 6.3.2 of [3] could be refered. Jang, et al. Expires August 30, 2006 [Page 7] Internet-Draft Neighborhood discovery by using DHCP February 2006 3. EEE 802.21 MIIS and Heterogeneous Neighborhood Information Media Independent Information Service (MIIS) defined in [3] enables the functionality across all available access networks by providing uniform way to retrieve heterogeneous network information in any geographical area. An MN may get the heterogeneous neighborhood information by requesting Information Elements (IEs) from MIIS Server. For example, by request and response for TYPE_IE_LIST_OF_NETWORKS, an MN may get the information on the types of neighboring networks such as IEEE 802.11, CDMA2000, UMTS, etc. The heterogeneous neighborhood information may also be delivered to the MN by using the pre-defined reports. For example, the General Information Report provides the neighboring information about link type, number of operators for each link type, and a list of operator for each link type. The information provided by MIIS conforms to structure and semantics specified within 802.21. The key components regarding MIIS in the IEEE 802.21 document are: Information Elements represented by using a standardized format such as XML or TLV; Primitives between MIH Function and MIH User for higher layers to get information from repository; and the frame format for exchanging messages between peer MIH function entities. However, the transport of MIIS is out of the scope of IEEE 802.21. This draft proposes using DHCP as the transport. Jang, et al. Expires August 30, 2006 [Page 8] Internet-Draft Neighborhood discovery by using DHCP February 2006 4. Security Considerations This document does not introduce any new security concerns beyond those specified in the basic DHCP [1] and DHCPv6 [2] specifications. In the absence of message integrity protection for these options, an attacker could modify the option values. Jang, et al. Expires August 30, 2006 [Page 9] Internet-Draft Neighborhood discovery by using DHCP February 2006 5. IANA Consideration This document introduces two new DHCP options, Neighborhood Request and Neighborhood Reply option. The type numbers for these DHCP options are currently TBD. An appropriate request will be made to IANA if this Internet draft gets accepted as an RFC. 6. Normative References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] IEEE P802_21_D00_05, Draft IEEE standard for Local and Metropolitan Area Networks: Media Independent Handover Services. Jang, et al. Expires August 30, 2006 [Page 10] Internet-Draft Neighborhood discovery by using DHCP February 2006 Authors' Addresses Heejin Jang Communication Lab Samsung-AIT P.O. Box 111 Suwon 440-600 Korea Email: heejin.jang@samsung.com Alper E. Yegin Communication Lab Samsung-AIT Istanbul Turkey Email: alper01.yegin@partner.samsung.com Xiaoyu Liu Communication Lab Samsung-AIT P.O. Box 111 Suwon 440-600 Korea Email: xiaoyu.liu@samsung.com Jang, et al. Expires August 30, 2006 [Page 11] Internet-Draft Neighborhood discovery by using DHCP February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jang, et al. Expires August 30, 2006 [Page 12]