Internet DRAFT - draft-wanghui-netlmm-protocol
draft-wanghui-netlmm-protocol
NETLMM Hui Wang
Internet Draft Yanfeng Zhang
Draft-wanghui-netlmm-protocol-00.txt Yong Xia
NEC Labs China
Expires: Oct. 2006 April 10, 2006
NETLMM Protocol
draft-wanghui-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 July 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document specifies a network-based localized mobility management
(NETLMM) protocol which enables mobile nodes remaining reachable
while moving across different access routers in a certain access
network zone called Edge Mobility Domain (EMD). This protocol
requires no extra host stack support and no complex security and
H. Wang Expires October 10, 2006 [Page 1]
Internet-Draft NETLMM Protocol April 2006
signaling interactions between mobile node and the access network.
Especially, by utilizing the neighbor Access Router (AR) information,
NETLMM can achieve very fast and smooth handover performance to fit
the requirements of most real-time and interactive multimedia
applications.
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................................................2
2. Terminology.................................................3
3. Protocol Overview...........................................4
3.1. MN Attaching Procedure..................................5
3.2. Communication Initialization Procedure..................6
3.3. Fast Handover Procedure.................................7
4. Protocol Specification......................................11
4.1. Conceptual Data Structures.............................11
4.2. Access Router Operation................................11
4.3. Edge Mobility Anchor Point Operation...................13
5. Security Considerations.....................................14
6. IANA Considerations........................................14
7. Acknowledgments............................................14
8. References.................................................14
Author's Addresses............................................16
Intellectual Property Statement................................16
Disclaimer of Validity........................................17
Copyright Statement...........................................17
Acknowledgment................................................17
1. Introduction
A number of protocol proposals for terminal mobility management have
been proposed in IETF, such as MIPv6 [2], HIP [9] and MOBIKE [10].
They could be view as global mobility protocols, which allow a mobile
node to maintain reach-ability when changing its attaching access
routers, by updating the address mapping between the home address and
care-of address at the global mobility anchor point, or even changing
the mapping directly at the corresponding node end to end. Global
mobility management protocols can be used between access routers to
H. Wang Expires October 10, 2006 [Page 2]
Internet-Draft NETLMM Protocol April 2006
handle local mobility. However there are many well-known problems,
such as possibly long location update latency, large signaling cost
and etc. An extensive discussion on these problems can be found in
[5]. Instead of using a global mobility management protocol on each
IP link move, a protocol to localize the management of topologically
small movements is more preferable to handle local movements. And the
requirements and gap analysis for IP local mobility are discussed in
[6].
This document describes a Network-based Localized Mobility Management
(NETLMM) protocol, which is aimed to achieve the goals proposed in [5]
and [6]. This document describes the efficient support for mobile
nodes communicating with peers both outside and inside the same
mobility domain when mobile nodes moves across different access
routers, which requires no extra host stack support, no complex
security and signaling interactions between mobile node and the
access network. By utilizing the neighbor Access Router information,
NETLMM can achieve very fast and smooth handover performance to fit
the requirements of most real-time and interactive multimedia
applications.
2. Terminology
Access Router (AR)
A router in an Edge Mobility Domain, which handles the movement
events of a mobile node, registers the association of a mobile node
with its point of attachment to an Edge Mobility Anchor Point and
provides routing services to mobile nodes.
Edge Mobility Anchor Point (EMAP)
EMAP is a light location server in an Edge Mobility Domain, which
maintains current location (the attaching AR) for a mobile node when
the mobile node is in an Edge Mobility Domain. EMAP is generally
embedded in the gateway of an Edge Mobility Domain, and thus it also
takes the role of delivering the packets to mobile hosts.
Edge Mobility Domain (EMD)
An administrative network composed of Access Routers and Edge
Mobility Anchor Points. Besides ARs and EMAPs, an EMD can also
contain other internal networking components, such as a common router,
to construct the whole EMD. But the common routers cannot provide
access service with mobility support.
H. Wang Expires October 10, 2006 [Page 3]
Internet-Draft NETLMM Protocol April 2006
3. Protocol Overview
NETLMM protocol, operating within an Edge Mobility Domain (EMD), is a
network-based localized mobility management protocol, which supports
both IPv6 and IPv4. In this draft, we use IPv6 for illustration. The
IP address configuration for a mobile node (MN) is the same as in
standard IPv6 system, by either using DHCP or stateless IP address
configuration. As for DHCP method, the DHCP server will assign the
same subnet address to all mobile nodes; as for stateless IP address
configuration, each AR advertises the same prefix which is called the
EMD subnet prefix, so that a MN keeps its IP address unchanged when
it moves among different ARs within an EMD.
This section describes an overview of NETLMM protocol configuration.
It is assumed that only one single EMAP exists within this EMD. The
architecture model is shown in Figure 1. The communications between
both MN-CN and MN1-MN2 will be discussed, with the fast handover
procedure. NETLMM utilizes link layer identifier to help to do fast
and efficient handover. The architecture model in Figure 1 is a
little different from the network model depicted as Figure 1 in the
problem statement document [5]. Compared with the later, the Access
Points (APs) is omitted on Figure 1 in this draft. The reason is
that when the MN moves between two APs belonging to the same AR, the
AR knows nothing about this movement. Since this NETLMM protocol is
focusing on layer 3 handover between ARs, we just simply this
architecture model. From this point of view, the architecture model
in this draft is consistent with that in the problem statement draft
[5].
+----------------------+
| Edge Mobility Domain | +----------+
| | | |
+-----+ | +----+ +------+ | | External | +----+
| MN1 |-+---| AR |--+--| EMAP |-------------------| CN |
+-----+ | +----+ | +------+ | | Network | +----+
| | | | |
+-----+ | +----+ | | +----------+
| MN2 |-+---| AR |--+ |
+-----+ | +----+ |
| |
+----------------------+
Figure 1 : Architecture Model
The EMAP works as a local domain location server, managing mapping of
the MN's address to the AR's address where the MN attaches. On one
hand, the mapping is used to manage a bi-directional tunnel between a
particular MN's current AR and its EMAP for forwarding packets
H. Wang Expires October 10, 2006 [Page 4]
Internet-Draft NETLMM Protocol April 2006
between a correspondent node (CN) outside the EMD and the MN. On the
other hand, while for support intra EMD communications between local
mobile nodes, this mapping will provide a location information to
help to build the bi-directional tunnel to forward data between the
two ARs which the MNs attaching to. The detailed processes will be
given below.
3.1. MN Attaching Procedure
Figure 2 gives the procedure when a MN newly attaches to an AR in an
EMD. When a MN attaches to the AR just after its power-on, the MN
first starts a link layer association process with AR. In the real
deployment, other link layer devices such as access points may be
used between AR and MN, in this case MN directly associates with an
AP; and then AP will send this association event to AR and/or AR will
actively sense this event. For example, the multiple 802.11 access
points are interconnected by means of a distribution system -
typically an Ethernet which an AR attaches to. When the MN associates
with one of the APs, a layer-2 update frame is broadcasted in order
to register the mobile node's current location with all bridges and
switches in the distribution system. And the AR can learn those
events at the same time. The association process is radio technology
specific, which is beyond the scope of this draft. To make the
discussion clearer, we just say that MN directly does association/de-
association/re-associations with AR in the following. And we assume
that when those association/re-association/de-association/ events are
accomplished, AR is able to recognize them and know the peer link
layer ID (for example, if the 802.11 technology is adopted, the link
layer ID is MAC address of the mobile node's wireless interface). We
will use MN-ID to denote the mobile node's ID.
After the link layer association process is finished, MN will try to
acquire its IP address through a conventional mechanism, such as
stateless [7] or stateful configuration [8] via the attaching AR. On
the network side, the AR will recognize this attaching and know the
mapping of MN's IP address (MN-IP) and its MN-ID. For stateless
configuration, AR can learn MN's IP address through many ways such as
Router Solicitation, Neighbor Solicitation for Duplicated Address
Detection (DAD) and so on. If stateful IP address configuration is
used, AR acts as DHCP relay between DHCP server and MN, so it can
know MN-IP and MN-ID naturally. The default route/gateway in MN is
set to be the same default router/gateway of this EMD. Thus, when MN
moves among different ARs, the layer 3 configurations, including its
IP address and the default router, will always keep unchanged.
H. Wang Expires October 10, 2006 [Page 5]
Internet-Draft NETLMM Protocol April 2006
After the MN-IP is configured, AR1 takes 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).
And then, AR1 creates a cache entry of "Local Registered MN List (LR
List)". The cache entry includes mapping among the MN-ID, the MN-IP
and the EMAP's address, which makes the AR1 know which MN is
attaching to it.
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 enables MN to visit the
Internet through this EMD. But the intra EMD communication will not
go through EMAP (refer to next section 3.2).
MN AR1 EMAP
| | |
Link layer association | |
|----------------->| {AR1 gets MN-ID} |
Configure IP address | |
|<---------------->| {AR1 gets MN-IP} |
| | |
| | |
| Location Registration Request
| |-------------------->|
| |(MN-ID, MN-IP, AR1-IP)
| | |
| Location Registration Acknowledgement
| |<--------------------|
| | |
| | |
Figure 2 : Attachment procedure
3.2. Communication Initialization Procedure
If MN wants to send packets to a CN outside of his EMD (i.e. CN and
MN have different IP subnet prefix), MN will send the packets to its
default router - the EMD default router/gateway. When MN sends
Neighbor Solicitation (IPv6) or ARP Request (IPv4) for the default
router/gateway, the attaching AR will reply to it as to cheat the MN
H. Wang Expires October 10, 2006 [Page 6]
Internet-Draft NETLMM Protocol April 2006
that it is the default router. Then AR will forward the intercepted
packets via the bi-tunnel to the real default router of this EMD,
normally, the EMAP. EMAP, acting the gateway of this EMD, will
further forward the packets to external network.
If CN and MN are in the same EMD, there will be a little difference.
Figure 3 denotes the basic process. Since MN and CN have the same IP
subnet prefix, MN will send Neighbor Solicitation (IPv6) or ARP
Request (IPv4) message to resolve the link layer address of CN before
sending the real data packets. On receiving such messages, the
attaching AR (AR1) will check its Local Registered MN List to see if
he has the binding information for this CN-IP. If it has no entry
with this CN-IP, AR1 will send a CN Location Query message to EMAP
with the key of CN-IP. On receiving this CN Location Query message,
EMAP will look up its local Location Registration Cache and return
back the current attaching AR-IP (AR2) of the CN-IP via a CN Location
Reply message. Then AR1 gets the AR2-IP, and it sends Tunnel Setup
Request message to AR2 with the information of "MN-IP, AR1-IP, CN-IP,
AR2-IP". Optionally, AR2 will send a Tunnel Built Acknowledgement
message back to AR1. After this procedure, a bi-tunnel between AR1
and AR2 is built up. AR1 and AR2 sends reply to MN's Neighbor
Solicitation or ARP request, and then intercept the packets destined
to CN and MN respectively. And thus MN can build data communication
with CN via the bi-tunnel between AR1 and AR2.
MN AR1 EMAP AR2 CN
| | | | |
|-------->| {MN sends Neighbor Solicitation message} |
| | | | |
| CN Location Query (CN-IP) | |
| |------------->| | |
| CN Location Reply (CN-IP, AR2-IP)| |
| |<-------------| | |
| Tunnel Setup Request (MN-IP, AR1-IP, CN-IP, AR2-IP)
| |---------------------------->| |
| Tunnel Built Acknowledgement | |
| |<----------------------------| |
| | | |
|<~~~~~~~>|<===========================>|<~~~~~~~~~~~>|
| | | |
Figure 3 : Communication process when MN & CN are in the same EMD
3.3. Fast Handover Procedure
NETLMM implements a neighbor AR information assisted fast handover
scheme. First, neighboring AR can build neighbor information with
H. Wang Expires October 10, 2006 [Page 7]
Internet-Draft NETLMM Protocol April 2006
each other through other methods such as neighbor information
broadcast or CARD protocols [11]. How to build the neighborhood
relationship will not be discussed in this draft. The entire neighbor
ARs are considered to be the possible candidate ARs when a MN moves
out of current AR. By utilizing the neighbor AR information, NETLMM
can achieve a very fast and smooth handover to fit the requirements
of most real-time and interactive multimedia applications.
The procedure of handover is shown in Figure 4 and Figure 5. Figure 4
gives the scenario when CN is outside the EMD, while Figure 5 depicts
the scenario when CN is in the same EMD as MN. The operations for
both scenarios can be combined together as seen in section 4 -
protocol specification.
Neighbor
MN AR2 AR1 EMAP ARs
| | {Link layer de-association} | |
0<-------------- X ------------>|{AR1 gets the MN-ID} | |
| | |{AR1 starts to buffer data} |
| | MN Movement Notification & MN's context| |
| |<--------------------|---------------------------->|
| | (MN-ID, MN-IP, AR1-IP) | |
| | | | |
0-------->|{Link layer (re-)association} | |
| |{AR2 gets the MN-ID} | | |
| | | | |
| | MN Fast Handover Notification (MN-ID, MN-IP, AR2-IP)
| |-------------------->| | |
| | Buffered data | | |
|<~~~~~~~~|<====================| | |
| | | | |
| | MN Location Update Request (AR2-IP, MN-IP)| |
| |------------------------------------------>| |
| | | MN Location Update | |
| | |<--------------------| |
| | | (MN-ID, MN-IP) | |
| | | | |
| | Location Registration Acknowledgement | |
| |<------------------------------------------| |
| | | | |
|<~~~~~~~>|<=========================================>| |
Figure 4 : Handover procedure (1)
Figure 4 gives the handover procedure when the MN moves from AR1 to
AR2. First, MN performs link layer de-association with AR1. AR1
immediately recognizes this de-association and knows the MN-ID. Then
H. Wang Expires October 10, 2006 [Page 8]
Internet-Draft NETLMM Protocol April 2006
AR1 starts to buffer the packets destined to MN-IP (MN-ID), and sends
a MN Movement Notification message and MN's context to its
neighboring ARs, containing the MN-ID and MN-IP. At the same time,
MN's movement causes its link layer do re-associations with new AR
(say, AR2). Once the re-association completes, AR2 recognizes the new
attachment with the MN-ID. Since AR2 has already received a MN
Movement Notification message with this MN-ID, AR2 knows this MN has
moved to its service coverage area and is not a new joiner for the
EMD. AR2 sends a MN Fast Handover Notification message to AR1, and
also a MN Location Update Request to EMAP as described in section 3.1.
On receiving the MN Fast Handover Notification message, AR1 will
first forward the buffered packets to AR2 (and then the packets will
be forwarded to MN). Before the new data path between EMAP and AR has
been setup, AR1 will keep forwarding the packets destined to MN-IP
(MN-ID) as to keep the handover packet lossless. On the other hand,
once EMAP receives the MN Location Update Request message, EMAP will
look up its "Location Registration Cache" and updates the Location
Registration Cache with the new AR-IP for this MN-IP and build new
bi-tunnel between EMAP and AR2 to forward data from/to MN-IP. After
tunnel is setup, EMAP will send a MN Location Update message to AR1
to update the "Local Registered MN List" in AR1 and the tunnel
between AR1 and EMAP for this MN will be removed. Thus the handover
process completes.
Figure 5 gives the handover procedure when the communication is
between two MN inside the same EMD. The basic process is the same.
After the detection of MN-ID's link layer de-association, AR1
performs the same as described in Figure 4: buffer the packets
destined to MN-IP (MN-ID), and sends a MN Movement Notification
message and MN's context to its neighboring ARs. Also when AR2
detects the link layer attachment of MN-ID, it performs the same:
sends a MN Fast Handover Notification message to AR1, and a MN
Location Update Request to EMAP. On one hand, EMAP deals with this MN
Location Update Request message the same way as in Figure 4. On the
other hand, on receiving the MN Fast Handover Notification message,
AR1 not only forwards the buffered data to AR2, but also sends a
Tunnel Update Request message to AR3 (CN is attaching to AR3)
containing the MN-IP, AR1-IP, CN-IP and AR2-IP. AR3 acts to this
Tunnel Update Request message by sending a Tunnel Setup Request
message to AR2 with AR3-IP, CN-IP, AR2-IP and MN-IP. AR2 will return
a Tunnel Built Acknowledgement message to AR3. On receiving the
Tunnel Built Acknowledgement message from AR2, AR3 will remove the
old bi-tunnel setting between AR3 and AR1, and then send a Tunnel
Remove message to notify AR1 to remove the related bi-tunnel between
AR1 and AR3. Thus the new bi-tunnel between AR2 and AR3 is built to
forward packets between MN and CN. And the whole handover process
completes.
H. Wang Expires October 10, 2006 [Page 9]
Internet-Draft NETLMM Protocol April 2006
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 AR2 AR1 EMAP AR3 CN
| | | | | |
|Data Packet | | | | |
|<~~~~~~~~~~~~~~~~~~~~~~~~>|<=========================>|<~~~~~~~~~~>|
| | | | | |
0 ---------X-------------->|{Link layer de-association,AR1 gets MN-ID}
| | |{AR1 starts to buffer data}| |
| | | | | |
| |< ---------- |MN movement notification & MN's context |
| | | | | |
| {Link layer (re-)association with AR2; AR2 gets MN-ID} |
0----------->| | | | |
| MN Fast Handover Notification (MN-ID, MN-IP, AR2-IP) |
| |------------>| | | |
| | MN Location Update Request (AR2-IP, MN-IP) |
| |-------------------------->| | |
| | | | | |
| |Buffered data| | | |
|<~~~~~~~~~~~|<============| | | |
| | | | | |
| | | Tunnel Update Request | |
| | |-------------------------->| |
| | | (MN-IP, AR2-IP, AR3-IP, CN-IP) |
| | | | | |
| | Tunnel Setup Request (AR3-IP, CN-IP, AR2-IP, MN-IP) |
| |<----------------------------------------| |
| | | | | |
| Tunnel Built Acknowledgement (AR3-IP, CN-IP, AR2-IP, MN-IP) |
| |---------------------------------------->| |
| | | | | |
| Tunnel Remove Notification (AR3-IP, CN-IP, AR1-IP, MN-IP) |
| | |<--------------------------| |
| | | | | |
|Data Packet | | | | |
|<~~~~~~~~~~>|<=======================================>|<~~~~~~~~~~>|
Figure 5 : Handover procedure (2)
H. Wang Expires October 10, 2006 [Page 10]
Internet-Draft NETLMM Protocol April 2006
4. Protocol Specification
As described in the previous sections, the entities that are
introduced in NETLMM protocol 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.
- MN Location Registration Cache (LR Cache)
- MN Location Registration List (LR List)
LR Cache keeps the bindings between the MN and the AR where the MN
attaches to for each MH, which is maintained by the EMAP. One LR
Cache entry contains the following fields:
- The Identifier which identifies a MN (MN-ID). In this protocol,
link layer specific ID such as MAC address is assumed to be the MN-ID.
- The IP address of the MN (MN-IP).
- The IP address of the AR where the MN is attaching to. (AR-IP)
The LR List is maintained in each AR, which records all the MH that
attaches to this AR. Each LR List entry contains the following fields:
MN-ID, MN-IP, EMAP-IP (the EMAP the MN location is registered). The
LR List can be seen as a subset of the LR Cache in EMAP.
4.2. Access Router Operation
All ARs within an EMD send Router Advertisement which includes the
same prefix as the EMD subnet prefix. Also the AR advertise the EMAP
or the gateway of this EMD to be the default router for the MN, which
allows no any L3 change to the MN (IP address and the default router)
when it moves among different ARs.
An AR sends a MN Location Registration Request (LR Req) to an EMAP
whenever a new MN attaches on its link. The LR Req includes the MN-ID,
MN-IP and AR-IP. When sending the LR Req to the EMAP, the AR creates
the corresponding LR List entry.
H. Wang Expires October 10, 2006 [Page 11]
Internet-Draft NETLMM Protocol April 2006
When the AR receives a Location Registration Acknowledgement with a
status code indicating successful registration, it sets up a bi-
directional tunnel with EMAP for the MN.
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 AR catches the Neighbor Solicitation (IPv6) or ARP Request
message from MN (IPv4), it must send a CN Location Query message to
EMAP with the CN-IP embedded. And afterwards, when it receives the CN
Location Reply from the EMAP with a successful code, AR (AR1) can
know the AR (AR2) which CN is now attaching to. Then AR1 sends a
Tunnel Setup Request message to AR2 containing (MN-IP, AR1-IP, CN-IP,
AR2-IP).
When the AR receives a Tunnel Setup Request from another AR, it must
setup a tunnel using the endpoint information (MN-IP, CN-IP, AR1-IP,
and AR2-IP) contained in the request message, and then send back a
Tunnel Built Acknowledgement.
Traffic from/to the MN goes through a bi-directional tunnel between
the AR and the EMAP, or between the two ARs. So, the AR encapsulates
and decapsultes packets from/to the MN.
When AR1 receives a link layer de-association event from MN-ID, it
must buffer the packets that are destined to MN-ID and send MN
Movement Notification message to all of its neighboring ARs
containing MN-ID, MN-IP and AR1-IP.
When AR2 receives a link layer (re-)association event from MN-ID, it
looks up local MN movement notification list. If the MN-ID is
notified earlier from AR1, it must send MN Fast Handover Notification
message (MN-ID, MN-IP, AR2-IP) to AR1. At the same time, it must send
MN Location Registration Request to EMAP with (AR2-IP,MN-IP).
On receiving a MN Fast Handover Notification message, AR1 must
forward the buffered data to AR2. And at the same time, AR1 must
check to see if there exists bi-tunnel with other ARs for this MN-ID.
If this kind of bi-tunnels exists, AR1 must send Tunnel Update
Request message, containing the new endpoint (say, AR2) of this
tunnel (MN-IP, AR2-IP, AR3-IP, CN-IP), to AR3 that is the other
endpoint of this bi-tunnel.
On receiving a Tunnel Update Request message from the peer endpoint
of a bi-tunnel, AR (AR3) must sends a Tunnel Setup Request message to
H. Wang Expires October 10, 2006 [Page 12]
Internet-Draft NETLMM Protocol April 2006
AR2. On receiving Tunnel Setup Request message, AR2 must setup bi-
tunnel with AR3 to forward packet from MN-IP and CN-IP, and send back
a Tunnel Built Acknowledgement message to AR3. When AR3 gets this
acknowledgement message, it must remove the current bi-tunnel with
AR1 and send a Tunnel Remove Notification to AR1 which lets AR1 to
remove the related tunnel setting.
On receiving a MN Location Update message from EMAP, AR must update
its local LR List and remove the related bi-tunnel setting.
4.3. Edge Mobility Anchor Point Operation
When an EMAP receives a MN Location Registration Request including
MN-IP, MN-ID and AR-IP, it must verify the MN-IP is unique or not in
the EMD by means of searching LR Caches using the MN-ID and/or MN-IP
as a key. If the LR Req message is valid, EMAP must create a new
entry in its LR Cache for this MN or update its existing LR Cache
entry, if the entry already exists.
If MN obtains its IP address through stateless IPv6 address
configuration, and unless this EMAP already has a LR Cache entry for
the MN, the EMAP must lookup to see if there is already a same IP
address in the LR Caches before returning the LR Ack. Since the LR
Caches in EMAP contain all the MN's information (MAC-ID, MN-IP, AR-
IP), this lookup operation ensures that no other node is using the
same IP address inside this EMD and the Duplicate Address Detection
process can be skipped. If this lookup returns that there is
collision for the MN's address, the EMAP must send the AR a LR Ack
with a status code indicating Duplicate Address Detection failure. If
MN's IP address is configured through stateful address configuration
protocols by a center DHCP server, the above DAD procedure can be
removed. In fact, we can put the DHCP server inside EMAP. The EMAP
sends the AR a LR Ack with successful code if all checks performed
after receiving the LR Req have been successful.
On receiving the Location Update Request message from ARs, EMAP just
updates the LR cache, removes its local tunnel settings related to
the old AR for this MN and sends a MN Location Update message to the
AR in the cache to remove the cache entry on the AR.
On receiving the Location Query message (MN-IP) from ARs, EMAP
performs a lookup of the LR Caches with the key of MN-IP. If it finds
an entry for this MN-IP, EMAP returns a MN Location Reply message to
the AR containing the MH-IP and AR-IP; if it fails to find the
related entry, it returns a MN Location Reply message to the AR
containing a failure code.
H. Wang Expires October 10, 2006 [Page 13]
Internet-Draft NETLMM Protocol April 2006
Normally, EMAP is embedded in the gateway, so the bi-tunnel between
AR and EMAP is setup to enable MN to visit Internet. The EMAP should
de-capsulate packets from the MN to the Internet and encapsulates
packets from the Internet to the MN on the other hand.
5. Security Considerations
Since NETLMM provides mobility support without any extra signaling
between the mobile node and network, it requires no extra security
association between the mobile node and the network entity that
protect such kind of signaling messages. Also removing mobile node
involvement in localized mobility management limits the possibility
of DoS attacks on network infrastructural elements [6].
The security problem between the entities among NETLMM network side
is to protect the NETLMM signaling messages. IPSec can be applied
here to guarantee the messages. The security associations between
NETLMM entities can be built through static configuration or from
other infrastructures, which is currently not analyzed in this draft.
6. IANA Considerations
This document will register with the IANA the protocol parameters set;
details of these registrations will appear in a later version of the
draft.
7. Acknowledgments
The authors would like to thank Jinling Wang, Yichuan Wu, Yingang
Yuan for their reviews and comments on this document.
8. 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.
H. Wang Expires October 10, 2006 [Page 14]
Internet-Draft NETLMM Protocol April 2006
[5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Problem Statement for IP Local Mobility",
Internet-Draft, draft-ietf-netlmm-nohost-ps-00, Feburary, 2006,
working in progress.
[6] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Requirements and Gap Analysis for IP Local
Mobility", Internet-Draft, draft-ietf-netlmm-nohost-req-00,
Feburary, 2006, working in progress.
[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.
[11] Marco Liebsch, et al. "Candidate Access Router Discovery",
Internet Draft, draft-ietf-seamoby-card-protocol-08.txt, work
in progress
H. Wang Expires October 10, 2006 [Page 15]
Internet-Draft NETLMM Protocol April 2006
Author's Addresses
Hui Wang
NEC Laboratories China
11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park
No.1, Zhong Guan Chun East Road, Beijing
China
Phone: +81 10 6270 5962 ext# 323
Email: wanghui@research.nec.com.cn
Yanfeng Zhang
NEC Laboratories China
11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park
No.1, Zhong Guan Chun East Road, Beijing
China
Phone: +81 10 6270 5962 ext# 210
Email: zhangyanfeng@research.nec.com.cn
Yong Xia
NEC Laboratories China
11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park
No.1, Zhong Guan Chun East Road, Beijing
China
Phone: +81 10 6270 5962 ext# 320
Email: xiayong@research.nec.com.cn
Comments are solicited and should be addressed to the working group's
mailing list at netlmm@ngnet.it and/or the author(s)
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.
H. Wang Expires October 10, 2006 [Page 16]
Internet-Draft NETLMM Protocol April 2006
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.
H. Wang Expires October 10, 2006 [Page 17]
