| TOC |
|
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 May 12, 2008.
1.
Introduction
2.
Terminology
3.
Problem Statement
4.
Prefix distribution
5.
Evaluation
6.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Connected MANETs have connectivity to one or more external networks, typically the Internet, through one or more MNBR (MANET Border Router, see [2]). MANET routers may generate traffic destined to remote hosts across these external networks. This document gives a framework of autoconfiguration solutions for connected MANETs.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
| TOC |
This document uses the MANET architecture and autoconfiguration problem state terminology defined in [2] and [3], as well as the following terms:
Edge router (ER): The router residing in the external network that maintains links with MANET nodes serving as the gateway between the MANET and external network.
Mobility Anchor Point (MAP): A physical or virtual entity to generate topologically correct prefix for Connected MANETs.
| TOC |
Problem statement for Connected MANETs is given in [3]. We describe more specific problems to consider in this document as follows:
Suppose a MANET has one or more MNBRs and a MANET router needs to communicate with a remote host in the Internet via one of MNBRs (Fig. 1). To do this, the MANET router selects one of the MNBRs and configures a global address for each of its MANET interface using a prefix, that is advertised through the selected MNBR. The MANET router then starts to communicate with the remote host using the configured global address. When the selected MNBR leaves the MANET or it is no longer appropriate as the MNBR for the communication, the MANET router needs to discover a new MNBR to continue communication. If this new MNBR advertises a different prefix, the MANET router configures a new global address using the new prefix, resulting in address change. The address change also occurs, when a MANET has multiple MNBRs and a MANET router re-selects a better MNBR in terms of communication efficiency and a different prefix is advertised thorough this new MNBR.
INTERNET MANET
+---------------+ +----------------------+
| | a | a |
| +--+ | -----> | +---+ -----> +---+ |
| +----->| |------------>| | ------->| | | axxx
| | +--+ | | +---+ ---+ +---+ |
| | ER1 | | MNBR1 | a MNR |
| | | | +---> |
| | | | |
| +---+ | | b |
| |CN | | | +---> |
| +---+ | | | |
| +--+ | | +---+ ---+ |
| | | | | | | |
| +--+ | -----> | +---+ ---+ |
| ER2 | b | MNBR2 | |
| | | +---> |
+---------------+ +----------------------+
MNR : MANET Router
MNBR : MANET Border Router
ER : ISP Edge Router
Fig. 1: The example of communication with a remote host
in the Internet via one of MNBRs.
Such address change is harmful in two aspects. Firstly, any application sessions established between the MANET router in question and the corresponding remote hosts in the Internet are obliged to be terminated, when address change occurs, and new application sessions need to be re-established between them to continue communications. Secondly, route entries based on old addresses in MANET routers become obsolete and route entry re-establishment based on new addresses is required. During route re-establishment, data packets forwarding may fail.
| TOC |
There are two schemes for advertising and distributing topologically correct global prefixes into a connected MANET, that is, Individual Prefix Distribution (IPD) [4]-[7] and Common Prefix Distribution (CPD) [8]-[9]. IPD and CPD are explained in Fig. 2 and Fig. 3, respectively.
In IPD, a topologically correct global prefixes are maintained and advertised by Edge Routers (ERs) and distributed via MNBRs, each of which is connected to the corresponding ER, into the MANET. Different ERs may advertise different global prefixes depending on their topological locations in the Internet.
In Case I of Fig. 2, an MNR obtains the prefix a though MNBR1 and configures the address axxx to communicate with a CN. Later, MNBR1 leaves the MANET and MNR re-select a new MNBR2 and obtains the new prefix b to configure the address bxxx, thus address change occurs. In case of Fig.2, MNR itself roams in the MANET and select MNBR2 based on some metric such as the number of hops between MNR and MNBR. Again the address change from axxx to bxxx occurs.
In CPD, a global prefix is maintained and advertised by a Mobility Anchor Point (MAP) and distributed via ERs and the corresponding MNBRs into the MANET. The same global prefix is therefore distributed regardless of different MNBRs into the MANET.
In Fig. 3, the same prefix a is supplied to both ER1 and ER2 based on an appropriate mechanism such as use of the Moblity Anchor Point (MAP). an MNR obtains the prefix a through MNBR1 and configures the address axxx to communicate with a CN. Later, MNR roams and select MNBR2 for communication efficiency. MNR obtains the same prefix a through MNBR2 and thus can keep the same address axxx. No address change is required.
INTERNET MANET
+---------------+ +---------------------+
| | a | |
| +--+ | -----> | +---+ a |
| +----->| |------------>| | ------> |
| | +--+ | | +---+ ---+ |
| +---+ ER1 | | MNBR1 | +--+ |
| |CN | | | | +-->| | | axxx
| +---+ | | a | +--+ | |
| | | v MNR | | Re-select
+---------------+ +---------------------+ | a new MNBR
| |
v ^ |
+---------------+ +------- | -----------+ |
| +--+ | | +--+ | | |
| +----->| |------------>| |--+ | |
| | +--+ | | +--+ | |
| +---+ ER1 | | MNBR1 b +--+ | v
| |CN | | | +--->| | | bxxx
| +---+ | | | +--+ |
| | +--+ | | +--+ ---+ MNR |
| +----->| |------------>| | -------> |
| +--+ | -----> | +--+ ---+ |
| ER2 | b | MNBR2 | |
| | | +---> |
+---------------+ +---------------------+
(Case I : The selected MNBR leaves)
INTERNET MANET
+---------------+ +----------------------+
| | a | a |
| +--+ | -----> | +---+ -----> +---+ |
| +----->| |------------>| | ------->| | | axxx
| | +--+ | | +---+ ---+ +---+ | |
| | ER1 | | MNBR1 | a MNR | |
| | | | +---> | | |
| | | | | | | Select a
| +---+ | | b | | | better MNBR
| |CN | | | +---> | | |
| +---+ | | | v | |
| | +--+ | | +---+ ---+ b +---+ | v
| +----->| |------------>| | ------->| | | bxxx
| +--+ | -----> | +---+ ---+ +---+ |
| ER2 | b | MNBR2 | MNR |
| | | +---> |
+---------------+ +----------------------+
(Case II : A MANET router roams)
MNR : MANET Router
MNBR : MANET Border Router
ER : ISP Edge Router
Fig. 2: Individual Prefix Distribution Scheme
INTERNET MANET
+---------------------+ +----------------------+
| | a | a |
| +---> +--+ | -----> | +---+ -----> +---+ |
| | +--->| |------------->| | ------->| | | axxx
| a | | +--+ | | +---+ ---+ +---+ | |
| | | ER1 | | MNBR1 | a | | |
| | | | +---> | | |
| | | | | | | Select a
| +--+ +---+ | | a | | | better MNBR
| | |-->| | MAR | | +---> | | |
| +--+ +---+ | | | v | |
| CN | +--+ | | +---+ ---+ a +---+ | v
| | +--->| |------------->| | ------->| | | axxx
| +---> +--+ | -----> | +---+ ---+ +---+ |
| a ER2 | a | MNBR2 | |
| | | +---> |
+---------------------+ +----------------------+
Fig. 3: Common Prefix Distribution Scheme
| TOC |
In IPD, a MANET router my change its global address when it re-selects a new MNBR, resulting in having route entries based on the old address obsolele. Route entries thus needs to be re-established in the MANET. To suppress route re-establishment, multiple address advertisement [6] or MANET-local address-based routing [7] may be used with additional overhead. Specifically, In the former, each node configures multiple care-of-addresses based on the received prefixes and advertises all of them throughout the MANET so that the routing protocol maintains all routes to the multiple addresses [6]. When a node changes its address to one of the advertised addresses, all other nodes already have maintained the route to this address. In the second approach, data packets are tunneled between the MANET routers and the selected MNBRs in both directions. MANET-local address is used for forwarding packets within the MANET [7]. As the result, no route re-establishment needs to be performed. However, these methods can't avoid address change. When address change occurs, application sessions are terminated and need to be re-established.
In CPD, address change does not occur, since the same global prefix is distributed into the MANET, regardless of the difference of MNBR. Application sessions continue to work, when a MANET router re-selects MNBR.
The evaluation is summarized in Table I.
Table I. The evaluation of prefix distribution schemes
for connected MANETs.
+--------------+---------+----------------+--------------------------+
| | Address | Route | Remarks |
| | Change | Reconstruction | |
| | | In MANET | |
+--------------+---------+----------------+--------------------------+
| Individual | Yes | Yes | Route reconstruction can |
| Prefix | | | be suppressed using, |
| Distribution | | | - Multiple address |
| | | | advertisement |
| | | | - MANET-local address |
| | | | based routing |
+--------------+---------+----------------+--------------------------+
| Common | No | No | Mobility Anchor Point, |
| Prefix | | | fixedly or dynamically |
| Distribution | | | configured, may be |
| | | | necessary. |
+--------------+---------+----------------+--------------------------+
| TOC |
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] I. Chakeres, J. Macker, T. Clausen, "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-07 (work in progress), November 2007.
[3] E. Baccelli, K. Mase, S. Ruffino, S. Shingh, "Address Autoconfiguration for MANET: Terminology and Problem statement", draft-ietf-autoconf-statement-01 (work in progress), August 2007.
[4] Wakikawa, R., J. T. Malinen, C. E. Perkins, A. Nilsson, and A. J. Tuominen, "Global Connectivity for Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-04 (work in progress), July 2005.
[5] Jelger, C., T. Noel, and A. Fre, "Gateway and Address Autoconfiguration for IPv6 Ad Hoc Networks", draft-jelger-manet-gateway-autoconf-v6-02 (work in progress), April 2004.
[6] Ruffino, S. and P. Stupar, "Automatic Configuration of IPv6 Addresses for noes in a MANET with Mutiple Gateways", draft-ruffino-manet-autoconf-multigw-01 (work in progress), December 2005.
[7] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol Specification", draft-hofmann-autoconf-mran-00 (work in progress), March 2006.
[8] F. Templin, S. Russert, I. Chakeres, S. Yi, "MANET Autoconfiguration", draft-templin-autoconf-dhcp-09 (work in progress), September 2007.
[9] K.Mase, Y.Owada, "Gateway Aggregation Protocol (GAP) for Mobile Ad hoc Networks", draft-mase-autoconf-gap-01 (work in progress), July 2007.
| TOC |
| Kenichi Mase | |
| Graduate School of Science and Technology, Niigata University | |
| Phone: | +81 25 262 7446 |
| Email: | mase@ie.niigata-u.ac.jp |
| URI: | http://www.net.ie.niigata-u.ac.jp/ |
| Kazuki Akima | |
| Graduate School of Science and Technology, Niigata University | |
| Email: | kakima@net.ie.niigata-u.ac.jp |
| URI: | http://www.net.ie.niigata-u.ac.jp/ |
| TOC |
Copyright © 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.
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.