MIPSHOP Working Group Heejin Jang
Internet-Draft Alper Yegin
Expires: October 5, 2007 Xiaoyu Liu
Samsung-AIT
April 3, 2007
Mobile and Wireless Neighborhood Discovery by Using DHCP
draft-jang-mipshop-nhdisc-01.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 October 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Jang, et al. Expires October 5, 2007 [Page 1]
Internet-Draft Neighborhood discovery by using DHCP April 2007
Abstract
This draft suggests a mechanism for proactively discovering
capability and configuration of handover candidate networks in the
neighborhood of a mobile node.
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. Location of DHCP Server . . . . . . . . . . . . . . . . . . . 8
4. IEEE 802.21 MIIS and Heterogeneous Neighborhood Information . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Jang, et al. Expires October 5, 2007 [Page 2]
Internet-Draft Neighborhood discovery by using DHCP April 2007
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 capability/configuration information about the
Jang, et al. Expires October 5, 2007 [Page 3]
Internet-Draft Neighborhood discovery by using DHCP April 2007
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 October 5, 2007 [Page 4]
Internet-Draft Neighborhood discovery by using DHCP April 2007
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. The database may be maintained by
DHCP server, or by some entities in the network. MIIS server and
DHCP server may not necessarily co-located.
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 +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Neighborhood Request Option Format
Jang, et al. Expires October 5, 2007 [Page 5]
Internet-Draft Neighborhood discovery by using DHCP April 2007
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) frame. The specific format of this is
described in section 8.3 of IEEE 802.21 document [3].
The values of SID (Service Identifier), Opcode (Operation
Code) and AID (Action Identifier) in the MIHF header
shall be set to 4 (Information Service), 1 (Request) and
26 (MIH_Get_Information) respectively.
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_NHRep | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ info-reply +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Neighborhood Reply Option Format
Jang, et al. Expires October 5, 2007 [Page 6]
Internet-Draft Neighborhood discovery by using DHCP April 2007
option-code
OPTION_NHRep (TBD)
option-len
Total length of the option in octets.
info-reply
This field is the MIHF (Media Independent Handover
Function) frame. The specific format of this is
described in section 8.3 of IEEE 802.21 document [3].
The values of SID (Service Identifier), Opcode (Operation
Code) and AID (Action Identifier) in the MIHF header
shall be set to 4 (Information Service), 2 (Response) and
26 (MIH_Get_Information) respectively.
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.4 of [3] could be referred.
Jang, et al. Expires October 5, 2007 [Page 7]
Internet-Draft Neighborhood discovery by using DHCP April 2007
3. Location of DHCP Server
Location of DHCP server is a deployment decision. It may be co-
located with the access router, or hosted on a centralized server
within the access network. In the latter case, a DHCP relay is
utilized on or alongside the access router. Use of options defined
in this document does not mandate particular placement of DHCP
entities.
In case the DHCP server that hosts the requested information is
different than the DHCP server used for other configuration
parameters pertaining to the currently serving network, on-link DHCP
relay may route the DHCP requests accordingly.
Jang, et al. Expires October 5, 2007 [Page 8]
Internet-Draft Neighborhood discovery by using DHCP April 2007
4. IEEE 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_CONTAINER_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 for IEEE 802.21 IS (not for ES and CS).
Jang, et al. Expires October 5, 2007 [Page 9]
Internet-Draft Neighborhood discovery by using DHCP April 2007
5. 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 October 5, 2007 [Page 10]
Internet-Draft Neighborhood discovery by using DHCP April 2007
6. IANA Consideration
This document introduces two new DHCP options, Neighborhood Request
and Neighborhood Reply options. 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.
Jang, et al. Expires October 5, 2007 [Page 11]
Internet-Draft Neighborhood discovery by using DHCP April 2007
7. 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/D04.00, Draft Standard for Local and Metropolitan
Area Networks: Media Independent Handover Services, February
2007.
Jang, et al. Expires October 5, 2007 [Page 12]
Internet-Draft Neighborhood discovery by using DHCP April 2007
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 October 5, 2007 [Page 13]
Internet-Draft Neighborhood discovery by using DHCP April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jang, et al. Expires October 5, 2007 [Page 14]