Network Working Group Hongke Zhang
Internet Draft Feng Qiu
Expires: March 2013 Huachun Zhou
Xiaoqian Li
Fei Song
September 4, 2012
A Distributed Mobility Management Solution in LISP networks
draft-zhang-dmm-lisp-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 March 4, 2013.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Zhang et al. Expires March 4, 2013 [Page 1]
Internet-Draft dmm-lisp September 2012
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
In traditional Internet architectures, current centralized mobility
management solutions face scalability issues due to the creation of
network bottlenecks and a single mobility agent of failures. To
address these issues, we propose a Distributed Mobility Management
solution in Locator/ID Separation Protocol (DMMLISP). We divide the
network into many domains according to the area of Autonomous
Systems (ASs). Each domain consists of a Mapping Server and several
Tunnel Routers (xTRs). The Mapping Server stores global mappings
between EID (Endpoint Identifier) prefixes and AS Numbers (ASNs) to
lookup the mobile nodes'(MNs') home domain. Meanwhile, the Mapping
Server also contains ASN-to-xTR mappings so that it can forward Map-
Register and Map-Request messages to any xTR of the MN's home domain,
thus enhancing reliability. In addition, the xTRs in each domain
constitute one-hop DHT (Distributed Hash Table). Moreover, any xTR
in the MN's home domain may be the home agent of MNs, and the MNs'
EID-to-RLOC (Routing Locator) mapping is stored in two xTRs using
two hash functions. In this way, it not only supports quick lookup
but also improves scalability and survivability.
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 0.
Table of Contents
1. Introduction ................................................ 3
2. Definition of items ......................................... 4
3. A distributed mobility management in LISP networks ...........6
3.1. The architecture of DMMLISP .............................6
3.2. Host mobility .......................................... 8
3.3. Call delivery procedure................................. 9
4. Properties of DMMLISP .......................................10
4.1. Optimize path ......................................... 10
4.2. Split the signaling and the data .......................10
4.3. Improve survivability.................................. 10
4.4. Hide location information of MNs .......................11
4.5. Network-based mobility management ......................11
4.6. Support routing scalability ............................11
Zhang et al. Expires March 4, 2013 [Page 2]
Internet-Draft dmm-lisp September 2012
5. Security Considerations..................................... 11
6. IANA Considerations ........................................ 11
7. Acknowledgments ............................................ 11
8. References ................................................. 12
Author's Addresses ............................................ 12
Acknowledgment ................................................ 13
1. Introduction
The conventional Internet does not natively support mobility because
IP addresses are used as both host identifiers and locators. Many
solutions based on the current Internet have been specified to
support mobility. Mobile IPv6 (MIPv6) [MIPv6] as a host-based
mobility protocol requires that an MN uses a Home Address (HoA) to
indicate its identifier and a Care of Address (CoA) to represent its
location information. A home agent (HA) as a location manager
maintains HoA-to-CoA mappings and takes charge of forwarding data
traffic for MNs. Proxy Mobile IPv6 (PMIPv6) [PMIPv6] is a network-
based mobility protocol in which a Local Mobility Anchor (LMA)
provides a prefix for an MN as its identifier. The IP address of a
Mobile Access Gateway (MAG) is used as the location of an MN, and
the LMA keeps the mapping between the MN's prefix and the serving
MAG address. In this way, whenever mobility events occur, the HoA or
the MN's prefix is unchanged, so it can keep transport connections
alive.
However, a HA and a LMA can be viewed as centralized mobility agents.
All traffic to MNs associated with the HA or the LMA is routed
through their agent. Such a centralized mobility solution has some
issues [Problem-dmm]. First, when a single mobility agent generally
serves a large number of MNs, it becomes a potential bottleneck
because all the traffic from and towards an MN has to go through the
centralized mobility agent. Second, a centralized mobility agent
often results in a non-optimal path. An MN and a correspondent node
(CN) may be close to each other but be both far from the mobility
agent. Packets destined to the MN need to be forwarded via the
mobility agent, which is not the shortest path. If the CoA of an MN
is given to the CN in MIPv6 Route Optimization (RO) mode, the
location privacy of the MN will be not protected. And we can not
expect RO capabilities to exist at each CN. Third, malicious MNs can
attack HAs or LMAs directly (e.g. MNs send a large mount of data
traffic), so it can bring insecure factors and a single point of
failures is more vulnerable. Finally, the current Internet faces
serious scaling problems. MIPv6 and PMIPv6 which develop based on
the traditional TCP/IP are not suitable for an increasing demand for
future Internet scalability.
Zhang et al. Expires March 4, 2013 [Page 3]
Internet-Draft dmm-lisp September 2012
To address the above issues, we propose a Distributed Mobility
Management in Locator/ID Separation Protocol (DMMLISP), which can
improve scalability and survivability of the network. When an MN
crosses different subnets, it only changes its RLOC but its EID used
by the transport layer's connection is invariable, so it can offer
services connectivity and support global roaming [MILSA]. A Tunnel
Router (xTR) receives packets from sites on one side [LISP] and
encapsulates them with RLOCs toward the Internet on the other side,
so routers in the core networks only need to maintain RLOCs, which
addresses routing scalability problems [Report-RoutingAddressing].
Meanwhile, we separate the signaling and data planes by introducing
the mapping system as an overlay architecture to deliver signaling
messages, which avoids evil MNs attacking map servers (MSs) [LISP-MS]
directly. In addition, we divide the Internet into different domains
according to the coverage area of Autonomous Systems (ASs). Each
domain is managed by an MS who takes charge of forwarding Map-
Request and Map-Register messages for xTRs by storing the global
EID-prefix-to-ASN (AS number) and ASN-to-xTR mappings. In this way,
even if one MS break down, other MSs can substitute it.
In addition, xTRs are distributed in different sites so that packets
may be routed via a nearby router. In this way, all the data between
two xTRs near to hosts can be transited on the shortest path. Hence,
it can help reduce the delay and overhead. Meanwhile, the xTRs in
each domain constitute one-hop DHT (Distributed Hash Table). We
store the MN's EID-to-RLOC mappings in two xTRs, avoiding a single
point of failures.
2. Definition of items
Autonomous System (AS): Within the Internet, an autonomous system is
a collection of connected IP routing prefixes under the control of
one or more network operators that presents a common, clearly
defined routing policy to the Internet.
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6)
value used in the source and destination address fields of the
first (most inner) LISP header of a packet. An EID is allocated to
a host from an EID-prefix block associated with the site where the
host is located. See [LISP] for details.
Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an
egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC
mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs
Zhang et al. Expires March 4, 2013 [Page 4]
Internet-Draft dmm-lisp September 2012
are numbered based on the connectivity of provider networks. See
[LISP] for details.
EID-prefix: An EID-prefix is a power-of-two block of EIDs which are
allocated to a site by an address allocation authority. EID-prefix
allocations can be broken up into smaller blocks when an RLOC set
is to be associated with the smaller EID-prefix.
EID-to-RLOC mapping: a binding between an EID or EID-prefix and a
RLOC set which can be used to reach the EID. The xTRs can
encapsulate packets with the RLOC in the EID-to-RLOC mapping to
reach the destination EID. A RLOC set may contain multiple RLOCs to
perform multihoming or traffic engineering.
Ingress Tunnel Router (ITR): An ITR accepts an IP packet and prepends
an "outer" header with RLOCs. It sends a Map-request to the mapping
system when it does not have the EID-to-RLOC mapping for the
destination EID.
Egress Tunnel Router (ETR): An ETR accepts packets with the RLOCs as
the destination addresses. It strips the outer header and forwards
packets based on EIDs.
xTR: A xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. xTR refers to the
router that is the tunnel endpoint.
Mapping Server (MS): A Mapping Server is a component, which stores
the EID-prefix-to-ASN and ASN-to-xTR mappings. The MS forwards Map-
Register or Map-Request messages to xTRs.
Mapping Domain (MD): This document defines the area that a Mapping
Server covers as a Mapping Domain.
EID-prefix-to-ASN mapping: It indicates which AS EID-prefix belongs
to.
ASN-to-xTR mapping: A binding between ASN and the xTR, which is one-
to-many relationship.
Zhang et al. Expires March 4, 2013 [Page 5]
Internet-Draft dmm-lisp September 2012
3. A distributed mobility management in LISP networks
3.1. The architecture of DMMLISP
+-------------------------------------------------+
| Mapping +----+ +----+ |
| System | MS |------------ | MS | |
| +----+ +----+ |
| | | |
| | | |
| +----+ +----+ |
| | MS |------------ | MS | |
| +----+ +----+ |
| / \ |
| ----------/----------------------\------------- |
| MD1 / | MD2 \ |
| +----+ +----+ | +---+ +---+ |
| -|HxTR|----|DxTR|-- | --|xTR|----|xTR|-- |
| |+----+ +----+ | | | +---+ +---+ | |
| | | | | | |
|+----+ +---+ | +---+ +---+ |
||HxTR| |xTR| | |xTR| |xTR| |
|+----+ +---+ | +---+ +---+ |
| | | | | | |
| | +---+ +----+ | | |+----+ +----+ | |
| --|xTR|---|xTR1|-- | -|xTR2|---|CxTR|-- |
| +---+ +----+ | +----+ +----+ |
| | | | |
| +----+ | +----+ |
| | MN | | | CN | |
| +----+ | +----+ |
| | |
+-------------------------------------------------+
Figure 1 :Architecture of DMMLISP
Figure 1 shows the architecture of DMMLISP, which is divided into
different domains according to the coverage area of the AS. Each
domain is managed by an MS who stores EID-prefix-to-ASN and ASN-to-
xTR mappings. All the xTRs in the same AS constitute one-hop DHT and
maintain EID-to-RLOC mappings.
Each xTR collects local EID-prefixes and notifies these prefixes to
the associated MS. MSs advertise their EID-prefix-to-ASN mappings
each other through BGP (Border Gateway Protocol) extension, so each
MS can know global EID-prefixes. In this way, it is possible to
aggregate local prefixes efficiently in an AS so that it can
alleviate the stored overload in the MS. Moreover, the change of the
Zhang et al. Expires March 4, 2013 [Page 6]
Internet-Draft dmm-lisp September 2012
topology within an AS does not impact on the mappings between EID-
prefix-to-ASN mappings in other MSs. Thus, the mapping system is
more scalability and stable.
In addition, the MS also maintains the ASN-to-xTR mappings, which is
one-to-many relationship. When the MS receives Map-Register or Map-
Request messages, it randomly selects one of xTRs as the destination
xTR (DxTR) and forwards these messages to the DxTR. Even if the DxTR
fails, any other xTRs in the destination AS can replace it by
reselecting other DxTRs. Hence, it enhances the survivability of
DMMLISP.
There are two ways to replace a broken MS. One way is that MSs use
BGP (Border Gateway Protocol), which entablishes on TCP. If one MS
breaks down, the peer MS can detect that the TCP connection is
broken and replaces the broken MS. Because each MS maintains ASN-to-
xTR mappings, the peer MS can notify all the xTRs in the AS of the
broken MS. In this way, the MS can replace the broken MS. Another
way is we replicate an MS in each AS. One MS is primary and the
other is for backup.
We deploy one-hop DHT ring in each AS. Any xTRs in the DHT ring may
be the agent of MNs, which inherits the advantages on scalability
and robustness of the DHT-based infrastructure. We store the MN's
EID-to-RLOC mapping in two xTRs. The DxTR uses different hash
functions to map the MN's EID to two home xTRs (HxTR) in order to
avoid a single point of failures. Hence, it can enhance the
survivability of the mobile network. The operations in detail are
described in the following sections.
Zhang et al. Expires March 4, 2013 [Page 7]
Internet-Draft dmm-lisp September 2012
3.2. Host mobility
+--+ +----+ +----+ +--+ +----+ +----+ +----+
|MN| |xTR1| |xTR2| |MS| |DxTR| |HxTR| |CxTR|
+--+ +----+ +----+ +--+ +----+ +----+ +----+
| |-handover->| | | | |
|<--1-Attachment---->| | | | |
| | | 2 Map- | | | |
| | |Register->| | | |
| | | |3 Map- | | |
| | | |Register->| | |
| | | | |4 Map- | |
| | | | |Register->| |
| | 5 Map- | | | | |
| | <-Update- | | | | |
| | | | | | |
| |-------------------6 Map--Update-------------------->|
| | | | | | |
Figure 2 : Host Mobility Scenario
Fig. 2 illustrates the message flows for host mobility. When an MN
moves from the coverage area of the xTR1 to the xTR2, it connects to
the xTR2 (Message 1). Then, the xTR2 checks whether the EID belongs
to its local AS or not. If yes, it indicates that this AS is the
home domain of the MN. The xTR2 hashes the EID to find its HxTR and
updates the MN's EID-to-RLOC mapping in the HxTR. If not, it
indicates that the MN has left its home domain, the xTR2 sends a
Map-Register message to its local MS (Message 2).
Each MS stores two tables: an EID-prefix-to-ASN table and an ASN-to-
xTR table. When receiving a Map-Register message, the MS lookups the
EID-prefix-to-ASN table to obtain the MN's home AS number. Then, it
lookups the ASN-to-xTR table and randomly chooses one xTR as the
DxTR. After that, the MS forwards the Map-Register message to the
DxTR (Message 3).
Once receiving the Map-Register message, the DxTR uses the MN's EID
as a key and hashes it in order to obtain the MN's HxTR. The HxTR
stores the mapping between the EID and the RLOC. To improve the
survivability of the system, we use two Hash functions and store the
EID-to-RLOC mapping in two HxTRs (Message 4). Even if one HxTR
breaks down, the other can replace it and respond to the Map-Request
message.
In addition, the xTR2 sends a location update message to the xTR1
(message 5) including the new MN's EID-to-RLOC mapping. Then, xTR1
sends a message to the correspondent's xTRs (CxTR) in order to
Zhang et al. Expires March 4, 2013 [Page 8]
Internet-Draft dmm-lisp September 2012
update the new MN's mapping information in the CxTR's mapping table
(message 6). Once the CxTR obtains the new mapping, packets destined
to the MN are directly forwarded to the xTR2, so that it is not
necessary to pass through the old xTR1. Thus, the scheme can achieve
route optimization.
3.3. Call delivery procedure
Fig. 3 illustrates the message flows for the call delivery procedure.
When a CN wants to communicate with an MN, it sends packets to the
CxTR using its EID and the MN's EID as the packets's source address
and destination address (Message 1). The CxTR checks whether the EID
belongs to the local AS. If the MN's home domain and the CxTR are
different, the CxTR sends a Map-Request message to the associated MS
(Message 2). The MS lookups the EID-prefix-to-ASN table and obtains
the home AS of the MN. Then, the MS lookups the ASN-to-xTR table in
order to find one of its home domain's DxTRs, and forwards the Map-
Request message to the DxTR (Message 3). If the MS does not receive
the response message of the DxTR, it will choose another DxTR and
send the Map-Request message to the DxTR. As long as one DxTR of the
MN's home domain is active, the signalling can be forwarded to the
DxTR. In this way, the survivability of the system is enhanced.
The DxTR randomly selects one of two hash functions to find the MN's
HxTR and then forwards the Map-Request message to it (Message 4).
The HxTR responds to a Map-Reply Message including the EID-to-RLOC
mapping to the CxTR (Message 5). Then, the CxTR encapsulates packets
with RLOCs and sends them to the xTR which the MN attaches to. When
receiving packets, the xTR of the MN strips the encapsulated header
and forwards them to the MN (Message 6).
Zhang et al. Expires March 4, 2013 [Page 9]
Internet-Draft dmm-lisp September 2012
+--+ +----+ +---+ +----+ +--+ +----+ +----+
|MN| |xTR2| |HTR| |DxTR| |MS| |CxTR| | CN |
+--+ +----+ +---+ +----+ +--+ +----+ +----+
| | | | | | |
| | | | | |1<=Packets=|
| | | | | | |
| | | | | 2 Map- | |
| | | | |<-Request| |
| | | | 3 Map- | | |
| | | |<-Request| | |
| | | 4 Map- | | | |
| | |<-Request | | | |
| | |---------5 Map--Reply-------->| |
| | | | | | |
|6 <=====|<===============Packets===================| |
Figure 3 : Call delivery procedure
4. Properties of DMMLISP
4.1. Optimize path
In PMIPv6 and MIPv6, the LMA or the HA is required to deliver data
packets and they as location managers need to encapsulate packets.
In DMMLISP, xTRs are distributed in different access networks so
that data packets may be routed via a nearby xTR without passing
through MSs. In this way, compared to PMIPv6 and MIPv6, there is not
an extra encapsulated overhead on location managers. Moreover, the
data transmission delay can be reduced.
4.2. Split the signaling and the data
The mapping system as an overlay architecture on the top of the
Internet is used to deliver signaling messages. The mapping system
consists of many MSs who manage mobility-related signaling.
Meanwhile, the locator/ID separation avoids evil MNs sending a great
many data to MSs. Thus, it can offer better controllability,
manageability and security.
4.3. Improve survivability
Each MS stores the global EID-prefix-to-ASN mappings. In this way,
even if one MS breaks down, other MSs can replace its function to
Zhang et al. Expires March 4, 2013 [Page 10]
Internet-Draft dmm-lisp September 2012
forward Map-Request and Map-Register messages. In addition, we store
the MN's EID-to-RLOC mapping in two HxTRs via two hash functions, so
the HxTR is also alternative. Thus, our scheme can enhance the
survivability of DMMLISP.
4.4. Hide location information of MNs
In LISP networks, a CN only knows the MN's identifier but location
information of the MN is hidden to the CN, which avoids malicious
CNs attacking MNs directly.
4.5. Network-based mobility management
The MN is not required to participate in any mobility-related
signaling, so the proposed scheme avoids a part of signaling
overhead in wireless links and makes use of wireless resources
efficiently. Moreover, our network-based mobility management
solution does not require any modification on the MNs.
4.6. Support routing scalability
One of aims for the Locator/ID separation solution is to support
routing scalability by removing hosts' EIDs from core routers in the
current routing system. After packets which are sent by a host
arrive at an xTR, they are encapsulated with RLOCs and then are
forwarded to its destination xTR. We design a distributed mobility
management solution based on LISP which does not damage the
architecture and can solve both global routing scalability problems
and mobility support.
5. Security Considerations
TBD
6. IANA Considerations
This document makes no request of the IANA.
7. Acknowledgments
Zhang et al. Expires March 4, 2013 [Page 11]
Internet-Draft dmm-lisp September 2012
8. References
[MIPv6] D. Johnson, C. Perkins, J. Arkko, Mobility Support in
IPv6, RFC 3775, 2004.
[PMIPv6] Sri G, Kent L, Vijay D, Kuntal C, Basavaraj P. Proxy
Mobile IPv6, RFC 5213, 2008.
[LISP] Dino F, Vince F, Dave M, Darrel L, Locator/ID Separation
Protocol (LISP), Internet draft, draft-ietf-lisp-22, February 2012.
[Problem-dmm] H Anthony C. Requirements of Distributed Mobility
Management, IETF Internet draft-chan-dmm-requirements-00, 2012.
[MILSA] Jianli P, Raj J, Subharthi P, Chakchai S. MILSA: A New
Evolutionary Architecture for Scalability, Mobility, and Multihoming
in the Future Internet, IEEE Journal on Selected Areas in
Communications, 2010;28(8):1344-1361.
[Report-RoutingAddressing] David M, Lixia Z, Kevin F. Report from
the IAB Workshop on Routing and Addressing, IETF RFC 4984, 2007.
[LISP-MS] Vince F, Dino F. LISP Map Server Interface, IETF
Internet draft-ietf-lisp-ms-16, 2012.
Author's Addresses
Hongke Zhang, Feng Qiu, Huachun Zhou, Xiaoqian Li, Fei Song
National Engineering Laboratory for Next Generation Internet
Interconnection Devices
School of Electronics and Information Engineering
Beijing Jiaotong University of China
Phone: +86 01051685677
hkzhang@bjtu.edu.cn
07111019@bjtu.edu.cn
hczhou@bjtu.edu.cn
Zhang et al. Expires March 4, 2013 [Page 12]
Internet-Draft dmm-lisp September 2012
xiaoqianli@bjtu.edu.cn
fsong@bjtu.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires March 4, 2013 [Page 13]