Internet DRAFT - draft-akiyoshi-netlmm-protocol
draft-akiyoshi-netlmm-protocol
NETLMM I. Akiyoshi
Internet Draft M. Liebsch
draft-akiyoshi-netlmm-protocol-00.txt NEC
Expires: April 2006 October 2005
NETLMM Protocol
draft-akiyoshi-netlmm-protocol-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 April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
I. Akiyoshi Expires - April 2006 [Page 1]
Internet Draft NETLMM Protocol October 2005
Abstract
This document specifies a network-based protocol which allows mobile
nodes to remain reachable while moving around a certain
administrative network called Edge Mobility Domain. This protocol
also allows mobile nodes to keep their IP address when the mobile
nodes move from one access router to another within the Edge Mobility
Domain.
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].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Protocol Overview..............................................3
4. Protocol Specification.........................................6
4.1 Conceptual Data Structures.................................6
4.2 Access Router Operation....................................7
4.3 Edge Mobility Anchor Point Operation.......................7
Appendix A: Protocol Extensions...................................8
References.......................................................13
Author's Addresses...............................................14
Intellectual Property Statement..................................14
Disclaimer of Validity...........................................14
Copyright Statement..............................................15
I. Akiyoshi Expires - April 2006 [Page 2]
Internet Draft NETLMM Protocol October 2005
1. Introduction
There have been a number of protocol proposals for terminal mobility
management such as MIPv6 [2], HIP [9] and MOBIKE [10]. Moreover there
is a strong requirement of a hierarchical configuration to such
mobility management schemes for achieving a world-wide IP-based
mobile network. Provisioning a hierarchical configuration for each
individual protocol makes a complex and expensive solution. Rather,
providing a unified local mobility management will make a simple and
inexpensive solution.
NETLMM, which is described in this document, is a network-based
localized mobility protocol for achieving such a simple solution.
This document mainly describes the basic configuration of NETLMM. An
advanced configuration is also described in the APPENDIX.
2. Terminology
Access Router (AR)
A router in an Edge Mobility Domain, which registers the
association of a mobile node with its point of attachment to an
Edge Mobility Anchor Point and provides routing services to the
mobile node while registered.
Edge Mobility Anchor Point (EMAP)
A router in an Edge Mobility Domain, which maintains current
location for a mobile node when the mobile node is in an Edge
Mobility Domain and delivers packets to the mobile node. One or
more EMAPs can be deployed in an Edge Mobility Domain.
Edge Mobility Domain (EMD)
An administrative network composed of Access Routers and Edge
Mobility Anchor Points.
3. Protocol Overview
NETLMM protocol is a network-based localized mobility management
protocol operating within an Edge Mobility Domain (EMD). Each AR
advertises the same prefix related to the EMAP's subnet, so that a
mobile node (MN) keeps its IP address when it moves from an AR to
another within an EMD.
This section describes an overview of NETLMM protocol basic
configuration. Within the scope of basic configuration of this
protocol, it is assumed that a single EMAP exists within a single EMD.
The architecture model is shown in Figure 1.
The EMAP manages mapping of the MN's address to the AR's address
where the MN connects. The mapping is used to manage a bi-directional
I. Akiyoshi Expires - April 2006 [Page 3]
Internet Draft NETLMM Protocol October 2005
tunnel between a particular MN's current AR and its EMAP for
forwarding packets from a correspondent node (CN) to the MN.
+----------------------+
| Edge Mobility Domain | +----------+
| | | |
+----+ | +----+ +------+ | | External | +----+
| MN |-+----| AR |--+--| EMAP |-------------------| CN |
+----+ | | +----+ | +------+ | | Network | +----+
| | | | | |
+----+ | | +----+ | | +----------+
| MN |-+ | | AR |--+ |
+----+ | +----+ |
| |
+----------------------+
Figure 1: Architecture Model
The procedure when a MN visits an EMD is shown in Figure 2. When a
MN attaches to the EMD just after its power-on, the MN first acquires
its IP address through a conventional mechanism, such as stateless
[7] or stateful configuration [8] via an AR. Then the MN sends attach
message including the MN's IP address (MN-IP) to the AR (AR1). The
message may be related to Neighbor Discovery Protocol [4] such as
Router Solicitation, Neighbor Solicitation for Duplicated Address
Detection (DAD) and so on.
Receiving the attach message, AR1 detects that the MN has connected
to it. Then AR1 sends a Location Registration Request (LR Req)
message to the EMAP within the EMD. The message includes the MN's
identifier (MN-ID), the MN's IP address (MN-IP) and the AR's IP
address (AR-IP). A MN-ID is needed to identify each MN by an
identifier except the MN's IP address, since all ARs have the same
prefix as EMAP's subnet. And then, AR1 creates a cache entry of
"Location Registration List (LR List)". The cache entry includes
mapping between the MN's IP address and the EMAP's address.
When the EMAP receives the LR Req message, the EMAP creates a cache
entry of mapping between the MN's IP address and AR1's address, which
is called "Location Registration Cache (LR Cache)" in this document.
And then, the EMAP sends a Location Registration Acknowledgement (LR
Ack) back to AR1.
After the LR Req/Ack exchange, the EMAP and AR1 establish a bi-
directional tunnel between the EMAP and AR1. The tunnel is used for
forwarding packets from/to the MN. And then EMAP also performs the
mechanism for intercepting any packets addressed to the MN's IP
address such as proxy Neighbor Discovery [4].
I. Akiyoshi Expires - April 2006 [Page 4]
Internet Draft NETLMM Protocol October 2005
The procedure of handover is shown in Figure 3. When the MN moves
from AR1 to AR2, AR2 performs in the same way as AR1 in Figure 2.
Receiving a LR Req message, the EMAP verifies if it has already had
the LR cache entry for the MN or not. If the EMAP already has the
entry and the AR address in the entry is different from the AR
address in the LR Req message which the EMAP receives, the EMAP sends
a Location Deregistration Request (LD Req) message to AR1 to delete
the LR List entry on the AR1. Receiving the LD Req message, the AR1
deletes the LR List entry and sends a Location Deregistration
Acknowledgement (LD Ack) to the EMAP.
When the procedure which a MN detaches from an EMD such as power-off
happens, an EMAP and an AR should delete the cache entry and the
associated tunnel for the MN. The detail of the detach procedure is
undefined in this document now. But the AR may send the EMAP a
message for deletion of the cache entry or the EMAP and the AR may
have a lifetime in each cache entry.
MN AR1 EMAP
| | |
| Attach | |
|----------------->| |
| (MN-IP) | |
| | |
| Location Registration Request
| |-------------------->|
| |(MN-ID, MN-IP, AR1-IP)
| | |
| Location Registration Acknowledgement
| |<--------------------|
| | |
| | |
Figure 2: Attachment procedure
I. Akiyoshi Expires - April 2006 [Page 5]
Internet Draft NETLMM Protocol October 2005
MN AR2 AR1 EMAP
| | | |
| Attach | | |
|----------------->| | |
| (MN-IP) | | |
| | | |
| | Location Registration Request |
| |------------------------------------------>|
| | (MN-ID, MN-IP, AR2-IP) |
| | | |
| | Location Registration Acknowledgement |
| |<------------------------------------------|
| | | |
| | | |
| | Location Deregistration Request
| | |<--------------------|
| | | (MN-ID, MN-IP) |
| | | |
| | Location Deregistration Acknowledgement
| | |-------------------->|
| | | |
Figure 3: Handover procedure
4. Protocol Specification
This section provides the detailed description of the protocol. As
mentioned in the overview section, the entities that are introduced
in this document are the Access Router (AR) and the Edge Mobility
Anchor Point (EMAP): the detailed operation of both of them is
described in following sections. Before that, the conceptual data
structures that AR and EMAP need to implement are described.
4.1. Conceptual Data Structures
The conceptual data structures used in this protocol are the
following.
- Location Registration Cache (LR Cache)
- Location Registration List (LR List)
An EMAP maintains a LR Cache of bindings between the MN and the AR
where the MN connects. A separate LR Cache entry should be maintained
for each MN. Each LR Cache entry contains the following fields:
- The Identifier which identifies a MN. Network Access Identifier
(NAI) [3] or L2-specific ID such as MAC address is assumed.
I. Akiyoshi Expires - April 2006 [Page 6]
Internet Draft NETLMM Protocol October 2005
- The IP address of the MN.
- The IP address of the AR where the MN is located. This is
updated based on LR Req message received by the AR.
An AR maintains a LR List. A separate LR List entry should be
maintained for each MN. Each LR List entry contains the following
fields:
- The Identifier which identifies a MN. Network Access Identifier
(NAI) [3] or L2-specific ID such as MAC address is assumed.
- The IP address of the MN.
- The IP address of AR where the MN is located.
- The IP address of the node to which a LR Req was sent.
4.2. Access Router Operation
All ARs within an EMD controlled by a singular EMAP sends Router
Advertisement which includes the same prefix as the EMAP's subnet.
Also the AR must be a default router for the MN.
An AR sends a LR Req to an EMAP whenever a new MN attaches on its
link. The LR Req includes the identifier of the MN, IP address of the
MN and IP address of the AR itself. When sending the LR Req to the
EMAP, the AR creates the corresponding LR List entry.
When the AR receives a LR Ack with a status code indicating
successful registration, it sets up a bi-directional tunnel for the
MN. The endpoints of the tunnel are the AR and the EMAP.
When the AR receives a LR Ack with a status code indicating an error,
it must remove the LR List entry. In particular, if the error code
indicates DAD failed, it must notify the MN that the IP address
currently in use is no longer valid.
When the AR receives a LD Req from the EMAP, it must remove the LR
List entry for the MN. And then it sends a LD Ack back to the EMAP.
Traffic from/to the MN goes through a bi-directional tunnel between
the AR and the EMAP. So, the AR encapsulates packets from the MN to
the CN and decapsulates packets from the CN to the MN on the other
hand.
4.3. Edge Mobility Anchor Point Operation
I. Akiyoshi Expires - April 2006 [Page 7]
Internet Draft NETLMM Protocol October 2005
When an EMAP receives a LR Req including an identifier and an IP
address of a MN, it must verify the MN's IP address is unique or not
in the EMD by means of searching LR Caches using the identifier and
the IP address of the MN as a key.
If the LR Req message is valid, the EMAP must then create a new
entry in its LR Cache for this MN or update its existing LR Cache
entry, if the entry already exists.
Unless this EMAP already has a LR Cache entry for the MN, the EMAP
must perform Duplicate Address Detection on the EMAP's link before
returning the LR Ack. This ensures that no other node on the link was
using the MN's IP address when the LR Req arrived. If this Duplicate
Address Detection fails for the MN's address, then the EMAP must send
the AR a LR Ack with a status code indicating Duplicate Address
Detection failure.
If all checks performed after receiving the LR Req have been
successful, the EMAP sends the AR a LR Ack with successful code.
If the EMAP already has the LR Cache entry and the AR address in the
entry is different from the AR address in the LR Req message which
the EMAP receives, the EMAP sends a LD Req message to the AR in the
cache to delete the cache entry on the AR after sending a LR Ack.
Traffic from/to the MN goes through a bi-directional tunnel between
the AR and the EMAP. So, the EMAP decapsulates packets from the MN to
the CN and encapsulates packets from the CN to the MN on the other
hand.
Appendix A: Protocol Extensions
In this section, support for plural EMAPs and route optimization is
described as protocol extensions.
When an EMD is a large network such as cellular network, plural
EMAPs and route optimization within a single EMD may be required from
the viewpoint of load sharing and efficient use of wired network
resources. In this case, all EMAPs should be on the same link to
preserve location privacy. So, all ARs within the EMD to advertise
EMAPs prefix as well as above basic description.
This extension requires the MN to send the message to an AR for
handover. Since context transfer between ARs is needed to take over
some information of the MN, such as the EMAP address which manages
the MN and the AR address where a CN connects, when the MN
communicating with the CN on the optimized routing path moves from
one router to another.
I. Akiyoshi Expires - April 2006 [Page 8]
Internet Draft NETLMM Protocol October 2005
Attachment procedure is shown in Figure 4. AR1 performs almost in
the same way as in Figure 2. The difference is that AR1 performs EMAP
discovery procedure to get an EMAP's IP address for the MN, when AR1
detects the attachment. The mechanism is that AR1 obtains the EMAP
address by requesting from a control server which manages states of
EMAPs or performing similar procedure as Dynamic Home Agent Discovery
procedure of MIPv6[2]. After EMAP discovery procedure, the AR1 sends
LR Req to the MN's EMAP (EMAP1).
EMAP1 operation is the same as the operation described in Figure 2.
When EMAP1 performs DAD on the local link representing the EMAPs
prefix, other EMAPs should listen to associated solicitations and
perform kind of Proxy DAD for the registered MN.
MN AR1 EMAP1
| | |
| Attach | |
|----------------->| |
| (MN-IP) | |
| | |
| +-----------------+ |
| | EMAP Discovery | |
| +-----------------+ |
| | |
| Location Registration Request
| |-------------------->|
| |(MN-ID, MN-IP, AR1-IP)
| | |
| Location Registration Acknowledgement
| |<--------------------|
| | |
| | |
Figure 4: Attachment procedure
Route optimization procedure is shown in Figure 5. The arrows with a
wiggly line and a dual line in this figure indicate original data
flows and tunneled data flows respectively. When AR1 receives a data
packet from the MN to a CN attached to AR2 within the same EMD, AR1
verifies if the destination address has a same prefix as the EMAPs
subnet. If the destination address has the same prefix, AR1 starts
route optimization procedure. Otherwise AR1 performs packet
processing operation described in subsection 4.2.
AR1 tries to get the EMAP which manages the CN to inquire an AR
address where the CN attaches. The detailed mechanism is still
undefined, but AR1 may inquire it from EMAPs. The key for the inquiry
is the CN's IP address. And then, the AR1 sends an AR query message
to the EMAP2. The message includes the CN's IP address.
I. Akiyoshi Expires - April 2006 [Page 9]
Internet Draft NETLMM Protocol October 2005
Receiving the AR query message, EMAP2 searches an AR address where
the CN attached. The key for the search is the CN's IP address
included in the AR query message. And then EMAP2 sends a Reply
message to notify AR1 of the AR address where the CN attaches.
AR1 sends a LR Req to AR2 after getting the AR address where the CN
attaches. The message is used to notify AR2 of the mapping between
the MN and AR1 where the MN attaches. The LR Req may not include the
MN-ID. And then, AR1 creates a LR List entry for route optimization.
Receiving the LR Req message, AR2 verifies if the LR Cache entry for
route optimization already exists or not. Unless AR2 already has the
entry, AR2 creates a new entry in its LR Cache entry for it. If AR2
already has the entry, AR2 updates the entry. If necessary, AR2 may
send a LR Ack message to AR1.
After the route optimization procedure, AR2 tunnels data packets,
whose source and destination are IP address of the CN and the MN
respectively, to AR1 directly.
MN AR1 EMAP1 EMAP2 AR2 CN
| | | | | |
|Data Packet | | | | |
|~~~~~~~~~~~>|============>|~~~~~~~~~~~~>|============>|~~~~~~~~~~~>|
| | | | | |
| | AR Query | | |
| |-------------------------->| | |
| | (CN-IP) | | |
| | | | | |
| | Reply | | |
| |<--------------------------| | |
| | (CN-IP, AR2-IP) | | |
| | | | | |
| | Location Registration Request | |
| |---------------------------------------->| |
| | (MN-IP, AR1-IP) | |
| | | | | |
| Location Registration Acknowledgement (If necessary) |
| |<----------------------------------------| |
| | | | | |
|Data Packet | | | | |
|<~~~~~~~~~~~|<========================================|<~~~~~~~~~~~|
| | | | | |
| | | | | |
Figure 5: Route Optimization procedure
I. Akiyoshi Expires - April 2006 [Page 10]
Internet Draft NETLMM Protocol October 2005
Handover procedure is shown in Figure 6. When the MN moves from AR1
to AR3, the MN sends a handover message to AR2. The message should
include some information related to a previous AR, since the new AR
needs to take over some contexts related to the MN from the previous
AR. The context includes an EMAP address which manages the MN and an
AR address where the CN attaches at least.
Receiving the handover message, AR3 derives AR1 address from
previous AR information included in the handover message. And then,
AR3 sends a Context Transfer Request message to AR1.
When AR1 receives the Context Transfer Request message, AR1 sends
EMAP1 address which manages the MN and AR2 address which the MN
communicates, if any.
Receiving the Context Transfer Acknowledgement message, AR3 creates
the LR List entry for the registration to EMAP1. If AR address is
transferred, AR3 also creates the LR List entry for the registration
to the AR. Then AR3 sends a LR Req message to EMAP1 to register the
MN's new location.
When EMAP1 receives the LR Req message, EMAP1 updates the LR Cache
entry and send a LR Ack message back to AR3. And then EMAP1 also
sends a LD Req message to AR1 to delete the cache entry on it.
If AR address is transferred from AR1 to AR3, the AR3 sends a LR Req
message to let AR2 update the entry in its LR Cache entry for it.
Updating the cache, AR2 may send a LR Ack message as the reply, if
necessary.
I. Akiyoshi Expires - April 2006 [Page 11]
Internet Draft NETLMM Protocol October 2005
MN AR1 AR3 EMAP1 AR2 CN
| | | | | |
|Data Packet | | | | |
|~~~~~~~~~~~>|========================================>|~~~~~~~~~~~>|
| | | | | |
O Move to AR3| | | | |
| | | | | |
| Handover | | | |
|------------------------->| | | |
(MN-ID or MN-IP, previous AR info) | | |
| | | | | |
| Context Transfer Request | | |
| |<------------| | | |
| (MN-Id or MN-IP) | | |
| | | | | |
| Context Transfer Acknowledgement | | |
| |------------>| | | |
| (EMAP1-IP, AR2-IP) | | |
| | | | | |
| | Location Registration Request | |
| | |------------>| | |
| | (MN-ID, MN-IP, AR3-IP) | |
| | | | | |
| | Location Registration Acknowledgement | |
| | |<------------| | |
| | | | | |
| | | | | |
| Location Deregistration Request | |
| |<--------------------------| | |
| | (MN-ID, MN-IP) | | |
| | | | | |
| Location Registration Acknowledgement | |
| |-------------------------->| | |
| | | | | |
| | | | | |
| | Location Registration Request |
| | |-------------------------->| |
| | | (MN-IP, AR3-IP) | |
| | | | | |
| | Location Registration Acknowledgement (If necessary)
| | |<--------------------------| |
| | | | | |
|Data Packet | | | | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~|<==========================|<~~~~~~~~~~~|
| | | | | |
| | | | | |
Figure 6: Handover procedure
I. Akiyoshi Expires - April 2006 [Page 12]
Internet Draft NETLMM Protocol October 2005
References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Aboba, et. al., B., "The Network Access Identifier", RFC2486,
Jan. 1999.
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Problem Statement for IP Local Mobility", Internet-
Draft, draft-kempf-netlmm-nohost-ps-00, June 2005.
[6] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility",
Internet-Draft, draft-kempf-netlmm-nohost-req-00, July 2005.
[7] Thomson, S., Narten, T., Jinmei, T., "IPv6 Stateless Address
Autoconfiguration", Internet-Draft, draft-ietf-ipv6-rfc2462bis-08,
May 2005.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney,
M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC
3315, July 2003.
[9] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T.,
"Host Identity Protocol", Internet Draft, work in progress.
[10] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE
Protocol", Internet Draft, work in progress.
I. Akiyoshi Expires - April 2006 [Page 13]
Internet Draft NETLMM Protocol October 2005
Author's Addresses
Ippei Akiyoshi
NEC Corporation
1753, Shimonumabe, Nakahara-Ku,
Kawasaki, Kanagawa,
Japan
Phone: +81 44 396 2807
Email: i-akiyoshi@ah.jp.nec.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@netlab.nec.de
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,
I. Akiyoshi Expires - April 2006 [Page 14]
Internet Draft NETLMM Protocol October 2005
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 (2005). 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
I. Akiyoshi Expires - April 2006 [Page 15]
