Internet DRAFT - draft-giaretta-netlmm-protocol
draft-giaretta-netlmm-protocol
NETLMM BOF G. Giaretta
Internet Draft I. Guardini
Expires: April 14, 2006 E. Demaria
Tilab
October 14, 2005
Network-based localized mobility management (NETLMM)
with distributed anchor routers
<draft-giaretta-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 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes a network-based local mobility management
protocol that implies minimal host involvement in mobility
management procedures and fulfills the requirements provided in
draft-kempf-netlmm-nohost-req-00.
Giaretta, et al. Expires April 14, 2006 [Page 1]
Internet-Draft NETLMM Protocol October 2005
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].
Giaretta, et al. Expires April 14, 2006 [Page 2]
Internet-Draft NETLMM Protocol October 2005
Table of Contents
1. Introduction...................................................4
2. Terminology....................................................5
3. Reference architecture.........................................6
4. Protocol Overview..............................................7
5. Protocol Specification........................................11
5.1. Conceptual Data Structures...............................11
5.2. Visited Access Router Operation..........................12
5.2.1. HAR discovery.......................................12
5.2.2. Sending Location Updates............................13
5.2.3. Receiving Location Acknowledgements.................13
5.2.4. Packet processing...................................13
5.3. Home Anchor Router Operation.............................14
5.3.1. Receiving Location Updates..........................14
5.3.2. Sending Location Acknowledgements...................14
5.3.3. Packet Processing...................................14
6. Allocation of a centralized HAR within the LMMD...............16
7. Neighbor Discovery Considerations.............................17
8. Host Considerations...........................................19
8.1. Access through Neighbor Discovery........................19
8.2. Access through PANA/DHCP.................................23
9. Packets Formats...............................................27
10. Security Considerations......................................28
11. References...................................................29
11.1. Normative References....................................29
11.2. Informative References..................................29
12. Appendix A: Support for Route Optimization...................31
12.1. Basic Operation.........................................31
12.2. Management of host movements............................34
12.3. Recovery from error conditions..........................35
Authors' Addresses...............................................38
Intellectual Property Statement..................................39
Disclaimer of Validity...........................................39
Copyright Statement..............................................39
Acknowledgment...................................................39
Giaretta, et al. Expires April 14, 2006 [Page 3]
Internet-Draft NETLMM Protocol October 2005
1. Introduction
draft-kempf-netlmm-nohost-ps-00 [8] briefly describes the local
mobility problem and describes the two most serious issues with
existing protocols: the requirement for host support, and the
complex security interactions required between the host and the
network. A more complete list of requirements for a localized
mobility management solution is provided in [9].
This document describes a network-based mobility management
protocol that implies minimal host involvement in mobility
management procedures and fulfills the requirements provided
in [9].
The document is organized as follows: section 3 describes the
reference network architecture and the reference scenario. Section
4 provides an overview of the protocol and section 5 describes the
detailed protocol specification and related data structures.
Section 6 describes an optional feature of the protocol to
increase the degree of location privacy provided to hosts and
section 7 raises some possible issues with standard Neighbor
Discovery. Section 9 lists some approaches that can be used by
hosts to configure their addresses and to trigger mobility
management procedures. Finally, appendix A gives an overview on
how the protocol may be extended to provide optimal routing to
data packets.
Giaretta, et al. Expires April 14, 2006 [Page 4]
Internet-Draft NETLMM Protocol October 2005
2. Terminology
General mobility terminology can be found in [4]. The following
additional terms are used here:
HAR
Home Anchor Router. A router that provides mobility anchor
point functionalities to a host. The HAR can be co-located
with the Access Router where the host switches on or can be a
separate node different from any Access Router.
VAR
Visited Access Router. The Access Router where the host is
located. The VAR provides the HAR with the current location of
the host.
Location Cache
This cache contains an entry for each host which the node is
acting as HAR for. Its purpose and format are very similar to
Mobile IPv6 Binding Cache.
Location Update List
This cache contains an entry for each host the Access Router
acts as VAR. Its purpose and format are very similar to Mobile
IPv6 Binding Update List.
Giaretta, et al. Expires April 14, 2006 [Page 5]
Internet-Draft NETLMM Protocol October 2005
3. Reference architecture
The protocol described in this document can be used to handle IP
mobility within an Localized Mobility Management Domain (LMMD).
The reference network architecture is shown in Figure 1.
A single LMMD can span a whole administrative domain (e.g. the
network of an operator) or part of it. The edge of the LMMD is
made of Access Routers (ARs) and Border Gateways (BGs). An AR can
manage one or more IP links (i.e. layer 2 access networks), each
one univocally associated with at least an IPv6 prefix. It
represents
the first IP router encountered by the mobile node on the way to
the destination. The BGs are used to interconnect the LMMD with
external networks, which can be traditional IP networks like the
Internet or other LMMDs. There are no constraints on the internal
topology of an LMMD.
+--------------------------------+
| | +-----------------+
| LMM +---+ | External |
| Domain |BG |--| Network |
| +---+ | (e.g. Internet) |
| | +-----------------+
| +---+ +---+ +---+ | |
+---|AR1|-----|AR2|-----|AR3|----+ |
+---+ +---+ +---+ +--+
| | | |CN|
L2 | | | +--+
Access | | |
-+-+-+- -+-+-+- -+-+-+-
| | | | | | Base
O O O O O O Stations
Prefix-1 Prefix-2 Prefix-3
+--+ +--+
|MN| ----> |CN|
+--+ Movement +--+
MN's address:
IP-MN
Figure 1 - Reference architecture
As long as the mobile node remains within the same LMMD, it can
keep on using the same IP address even if it happens to change the
AR it is attached to.
Giaretta, et al. Expires April 14, 2006 [Page 6]
Internet-Draft NETLMM Protocol October 2005
4. Protocol Overview
Each AR sends Router Advertisement messages as described in [2].
These RAs include one or more prefix options that are specific to
the link. In case stateless auto-configuration can be used, the
bit A in the prefix option is set to one.
When a mobile node (MN) powers up on a link, it configures an
address through an address configuration mechanism: stateless
autoconfiguration [3], DHCP [7] or a AAA-based mechanism can be
used for this purpose. The address configured by the host is
topologically correct since it belongs to the network prefix
announced by the Access Router. As soon as the host has configured
an address, the Access Router receives an indication of the
presence of the host. This is depicted in Figure 2 as an activate
message. This message may be a Router Solicitation, a Neighbor
Solicitation, an unsolicited Neighbor Advertisement or it can be a
network trigger after the address configuration procedure.
Figure 2 depicts the host and AR operation when the host activates
on a link. When the AR receives an activate message including an
IP address that belongs to one of its network prefixes, it does
not need to perform any mobility management procedure. The traffic
to and from the host is delivered using standard IP routing, which
means that it is not tunneled. This is an important feature of the
protocol since it does not introduce any packet or signaling
overhead for nodes that are not moving or for nodes with limited
mobility requirements. This scenario is similar to the case of a
Mobile IPv6 MN located in the home network.
Giaretta, et al. Expires April 14, 2006 [Page 7]
Internet-Draft NETLMM Protocol October 2005
+--+ +---+ +---+ +--+
|MN| |AR1| |AR2| |CN|
+--+ +---+ +---+ +--+
| | | |
| /-----------\ | | |
|/ Address \| | |
|\ conf. /| | |
| \-----------/ | | |
| | | |
|Activate (IP-MN) | |
|-------------->| | |
| | | |
| Plain data packets (no tunneling) |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
Figure 2 - MN bootstrapping and routing from/to the home network
When the MN moves to another link, it sends an activate message to
the new AR (AR2 in Figure 3) with an indication of the IP address
used on the previous link. The type of indication depends on the
implementation of the activate message: some examples are
described in section 8. The AR acts as the Visited Access Router
for the host. Based on the IP address provided by the host the VAR
discovers its HAR: this can be done based on an exchange with a
topology server (i.e. a data-base maintaining the correspondence
between prefixes and HARs) or based on records already present in
the VAR. Once identified the HAR of the host, the VAR sends a
Location Update message to the HAR including its own address and
the IP address of the host. The HAR adds a new entry in its
Location Cache and replies with a Location Acknowledgement
message. The result of this message exchange is the set up of a
bi-directional tunnel between HAR and VAR. HAR intercepts all
packets sent to the host and forwards them to the tunnel
interface. From an implementation point of view, since several
hosts can share the same HAR and can be on the same VAR's link at
the same time, HAR and VAR can share an unique tunnel for all
these hosts.
Giaretta, et al. Expires April 14, 2006 [Page 8]
Internet-Draft NETLMM Protocol October 2005
HAR of MN VAR of MN
+--+ +---+ +---+ +--+
|MN| |AR1| |AR2| |CN|
+--+ +---+ +---+ +--+
| | | |
Moves | | |
to AR2 | | |
| Activate (IP-MN) | |
|------------------------------->| |
| | | |
| Location Update (IP-MN,AR2) |
| |<---------------| |
| +--------+ | |
| |Location| | |
| | Cache | | |
| | Update | | |
| +--------+ | |
| | Location Ack. | |
| |--------------->| |
| | | |
| | Plain data packets (no tunneling) |
| O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| O Tunnel | |
| O===============>O |
| | O |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O |
Figure 3 - First MN movement and Location Update
Subsequent MN's movements are handled in the same way as the
described in Figure 3. The only difference is highlighted in
Figure 4: when the HAR receives a Location Update message from a
new VAR, it updates its Location Cache and should send a Move
Notify message to the old VAR (AR2 in Figure 4) including the IP
address of the host. This can be needed in networks where AR2 does
not have an explicit indication that host has moved. When it
receives a Move Notify message, the VAR must delete the host-
specific entry in its Location Update List.
Giaretta, et al. Expires April 14, 2006 [Page 9]
Internet-Draft NETLMM Protocol October 2005
HAR of MN VAR of MN
+--+ +---+ +---+ +---+ +--+
|MN| |AR1| |AR2| |AR3| |CN|
+--+ +---+ +---+ +---+ +--+
| | | | |
Moves | | | |
to AR3 | | | |
| Activate (IP-MN) | |
|--------------------------------------------->| |
| | | | |
| | Location Update (IP-MN,AR3) | |
| |<-----------------------------| |
| | | | |
| +--------+ | | |
| |Location| | | |
| | Cache | | | |
| | Update | | | |
| +--------+ | | |
| | Location Acknowledge | |
| |----------------------------->| |
| | | | |
| Move Notify (IP-MN) | |
| |------------>| | |
| | | | |
| | Move Ack. | | |
| |<------------| | |
| | | | |
| | Plain data packets (no tunneling) |
| O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| O HAR-VAR tunnel | |
| O=============================>O |
| | | O |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O |
| | | | |
Figure 4 - Subsequent MN movements
Giaretta, et al. Expires April 14, 2006 [Page 10]
Internet-Draft NETLMM Protocol October 2005
5. Protocol Specification
This section provides the detailed description of the protocol. As
mentioned in the overview, the entities that are introduced in
this document are the Visited Access Router (VAR) and the Home
Anchor Router (HAR): the detailed operation of both of them is
described in following sections. Before that, the data structures
that VAR and HAR need to implement are described.
5.1. Conceptual Data Structures
The conceptual data structures introduced in this document are:
the Location Cache (LC), the Location Update List (LUL), the
Prefix Cache (PC) and the Active Visitors List (AVL).
The Location Cache must be implemented by each HAR. Its purpose
and format are very similar to Mobile IPv6 Binding Cache. It
contains an entry for each host which the node is acting as HAR
for. Conceptually, each Location Cache entry contains the
following fields:
o the IP address of the host for which this is the Location Cache
entry;
o the IP address of the VAR where the host is located. This is
updated based on Location Update messages received by the HAR;
o a lifetime value, indicating the remaining lifetime for this
Location Cache entry. The lifetime value is initialized from
the Lifetime field in the Location Update message;
o the maximum value of the Sequence Number field received in
previous Location Updates.
The Location Update List must be implemented by each VAR. Its
purpose and format are very similar to Mobile IPv6 Binding Update
List. It contains an entry for each host the Access Router acts as
VAR. Each Location Update List entry conceptually contains the
following fields:
o the IP address of the host for which this is the Location
Update List entry;
o the IP address of the HAR of the host;
o the value of the Lifetime field sent in the last Location
Update message;
o the remaining lifetime for this Location Update List entry.
This value is used by the VAR to schedule subsequent Location
Update messages;
Giaretta, et al. Expires April 14, 2006 [Page 11]
Internet-Draft NETLMM Protocol October 2005
o the maximum value of the Sequence Number field sent in previous
Location Updates to this HAR.
The Prefix Cache must be implemented by each VAR. The purpose of
this cache is to bind network prefixes to Home Anchor Routers. It
is used by VARs to determine the HAR of the host that has sent an
activate message. Prefix Cache entries can be statically
configured or dynamically created based on queries to a topology
server or based on some other protocols. The specification of the
mechanisms used by Access Routers to fill this cache is out of the
scope of this document. Each entry of the Prefix Cache
conceptually contains the following fields:
o the network prefix for which this is the Prefix Cache Entry.
This field is used as the key for searching the Home Anchor
Router of a host;
o the IP address of node that acts as Home Anchor Router for the
network prefix in the Prefix field;
o the remaining lifetime of that matching.
The Activate Visitors List must be implemented by all VARs. It
contains an entry for each host connected to the VAR. This list is
updated through activate messages and therefore can be implemented
as part of Neighbor Discovery specific caches (e.g. Destination
Cache, Neighbor Cache). This list is used if the link layer does
not provide any hint on the presence of the host. Conceptually,
each Activate Visitors List entry contains the following fields:
o the IP address of the host the entry is related;
o the time of the last hint of host's presence received by the
VAR;
o the remaining lifetime: this field is re-initialized when the
VAR receives a hint of host presence. When this lifetime
expires, the VAR removes the entry.
5.2. Visited Access Router Operation
5.2.1. HAR discovery
When a host attaches to a new link, it sends an activate
notification. This notification can be a neighbor discovery
message (e.g. Router Solicitation) or a network trigger after the
authentication procedure (e.g. PANA Bind Answer, an internal
trigger from the AAA infrastructure) and must contain the global
IP address of the host. Based on the global IP address provided by
Giaretta, et al. Expires April 14, 2006 [Page 12]
Internet-Draft NETLMM Protocol October 2005
the host, the VAR must identify a HAR for that host. This
information is gathered from the Prefix Cache. The key for
searching this information is the network prefix of the host
address: since the VAR cannot be aware of the prefix length, a
longest prefix match approach is applied. Once the VAR has
identified a HAR for a host, it sends a Location Update.
5.2.2. Sending Location Updates
A VAR sends a Location Update message whenever a new host attaches
on its link or when the remaining lifetime field of a Location
Update List entry is going to expire. The Location Update message
is sent to the HAR of the host: this is discovered through the
procedure described in section 5.2.1 for the initial Location
Update and is gathered from the HAR field in the Location Update
List entry for subsequent Location Updates.
The Location Update message includes the IP address provided by
the host, a sequence number and a lifetime value.
By means of the Location Update the VAR requests the Home Anchor
Router to serve as the Home Anchor Router for the given IP ddress.
When sending the Location Update to the HAR, the VAR must also
create or update the corresponding Location Update List entry. The
last Sequence Number value sent to the HAR in a Location Update is
stored by the VAR in its Location Update List entry. If the
sending VAR has no Location Update List entry, the Sequence Number
should start at a random value.
5.2.3. Receiving Location Acknowledgements
When the VAR receives a Location Acknowledgement (LA) with Status
0 (success), it should track this in the Location Update List and
it must start tunneling the packets from the host to the HAR. The
outcome of a successful LU-LA exchange is the set up of a bi-
directional tunnel between VAR and HAR that carries all packets
from/to the host.
When the VAR receives a Location Acknowledgement with Status
greater than 128 it must remove the entry in the Location Update
List. In particular, if the Status is 129 (DAD failed), it must
notify the host that the IP address currently in use is no longer
valid and another IP address has to be configured. The way this
notification is delivered depend on the access protocol employed
between MN and VAR (e.g. Neighbor Discovery, DHCP, PANA).
5.2.4. Packet processing
As mentioned before, the outcome of a LU-LA exchange is the set-up
of a bi-directional tunneling between the VAR and HAR. The tunnel
end-points are the IP address of the VAR and the IP address of the
Giaretta, et al. Expires April 14, 2006 [Page 13]
Internet-Draft NETLMM Protocol October 2005
HAR. The same tunnel can be shared by all hosts; in this case,
after a LU-LA exchange, the VAR needs only to update its
forwarding table so that all traffic from and to the host is
tunneled through the HAR.
5.3. Home Anchor Router Operation
5.3.1. Receiving Location Updates
When a HAR receives a Location Update, it validates it checking
that the host's IP address belongs to one of the network prefixes
it announces and the sequence number is a correct one.
If the Location Update is valid, the HAR searches in its Location
Cache using the host's IP address as a key. If an entry is
present, the HAR updates the entry. If no entry is present in the
Location Cache for the IP address of the host and the Location
Update has been validated, the HAR MUST create a new entry in its
Location Cache for the host. In this case, before returning the
Location Acknowledgement, the HAR MUST perform Duplicate Address
Detection. This ensures that no other node on the link is using
the host's address. If this Duplicate Address Detection fails for
the given address, then the HAR MUST reject the complete Location
Update, remove the Location Cache entry and MUST return a Location
Acknowledgement to the VAR with the Status field set to 129 (DAD
failed).
5.3.2. Sending Location Acknowledgements
If all checks performed after receiving a Location Update has been
successful, the HAR sends to the VAR a Location Acknowledgment
with Status field set to 0.
The HAR may refuse a Location Update. In this case it must send a
Location Acknowledgement with Status field greater than 128. In
particular, if the DAD for the IP address of the host has failed,
the HAR must send a Location Acknowledgement with Status 129 (DAD
failed).
5.3.3. Packet Processing
When the HAR has a valid Location Cache entry in its Location
Cache, it starts performing proxy Neighbor Discovery and defending
the host's IP address. Moreover, the HAR must intercept packets
that are addressed to the host. This is done in the same way a
Mobile IPv6 Home Agent intercepts Mobile Node's packets [10]. When
the HAR intercepts a packet to a host, it must lookup in its
Location Cache to get the location of the host (i.e. the VAR) and
must tunnel the packet to the VAR.
Giaretta, et al. Expires April 14, 2006 [Page 14]
Internet-Draft NETLMM Protocol October 2005
The HAR must also handle reverse tunneled packets since VAR
tunnels packets from the host to the HAR. The HAR must decapsulate
the packet and forward it to the actual destination. As in Mobile
IPv6, the HAR MUST verify that the Source Address in the tunnel IP
header is the host's IP address present in the Location Cache
entry.
Giaretta, et al. Expires April 14, 2006 [Page 15]
Internet-Draft NETLMM Protocol October 2005
6. Allocation of a centralized HAR within the LMMD
The protocol described in this document can be used also in
network scenarios where the HAR assigned to the MN is not co-
located with any of the available ARs, but is implemented as a
dedicated piece of equipment associated with the whole LMMD.
In this case, at power on (or the first time it enters the LMMD)
the MN has to be configured with an IP address belonging to the
"virtual link" managed by the centralized HAR. Standard Neighbor
Discovery (ND) cannot be used for that purpose, in that the
network prefix for stateless autoconfiguration is different from
the one announced by the AR on the access interface. Instead,
these are some possible suitable solutions:
o the inclusion of a HAR Option in Router Advertisement (RA)
messages. This option, which is similar to the MAP Option
defined for Mobility Anchor Point discovery in HMIPv6 [10],
could be used to carry the IP address of the HAR and the
related prefix information;
o the usage of standard DHCPv6;
o the usage of PANA or EAP for assigning a global IPv6 address
during the authentication procedure for network access. In this
case the IPv6 address, and the correspondent HAR, to be
allocated to the MN can be selected by the AAA server and then
delivered to the MN by means of some newly defined AVPs/TLVs.
Maintaining one or more HARs separated from the ARs has the
advantage of improving location privacy, in that the IP address
assigned to the MN does not disclose any information on the actual
point of attachment of the MN within the LMMD. The drawback of
this architecture is that data traffic exchanged by the MN gets
always tunneled in the fixed network (i.e. higher overhead), since
the MN can never be connected to its HAR (i.e. it is attached to a
VAR at any time).
Giaretta, et al. Expires April 14, 2006 [Page 16]
Internet-Draft NETLMM Protocol October 2005
7. Neighbor Discovery Considerations
Based on the protocol described in this document the host does not
change its IP address after an IP handover. This implies that
within a Localized Mobility Management Domain the host maintains
the same IP address independently from its movements and its
actual location. This feature of the protocol may arise some
issues related to Neighbor Discovery and how the address
resolution is made by hosts.
When the host powers up on a link it gets an IP address specific
to that link. The correspondent nodes that belong to the same IP
link can send packets to the host directly after performing an
address resolution procedure based on [2]. This is true if the
prefixes announced by the Access Router have the bit L set, which
implies that the prefix is used by hosts for on-link
determination. When the host has moved, the scenario is similar to
a movement of a Mobile IPv6 MN from the home network to a foreign
network. The HAR starts performing Proxy Neighbor Discovery and
the packets to the host are intercepted by the HAR and forwarded
to the host itself.
A scenario that may arise some issues related to Neighbor
Discovery is the following: the host moves from one foreign
network to another. While in the first foreign network, the host
may communicate with a correspondent node located in the same
link. In this case, if the prefix option sent by the VAR has the L
bit set, the host understands that the correspondent node is in
the same link. Therefore, it may perform an address resolution
procedure with a Neighbor Solicitation and Neighbor Advertisement
exchange in order to get the link local address of the
correspondent node. In the Neighbor Solicitation message, based on
[2], the host MUST include its link-layer address in a Source
Link-Layer Address option. This implies that the correspondent
node is aware of the link-layer address of the host and the
communication takes place directly, without any involvement of the
VAR. However, as soon as the host moves to another link, the
correspondent node does not have any mechanism to quickly
understand that the host is no more in its link. The unique tool
provided by Neighbor Discovery for that purpose is the Neighbor
Unreachability Detection procedure [2] but it requires a large
amount of time that may disrupt real-time on-going communications.
To avoid these problems, the VAR SHOULD send Router Advertisements
with the L flag unset in the prefix option: this implies that
hosts do not perform address resolution procedures with its
correspondent nodes and therefore the communication always occurs
through the Access Router.
Based on the same motivations, the Access Router SHOULD NOT send
Redirect messages to the correspondent nodes to inform them that
Giaretta, et al. Expires April 14, 2006 [Page 17]
Internet-Draft NETLMM Protocol October 2005
the host is on-link. The Access Router MAY send Redirect messages
only if it is aware that both host and correspondent node are
fixed and thus the issue described above does not apply.
Giaretta, et al. Expires April 14, 2006 [Page 18]
Internet-Draft NETLMM Protocol October 2005
8. Host Considerations
The mobility management protocol specified in this document is
independent from the procedure followed by the mobile node to gain
access to the network, and is therefore applicable to several
deployment scenarios (ISP, enterprise, etc.).
Movement detection can be carried out using unsolicited Router
Advertisements (RAs) with Interval Option, as specified in [10],
or exploiting available optimizations to further reduce the
handoff latency, such as DNA protocol [13][14][15][18] or L2
triggers.
The impacts on the mobile node are minimal and are limited to
slight modifications in the way IP addresses are renewed across
mobility events. After any link change, a host compliant with this
specification SHOULD always try to keep the IP address used in the
previous point of attachment, unless an explicit indication to
release it is received from the network.
In order to enable this model, the employed access protocol(s)
MUST be compliant with the following assumptions:
o it MUST be possible for the MN to request the confirmation of
the IP address used in a previously visited link;
o it MUST be possible for the network (e.g. AR) to signal to the
MN that an IP address cannot be reconfirmed and has to be
immediately released (e.g. the MN has moved to a new LMMD).
Possible access protocols that fulfill these requirements include:
o Neighbor Discovery (ND), eventually coupled with CGAs for
testing address ownership;
o the usage of PANA together with DHCP.
A few examples showing how to use ND and/or PANA in conjunction
with the protocol described in this document are provided in the
following sections.
Other viable options may be the sole usage of DHCP or the
exploitation of L2 protocols (or triggers) specific of the radio
technology employed in the access network.
8.1. Access through Neighbor Discovery
MN bootstrap using ND can be carried out as shown in Figure 5.
Giaretta, et al. Expires April 14, 2006 [Page 19]
Internet-Draft NETLMM Protocol October 2005
+--+ +---+ +---+
|MN| |AR1| |AR2|
+--+ +---+ +---+
| | |
+--------+ | |
| Build | | |
|LL addr.| | |
+--------+ | |
| NS (LL addr.) | DAD for link-local |
|----------------------->| address |
| | |
+--------+ | |
| Conf. | | |
|LL addr.| | |
+--------+ | |
| RS | |
|----------------------->| |
| | |
| RA (Prefix-1,bit A=1, | |
| lifetime=infinite) | RA can be unsolicited |
|<-----------------------| Valid and Preferred |
| | lifetimes of advert. |
+--------+ | prefixes are infinite |
| Build | | |
| global | | |
+--------+ | |
| NS (IP-MN) | DAD for global |
|----------------------->| address |
| | |
| +----------------------+ |
| |Verify addr. ownership| |
| | (if IP-MN is CGA) | |
| +----------------------+ |
| | |
| +------------+ |
+--------+ |Enable IP-MN| |
| Conf. | +------------+ |
| global | | |
+--------+ | |
| | |
Figure 5 - ND: MN bootstrap
The procedure involves the following steps:
o at power-on the MN builds a link-local address and performs
Duplicate Address Detection (DAD). If the address proves to be
unique, the MN configures it on its network interface;
Giaretta, et al. Expires April 14, 2006 [Page 20]
Internet-Draft NETLMM Protocol October 2005
o MN performs router discovery sending a Router Solicitation (RS)
to the all routers multicast address;
o AR responds with a solicited Router Advertisement (RA)
including one or more Prefix Options, listing the IPv6
prefixes that can be used by the MN to build a valid global
address through stateless autoconfiguration (i.e. bit A set
to 1). Each prefix SHOULD be advertised with Valid and
Preferred lifetimes set to infinite;
o MN builds one or more global addresses through stateless
autoconfiguration and performs a DAD check for each of them;
o AR uses the Neighbor Solicitation (NS) message delivered as
part of the DAD procedure as a trigger indicating the MN is
asking the activation of a specific global address (i.e. IP-MN
in Figure 5);
o if the global address is a CGA (Cryptographically Generated
Address) [6], AR can use the validity check specified in [5] to
verify whether the MN is entitled to claim the ownership of the
address. Otherwise, based on policy rules defined by the
network administrator, the AR can decide to reject the request
or to accept it all the same;
o upon successful verification of the address ownership, AR
enables the global address claimed by MN (e.g. adjustment of
ingress filtering rules);
o at the expiration of the time-out involved by the DAD procedure
[3], the MN configures the global address on its network
interface and starts using it.
As long as the MN remains connected to the AR where it switched
on, any communication can be carried out using standard IP
routing, since the MN is using a topologically correct address.
Subsequent movements can be handled as shown in Figure 6.
Giaretta, et al. Expires April 14, 2006 [Page 21]
Internet-Draft NETLMM Protocol October 2005
+--+ +---+ +---+
|MN| |AR1| |AR2|
+--+ +---+ +---+
| | |
Moves | |
to AR2 | |
| | |
+------------+ | |
|Detect loss | | |
|of RAs from | | |
|AR1 through | | |
|int. option | | |
+------------+ | |
| NS (AR1) | |
|----------------->X Neighbor Unreachability |
|-------------->X Detection (NUD) for AR1 |
| | |
+------------+ | |
|No replies: | | |
|detects mov.| | |
+------------+ | |
| RS | |
|------------------------------------------------->|
| RA (Prefix-2,Flag A=1,Lifetime=Infinite) |
|<-------------------------------------------------|
| | |
| NS (IP-MN) | | DAD for
|------------------------------------------------->| IP-MN
| | |
| | +-------------------+
| | |Verify addr. owner.|
| | |(if IP-MN is CGA) |
| | +-------------------+
| | /---------------------\ |
| AR1 is HAR |/ NETLMM \|
| for MN |\ Protocol /|
| | \---------------------/ |
| | +------------+
| | |Enable IP-MN|
| | +------------+
| | |
Figure 6 - ND: mobility
Giaretta, et al. Expires April 14, 2006 [Page 22]
Internet-Draft NETLMM Protocol October 2005
The procedure involves the following steps:
o MN detects the movement as described in [10], and therefore,
after having discovered the loss of a sequence of RAs, performs
Neighbor Unreachability Detection (NUD) for the previous AR.
Other approaches for movement detection may be suitable as well
and the choice does not impact on the rest of the procedure;
o MN performs router discovery on the new link sending a Router
Solicitation (RS) to the all routers multicast address;
o the AR available on the new link (i.e. AR2 in the example of
Figure 6) responds with a solicited Router Advertisement (RA)
including one or more Prefix Options. Optionally the MN can use
this fresh prefix information to build one or more
topologically valid global addresses through stateless
autoconfiguration;
o MN signals that it is willing to keep the previous global
address performing a new DAD check for it. Optimistic DAD
solutions [16] can be applied to shorten DAD latency and enable
fast handovers;
o at the reception of the NS sent out as part of the DAD
procedure, the AR verifies the ownership of the global address
claimed by the MN (if the address is a CGA) and then triggers
the NETLMM Protocol to adjust host routing within the Localized
Mobility Management Domain (LMMD). The HAR of the MN is the AR
where the MN switched on (i.e. AR1 in the example of Figure 6);
o if the NETLMM protocol completes successfully, the AR enables
the global address and the MN can start using it for exchanging
data traffic with its correspondents.
8.2. Access through PANA/DHCP
In case the MN has to authenticate itself for gaining network
access and the authentication procedure is carried out relaying on
PANA [17], the bootstrap phase can be handled as described in
Figure 7. The procedure involves the following steps:
o at power-on the MN undertakes a full PANA authentication. The
MN is the PANA Authentication Client (PAC) and the AR is the
PANA Authentication Agent (PAA). The PAA works as a pass-
through for EAP authentication, that involves the PAC and a
backend AAA server;
o at the end of the authentication phase, the backend AAA server
verifies if the MN has to be handled using the NETLMM protocol.
This check can be performed based on the subscription
information included in the user service profile;
Giaretta, et al. Expires April 14, 2006 [Page 23]
Internet-Draft NETLMM Protocol October 2005
o if NETLMM protocol has to be enabled, the AAA server selects a
suitable HAR and allocates a global address. The selected HAR
can be co-located on the AR visited by the MN or can be a
dedicated machine located somewhere else within the LMMD;
o the AAA server communicates to the AR the global address
allocated to the MN (and related lifetimes) inserting a NETLMM
AVP in the RADIUS (or Diameter) Access-Accept message. This AVP
may optionally include also the address of the correspondent
HAR, so that the AR does not have to discover it afterwards;
o at the reception of the Access-Accept message, the AR delivers
to the MN a PANA-Bind-Request including a Post PANA Address
Configuration (PPAC) AVP [17]. The Flag D included in the PPAC
AVP is set to 1, indicating that the MN is expected to
configure a Post PANA Address using DHCP;
o the MN responds with a PANA-Bind-Answer and then, as mandated
by the previous PANA-Bind-Request, undertakes a DHCP handshake
to get a valid global address;
o the AR works as a local DHCP server and offers to the MN the
global address previously received from the AAA server;
o the MN confirms that it is willing to accept the configuration
offered by the AR in the DHCP Request;
o at the reception of the DHCP Request, the AR activates the
NETLMM protocol to adjust host routing within the LMMD;
o if the NETLMM protocol terminates successfully, the AR enables
the global address assigned to the MN (e.g. tuning of ingress
filtering policies) and sends the DHCP Reply.
Giaretta, et al. Expires April 14, 2006 [Page 24]
Internet-Draft NETLMM Protocol October 2005
+--+ +---+ +---+ +---+ +---+
|MN| |AR1| |AR2| |AAA| |HAR|
+--+ +---+ +---+ +---+ +---+
| PANA Start Req. | | | |
|<--------------------| | | |
| PANA Start Answ. | | | |
|-------------------->| | | |
| /-----------------\ | /-------------------------\ | |
|/ PANA authentic. \|/ RADIUS \| |
|\ (N round trips) /|\ or Diameter /| |
| \-----------------/ | \-------------------------/ | |
| | | | |
| PANA-Auth-Answer | | | |
| (EAP-Response) | RADIUS Access-Request | |
|-------------------->| (EAP-Response) | |
| |---------------------------->| |
| | | +---------+ |
| | | |Authoriz.| |
| | | | & addr. | |
| PANA-Bind-Request | RADIUS Access-Accept |selection| |
| (EAP-Success,PPAC | (EAP-Success,NETLMM AVP)+---------+ |
| with Flag D=1) |<---------------|------------| |
|<--------------------| | | | |
| PANA-Bind-Answer | | | +--------------+ |
|-------------------->| | | |IP address | |
| DHCP Solicit | | +-->|to be assigned| |
|-------------------->| | |to MN (IP-MN) | |
| DHCP Advertise | | +--------------+ |
|<--------------------| | | |
| DHCP Request | | | |
|-------------------->| | | |
| | /-----------------------------------\ |
| |/ NETLMM \|
| |\ Protocol /|
| | \-----------------------------------/ |
| +------------+ | | |
| |Enable IP-MN| | | |
| DHCP Reply +------------+ | | |
|<--------------------| | | |
| | | | |
Figure 7 - PANA/DHCP: MN bootstrap
Any subsequent movement of the MN can be handled as depicted in
Figure 8. The procedure involves the following steps:
o after having attached to a new link, the MN has to repeat the
PANA authentication procedure;
Giaretta, et al. Expires April 14, 2006 [Page 25]
Internet-Draft NETLMM Protocol October 2005
o as part of the authorization phase, the AAA server verifies
whether the new AR (i.e. the PAA) is located within the same
LMMD from which the previous access took place. If this is the
case, the AAA server delivers to the new AR (through the NETLMM
AVP) the IP address that was previously allocated to the MN.
Otherwise, the AAA server allocates to the MN a new global
address valid within the new LMMD;
o the MN tries to keep the same IP address used in the previous
link sending a DHCP Confirm;
o at the reception of the DHCP Confirm, the AR verifies whether
the IP address claimed by the MN is the same received from the
AAA infrastructure. If this is the case, the AR activates the
NETLMM protocol, enables the address and delivers a successful
DHCP Reply to the MN.
+--+ +---+ +---+ +---+ +---+
|MN| |AR1| |AR2| |AAA| |HAR|
+--+ +---+ +---+ +---+ +---+
| | | | |
Moves | | | |
to AR2 | | | |
| /------------------------------\ | /------------\ | |
|/ PANA \|/ RADIUS or \| |
|\ session /|\ Diameter /| |
| \------------------------------/ | \------------/ | |
| | | | |
| DHCP Confirm (IP-MN) | | |
|--------------------------------->| | |
| | | /----------------------\ |
| | |/ NETLMM \|
| | |\ Protocol /|
| | | \----------------------/ |
| | +------------+ | |
| | |Enable IP-MN| | |
| DHCP Reply | +------------+ | |
|<---------------------------------| | |
| | | | |
Figure 8 - PANA/DHCP: mobility
Giaretta, et al. Expires April 14, 2006 [Page 26]
Internet-Draft NETLMM Protocol October 2005
9. Packets Formats
To be completed.
Giaretta, et al. Expires April 14, 2006 [Page 27]
Internet-Draft NETLMM Protocol October 2005
10. Security Considerations
Location Update and Location Acknowledgement messages MUST be
authenticated, integrity protected and optionally encrypted. IPsec
MUST be used between HAR and VAR to protect the protocol
signaling. The IPsec Security Associations shared by the ARs may
be configured manually or dynamically set-up. Moreover, as
mentioned in the draft, each IPsec Security Association can be
used for traffic related to any MN since it is not MN-specific.
This limits the number of SAs required by the protocol.
This document does not specify a protocol for the interface
between the Mobile Node and the Access Router. Some examples
(Neighbor Discovery and PANA/DHCPv6) to implement this interface
have been provided in this document but a deep security analysis
has not been performed.
Nonetheless, since any NETLMM solution implies that the MN does
not change its IP address while moving across Access Routers that
belong to the same LMMD, some generic issues related to MN-AR
interface may arise. In particular, the Activate message, that is
used by the MN
to trigger NETLMM protocol operation, MUST be authenticated.
Moreover, the Access Router must be sure that the IP address
provided by the MN in the Activate Message has not been spoofed
and is owned by the MN itself. Cryptographically Generated
Addresses may be useful for this purpose but a AAA-based solution
should be also investigated. It is worthwhile to mention that
these issues are not specific to this NETLMM protocol, but apply
to any NETLMM solution.
Giaretta, et al. Expires April 14, 2006 [Page 28]
Internet-Draft NETLMM Protocol October 2005
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., Simpson, W., Soliman, H.,
"Neighbor Discovery for IP version 6 (IPv6)", Internet-
Draft, draft-ietf-ipv6-2461bis-04, July 2005.
[3] Thomson, S., Narten, T., Jinmei, T., "IPv6 Stateless
Address Autoconfiguration", Internet-Draft, draft-ietf-
ipv6-rfc2462bis-08, May 2005.
11.2. Informative References
[4] Manner, J., Kojo, M., "Mobility Related Terminology", RFC
3753, June 2004.
[5] Arkko, J., Kempf, J., Zill, B., Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, M., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[8] 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.
[9] 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.
[10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[11] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[12] Soliman, H., Castelluccia, C., El Malki, K., Bellier, L.,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
RFC 4140, August 2005.
[13] Choi, J., Nordmark, E., "DNA solution framework", Internet-
Draft, draft-ietf-dna-soln-frame-00, April 2005.
Giaretta, et al. Expires April 14, 2006 [Page 29]
Internet-Draft NETLMM Protocol October 2005
[14] Narayanan, S., Daley, G., Montavont, N., "Detecting Network
Attachment in IPv6 - Best Current Practices for hosts",
Internet-Draft, draft-ietf-dna-hosts-01, June 2005.
[15] Choi, J., Nordmark, E., "DNA with unmodified routers:
Prefix list based approach", Internet-Draft, draft-ietf-
dna-cpl-01, April 2005.
[16] Moore, N., "Optimistic Duplicate Address Detection for
IPv6", Internet-Draft, draft-ietf-ipv6-optimistic-dad-05,
February 2005.
[17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., Yegin,
A., "Protocol for Carrying Authentication for Network
Access (PANA)", Internet-Draft, draft-ietf-pana-pana-10,
July 2005.
[18] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B.,
"Detecting Network Attachment in IPv6 Networks (DNAv6)",
Internet-Draft, draft-pentland-dna-protocol-01, July 2005.
Giaretta, et al. Expires April 14, 2006 [Page 30]
Internet-Draft NETLMM Protocol October 2005
12. Appendix A: Support for Route Optimization
The basic protocol operation described in the previous sections
may lead to sub-optimized routing paths, since data traffic
addressed to a MN connected to a Visited Access Router (VAR) is
always forwarded by the MN's Home Anchor Router (HAR). If the
Localized Mobility Management Domain (LMMD) is very large, such as
in the case of an LMMD spanning the whole network of an operator,
this sub-optimal routing may generate an unacceptable increase in
the end-to-end transfer latency as well as a significant waste of
network resources.
In order to solve these performance issues, the proposed protocol
architecture has been extended with a route optimization
procedure, that can be used to promptly switch to the shortest
routing path, limiting transit through HAR to the first few data
packets exchanged between MN and CN.
The performance improvements of the route optimization procedure
may depend on the network topology: if the HAR is not co-located
with an Access Router (as described in section 6.1) and a star
network topology is in place, it is possible that all packets are
routed to the HAR anyway and therefore the route optimization
procedure does not involve any performance improvement.
12.1. Basic Operation
The basic route optimization procedure is shown in Figure 9.
The first data packet transmitted from CN to MN is delivered using
standard IP routing and therefore gets to MN's HAR, which tunnels
it to MN's VAR. The need to perform forwarding through tunneling
is treated by MN's HAR as an explicit indication that the origin
of data traffic is not aware of the actual location visited by the
MN. This triggers the route optimization procedure.Inspecting the
source of received data packets, MN's HAR identifies the IP
address of the CN. This information is used to discover the edge
router that is injecting into the LMMD the data flow coming
from the CN. This edge router can be:
o the Access Router (AR) the CN is attached to, if the CN is an
internal node connected to the same LMMD of the MN (this is the
assumption made in the example of Figure 9),
o or a Border Gateway (BG), if the CN is a node located in an
external network.
How to carry out this discovery procedure is out of the scope of
the present specification. Possible technical approaches include:
Giaretta, et al. Expires April 14, 2006 [Page 31]
Internet-Draft NETLMM Protocol October 2005
o manual configuration on all ARs and BGs;
o wild-card search within a data-base maintaining the list of
available prefixes and correspondent HARs;
o exploitation of topology information advertised within the
routing protocol (e.g. iBGP, OSPF).
HAR or MN VAR of MN
+--+ +---+ +---+ +---+ +--+
|MN| |AR1| |AR2| |AR4| |CN|
+--+ +---+ +---+ +---+ +--+
| | | | |
| | First data packet from CN (no tunneling) |
| Triggers O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<~~~~~~~~~|
| delivery O Tunnel | | |
| or RU O===========>O | |
| | O | |
|<~~~~~~~~~~~~~~~~~~~~~~~O | |
| | | | |
| | Route Update (IP-CN,IP-MN,AR2) | Explicit |
| |------------------------------------->| ack. not |
| | | | needed |
| | | | |
| Plain data packets | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~|
| | | | |
Figure 9 - Route optimization: basic operation
After the identification of the edge router on the CN side (i.e.
the CN's AR, if the CN is located in the same LMMD of the MN, or
the CN BG, if the CN is located in an external network), MN's HAR
sends to it a Route Update (RU) message containing:
o the IP address of the CN that triggered the route optimization
procedure;
o the IP address of the host;
o the IP address of the current host's VAR (AR2 in the example of
Figure 9).
This Route Update message does not need to be explicitly
acknowledged, in that, in case it gets lost, retransmissions are
automatically triggered by the continuous arrival of non route
optimized data packets on MN's HAR.
At the reception of the RU message, the edge router on the CN side
stores its content in a local cache and begins to tunnel data
Giaretta, et al. Expires April 14, 2006 [Page 32]
Internet-Draft NETLMM Protocol October 2005
packets addressed to the MN directly to the MN's VAR (i.e. the
current visited location), thus restoring the shortest routing
path. This local cache is similar to the Binding Cache that Mobile
IPv6 correspondent nodes implement.
It is important to note that the location information contained in
the Route Update message can be applied to any CN willing to
establish a communication session with the MN, and not only to the
one that triggered the route optimization procedure on the host's
HAR. This approach has the following advantages:
o reduction of signaling overhead, since it is not necessary to
trigger the delivery of a fresh Route Update any time the MN
starts a new communication session. Instead, all the CNs
communicating with the MN through the same edge router can
share the location information included in the first Route
Update received from the MN's HAR;
o minimization of memory consumption on the edge routers, since
they are not required to maintain any specific state related to
the CN's the MN is communicating with.
In case the CN is a mobile host, by just inspecting the source of
received data traffic the MN's HAR can discover CN's HAR, but
cannot figure out whether the CN is at home or attached to a VAR.
Therefore as shown in Figure 10, the MN's HAR always sends the
Route Update message to the CN's HAR. If the CN happens to be
visiting a VAR, the CN's HAR looks up the actual location of the
correspondent node in its Location Cache (LC) and immediately
forwards the Route Update received from the MN's HAR to the CN's
VAR. This allows to complete the route optimization procedure
regardless of the actual position of the CN and without the need
to disclose it to the MN's HAR.
MN's HAR retransmits Route Update messages at regular intervals,
in order to refresh location information on the receiving party.
Edge routers are expected to immediately remove any Route
Optimization state related to the MN at the expiration of its
lifetime. This causes the restoration of traffic routing through
the MN's HAR (i.e. anchor-based routing).
Giaretta, et al. Expires April 14, 2006 [Page 33]
Internet-Draft NETLMM Protocol October 2005
HAR or MN VAR of MN HAR of CN VAR of CN
+--+ +---+ +---+ +---+ +---+ +--+
|MN| |AR1| |AR2| |AR4| |AR5| |CN|
+--+ +---+ +---+ +---+ +---+ +--+
| | | | | |
| | First data packet from CN (no tunneling) |
| Triggers O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<~~~~~~~~~|
| delivery O Tunnel | | | |
| or RU O===========>O | | |
| | O | | |
|<~~~~~~~~~~~~~~~~~~~~~~~O | | |
| | | | | |
| | RU (IP-CN,IP-MN,AR2) | | |
| |------------------------>| | |
| | | +------+ | |
| | | |Lookup| | |
| | | |in LC | | |
| | | +------+ | |
| | | | | |
| | | RU (IP-CN,IP-MN,AR2) |
| | | |----------->| |
| | | | | |
| Plain data packets | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~|
| | | | | |
Figure 10 - Route optimization: mobile CN roaming in a VAR
12.2. Management of host movements
In order not to break route optimization any time the host moves
to a new location, the MN's HAR proactively re-transmits Route
Update messages whenever it receives a Location Update showing
that the MN has attached to a new VAR (see Figure 11).For that
purpose, the host's HAR is required to keep a local cache listing
all the CNs that have triggered route optimization towards the MN.
This cache is similar to the Binding Update List that a Mobile
IPv6 Mobile Node must implement for route optimization operation.
Giaretta, et al. Expires April 14, 2006 [Page 34]
Internet-Draft NETLMM Protocol October 2005
HAR or MN Old VAR New VAR
+--+ +---+ +---+ +---+ +---+ +--+
|MN| |AR1| |AR2| |AR3| |AR4| |CN|
+--+ +---+ +---+ +---+ +---+ +--+
| | | | | |
| Plain data packets | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~|
Moves | | | | |
to AR3 | | | | |
| Activate (IP-MN) | | |
|------------------------------------>| | |
| | | | | |
| | LU (IP-MN,AR3) | | |
| |<------------------------| | |
| | | | | |
| | LA | | | |
| |------------------------>| | |
| | | | | |
| | Route Update (IP-CN,IP-MN,AR3) | |
| |------------------------------------->| |
| | | | | |
| Plain data packets | | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<===========O<~~~~~~~~~|
| | | | | |
Figure 11 - Route optimization: management of MN movements
The MN's HAR stops proactive re-transmission of Route Update
messages for a specific CN when it discovers that the
communication session between MN and CN is terminated. Since with
route optimization in place MN's HAR is not traversed by data
traffic, this is done under explicit indication of the edge router
on the CN side (i.e. AR or BG), that is required to continuously
monitor the traffic exchanged with the MN.
When the time elapsed since the last data packet sent to the MN,
or received from the MN, overcomes a certain activity threshold,
the edge router on the CN side replies to the Route Update with a
Route Acknowledgement indicating that there are no on-going
communications with the MN. At the reception of such an
indication, the MN's HAR immediately stops the delivery of
unsolicited RUs towards that edge router, and removes from its
local cache all the state related to the CN.
12.3. Recovery from error conditions
When operating in route optimization, the location information
stored on the CN's edge router may happen to become outdated. In
this case, data traffic generated by the CN gets erroneously
tunneled to a VAR where the MN is no longer present.
Giaretta, et al. Expires April 14, 2006 [Page 35]
Internet-Draft NETLMM Protocol October 2005
This routing anomaly may occur at least in the following cases:
o the MN moves to a new location but the proactive Route Update
(RU) message sent by MN's HAR gets lost (as shown in the
example of Figure 12). In this case, the CN's edge router
continues to tunnel data packets to the old VAR, since it
cannot detect that the MN has left it;
o route optimization on a specific edge router has been triggered
by a CN that afterwards has moved to a new location. In this
case the MN's HAR stops delivering proactive Route Update
messages to that edge router, whose location state may
therefore become outdated if the MN changes its point of
attachment. As a consequence, if a new CN starts communicating
with the MN from that edge router before the expiration of its
outdated route optimization state, data traffic gets
erroneously delivered to the old MN's VAR.
The solution that has been designed to recover from this routing
anomaly is shown in Figure 12. If a VAR (AR2 in the example)
receives tunneled data packets addressed to a MN that has moved
away, it decapsulates the packets and forwards them using standard
IP routing. As a consequence, the traffic gets to the MN'HAR that,
after tunneling it to the right VAR, triggers the route
optimization procedure. This involves the immediate delivery of
fresh Route Update towards the CN's edge router, which causes it
to adjust its route optimization state, thus recovering the
shortest routing path.
This approach ensures that data traffic sent from CN to MN is
always delivered to the destination, even when outdated route
optimization state is stored on some edge routers. The drawback is
that for short transition periods the routing path followed by
data packets may become sub-optimized, causing additional jitter
and, depending on network topology and transfer delays, potential
out of sequence delivery.
Giaretta, et al. Expires April 14, 2006 [Page 36]
Internet-Draft NETLMM Protocol October 2005
VAR or MN Old VAR New VAR
+--+ +---+ +---+ +---+ +---+ +--+
|MN| |AR1| |AR2| |AR3| |AR4| |CN|
+--+ +---+ +---+ +---+ +---+ +--+
| | | | | |
| Plain data packets | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~|
Moves | | | | |
to AR3 | | | | |
| Activate (IP-MN) | | |
|------------------------------------>| | |
| | LU (IP-MN) | | |
| |<------------------------| | |
| | LA | | | |
| |------------------------>| | |
| | | | | |
| | RU (IP-MN,IP-CN,AR3) | | |
| |------------------------------->X | |
| | | | RU does | |
| | Move Notify| | not get | |
| |----------->| | to AR4 | |
| | Move Ack. | | | |
| |<-----------| AR4 continues to | |
| | | tunnel packets to AR2 | |
| Triggers O<~~~~~~~~~~~O<========================O<~~~~~~~~~|
| delivery O | | | |
| of RU O========================>O | |
| | | O | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O | |
| | | | | |
| | RU (IP-MN,IP-CN,AR3) | | |
| |------------------------------------->| |
| | | | | |
| Plain data packets | Tunnel | |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<===========O<~~~~~~~~~|
| | | | | |
Figure 12 - Route optimization: recovery from loss of RU
Giaretta, et al. Expires April 14, 2006 [Page 37]
Internet-Draft NETLMM Protocol October 2005
Authors' Addresses
Gerardo Giaretta
Telecom Italia Lab
via Reiss Romoli 274
10148 Torino
Italy
Phone: +39 011 228 6904
Email: gerardo.giaretta@tilab.com
Ivano Guardini
Telecom Italia Lab
via Reiss Romoli 274
10148 Torino
Italy
Phone: +39 011 228 5424
Email: ivano.guardini@tilab.com
Elena Demaria
Telecom Italia Lab
via Reiss Romoli 274
10148 Torino
Italy
Phone: +39 011 228 5403
Email: elena.demaria@tilab.com
Giaretta, et al. Expires April 14, 2006 [Page 38]
Internet-Draft NETLMM Protocol October 2005
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Giaretta, et al. Expires April 14, 2006 [Page 39]
