Per-Host Locators for Distributed Mobility Management
draft-liebsch-mext-dmm-nat-phl-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Marco Liebsch | ||
| Last updated | 2011-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liebsch-mext-dmm-nat-phl-00
MEXT Working Group M. Liebsch
Internet-Draft NEC
Intended status: Standards Track October 25, 2011
Expires: April 27, 2012
Per-Host Locators for Distributed Mobility Management
draft-liebsch-mext-dmm-nat-phl-00.txt
Abstract
Mobile operators consider the distribution of mobility anchors to
enable offloading some traffic from their core network. In scope of
a solution for Distributed Mobility Management is the maintenance of
IP sessions and IP address continuity when mobile nodes get a new
mobility anchor assigned during handover. This document proposes the
use of identifier-locator split concepts to achieve optimal routing
of data packets to a mobile node's current mobility anchor. The use
of per-host locator IP addresses allows translation of addresses
within the mobile operator network to route packets to the mobile
node's current mobility anchor, while address translation is kept
transparent to the communication endpoints.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 27, 2012.
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
Liebsch Expires April 27, 2012 [Page 1]
Internet-Draft DMM per-host locator October 2011
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 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Routing Plane Considerations of DMM . . . . . . . . . . . . . 5
4. Use of NATs and per-host locators . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Liebsch Expires April 27, 2012 [Page 2]
Internet-Draft DMM per-host locator October 2011
1. Introduction
The concept of Distributed Mobility Management (DMM) in based on the
distribution of mobility anchors towards the access networks to
provide mobile nodes with local anchors and enable optimal routing of
traffic above anchor level to any kind of serving point, e.g.
distributed content caches. The closer mobility anchors are located
to mobile nodes, the more a mobile node's handover may necessitate
the assignment of a new mobility anchor. Continuity of a mobile
node's IP address or IP address prefix enables IP session continuity,
but creates the problem of routing downlink packets to the mobile
node's current mobility anchor. Different solutions and associated
extensions to IP mobility management protocols are being considered
to maintain a mobile node's IP session after mobility anchor
relocation.
The solution for DMM as described in this document adopts the concept
of an identifier-locator split to solve the routing above anchor
level and enable optimal routes to the mobile node's current mobility
anchor. Whereas the mobile node's Home Network Prefix (HNP) or Home
Address is treated solely as identifier after mobility anchor
relocation, the mobile node's current mobility anchor represents the
locator. The proposed solution assumes an Ingress Router (IR) which
resolves the MN's identifier into a locator address. The mobile
node's current mobility anchor serves as Egress Router (ER).
Instead of using encapsulation to tunnel packets between an IR and
the ER, per-host locator addresses are used to address translate
downlink packets at the IR(s) and route packets to the mobile node's
anchor. Locator addresses are overloaded to carry identifier
information, which allows the ER to reverse address translate the
packet's destination address into the mobile node's identifier (HNP
or Home Address) as assigned by the initial mobility anchor.
Liebsch Expires April 27, 2012 [Page 3]
Internet-Draft DMM per-host locator October 2011
2. Conventions and Terminology
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 [RFC2119].
Liebsch Expires April 27, 2012 [Page 4]
Internet-Draft DMM per-host locator October 2011
3. Routing Plane Considerations of DMM
The problem of routing downlink packets to the mobile node's current
mobility anchor after anchor relocation is depicted in Figure 1. The
MN initially attaches to a Mobility Anchor (MA) and gets assigned an
HNP from this MA's prefix pool in case Proxy Mobile IPv6 is used as
mobility management protocol below MAs. In case Mobile IPv6 is used,
the initial MA assigns a Home Address to the MN. In the following
description, PMIPv6 is assumed, whereas the proposed solution for DMM
is independent of the mobility management protocol. The MN's initial
anchor is denoted as previous MA (pMA), whereas the new anchor is
denoted as new MA (nMA)
The following symbolic notation of IP addresses is used: [Prefix]::
[Suffix].
+--+
|CN|
+--+
:
:data, dest. address A:1::1
:
V ?? Mobile Operator
Routing Plane
PFX A:x:: PFX B:x::
+----+ +----+
|pMA | |nMA |
+----+ +----+
|pAR/| |nAR/|
|pMAG| |nMAG|
+----+ +----+
. /
. +--+ /
. |MN|/
+--+
A:1::1
Figure 1: Issue of routing downlink packets after mobility anchor
relocation
The initial anchor pMA assigns the prefix A:1:: to the MN as a result
of the MN's registration. Routers in the mobile operator's core
network forward all packets with prefix (PFX) A:x:: towards pMA. As
a result of handover, the MN gets a new mobility anchor (nMA)
assigned. In case nMA continues anchoring the MN's initially
Liebsch Expires April 27, 2012 [Page 5]
Internet-Draft DMM per-host locator October 2011
assigned IP address prefix, the DMM solution must enable forwarding
of downlink packets to the nMA instead of following the default
routing states, which forward all A:x:: prefixes to the pMA.
Forwarding of packets from the pMA to the nMA may imply suboptimal
routes from the CN.
Figure 2 depicts the generic concept of using an Ingress Router (IR)
to resolve the MN's HNP into the associated locator address, which is
represented by the MN's current MA (nMA). The mechanism to resolve
the locator is out of scope of this version of the document. As the
nMA serves as locator and ER, the IR can set up a forwarding tunnel
to the ER. The inner packet carries the MN's identifier, which
allows forwarding of the packet after decapsulation of the tunnel at
the ER according to the mobility management protocol supported by the
nMA.
+--+
|CN|
+--+
:
:data, dest. address A:1::1
:
V
+--+
|IR|
+--+ A:1::1 is identifier, B:254::254 is locator
||
==================|| host route between IR and ER
||
||
VV
+----+ +------+
A:254::254|pMA | |nMA/ER| B:254::254
+----+ ++----++
|pAR/| |nAR/|
|pMAG| |nMAG|
+----+ +----+
. /
. +--+ /
. |MN|/
+--+
A:1::1
Figure 2: Identifier-Locator split to solve DMM on the routing plane
to enable IP address continuity after anchor relocation
Liebsch Expires April 27, 2012 [Page 6]
Internet-Draft DMM per-host locator October 2011
Since the IR can be topologically far away from the nMA, the solution
described in this document is based on address translation instead of
using encapsulation between the IR and the ER.
Liebsch Expires April 27, 2012 [Page 7]
Internet-Draft DMM per-host locator October 2011
4. Use of NATs and per-host locators
Translation of the MN's IP address into the locator address (pMA)
implies loosing identifier information, which results in an issue at
the ER to reverse address translate the MN's downlink packets into
the associated identifier address (HNP, Home Address). Hence, the
proposed solution is based on per-host locators instead of referring
to the nMA's IP address as locator. Building the per-host locator is
intrinsically supported by MAs for IP mobility management and are
represented by the HNP or the Home Address respectively.
At the nMA, the initially assigned address serves as identifier
(HNP_id), whereas the nMA assigns a new HNP to the MN after
registration, which is treated as per-host locator (HNP_loc). The
HNP_loc is not advertised to the MN for address configuration, but
provided to a mapping system, which enables IRs to resolve the HNP_id
into an HNP_loc. The description of the mapping system is out of
scope of the current version of this document. Figure 3 illustrates
NATing the downlink packet's destination address at the IR into the
HNP_loc. According to local binding information, the nMA can reverse
address translate the packet into the original IP address of the MN,
which carries the HNP_id prefix. Further forwarding from the nMA is
performed according to the used mobility management protocol.
Liebsch Expires April 27, 2012 [Page 8]
Internet-Draft DMM per-host locator October 2011
+--+
|CN|
+--+
:
:data, dest. address A:1::1
:
V
+--+---+
|IR|NAT|--------------+
+--+---+ |data, dest. address B:1::1
|
|
|
V
+----+
MN's BCE@pMA: |NAT | MN's BCE@nMA:
HNP A:1:: +----+ ++----++ HNP_id A:1::
|pMA | |nMA/ER| HNP_loc B:1::
+----+ ++----++
|pAR/| |nAR/|
|pMAG| |nMAG|
+----+ /+----+
. /
. +--+ /
. |MN|/
+--+
A:1::1
Figure 3: Using per-host locators to enable reverse NAT on the MN's
current mobility anchor (nMA)
Liebsch Expires April 27, 2012 [Page 9]
Internet-Draft DMM per-host locator October 2011
5. Security Considerations
Secure inter-working between with the mapping system must be
established to avoid entering addresses of a malicious node as
HNP_loc.
Liebsch Expires April 27, 2012 [Page 10]
Internet-Draft DMM per-host locator October 2011
6. IANA Considerations
So far no need for IANA actions has been identified.
Liebsch Expires April 27, 2012 [Page 11]
Internet-Draft DMM per-host locator October 2011
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Liebsch Expires April 27, 2012 [Page 12]
Internet-Draft DMM per-host locator October 2011
Author's Address
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
D-69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@neclab.eu
Liebsch Expires April 27, 2012 [Page 13]