Internet DRAFT - draft-liebsch-mext-dmm-nat-phl
draft-liebsch-mext-dmm-nat-phl
DMM Working Group M. Liebsch
Internet-Draft NEC
Intended status: Standards Track October 22, 2012
Expires: April 25, 2013
Per-Host Locators for Distributed Mobility Management
draft-liebsch-mext-dmm-nat-phl-02.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 25, 2013.
Copyright Notice
Copyright (c) 2012 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 25, 2013 [Page 1]
Internet-Draft DMM per-host locator October 2012
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. Ascertaining of an MN's current anchor . . . . . . . . . . . . 10
5.1. Resolving an MN's Locator State at a Router . . . . . . . 10
5.2. Maintenance of an MN's Locator State at a Router . . . . . 12
6. Function of the DMM Ingress Router . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Liebsch Expires April 25, 2013 [Page 2]
Internet-Draft DMM per-host locator October 2012
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 distributed DMM Ingress
Routers (IR) which resolve the MN's identifier into a locator address
in case they have to forward data traffic to a mobile node. The
mobile node's current mobility anchor serves as Egress Router (ER).
Between the IR and ER, the existing routing or switching plane in the
mobile operator network is in use.
Instead of using encapsulation to tunnel packets between an IR and
the ER, per-host locator addresses are used to network address
translate (NAT) 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.
The proposed approach to solve DMM in the routing plane above
mobility anchor level implies no dependency on the IP mobility
protocol below anchors and requires no changes to the routing
infrastructure, as standard routing and associated table entries can
be used. The introduced Ingress Router is represented by a regular
router with the capability of performing pre-routing NAT to make use
of a routable host address and to achieve that the data packet
arrives at the mobile node's current mobility anchor using the most
suitable route.
Liebsch Expires April 25, 2013 [Page 3]
Internet-Draft DMM per-host locator October 2012
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 25, 2013 [Page 4]
Internet-Draft DMM per-host locator October 2012
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 25, 2013 [Page 5]
Internet-Draft DMM per-host locator October 2012
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 DMM Ingress Routers
(IR) to resolve the MN's HNP into the associated locator address,
which is represented by the MN's current MA (nMA). Section 5
comprises exemplary operations of IRs with a mapping system.
However, detailed descriptions and recommendations of technology to
resolve the locator is not covered in 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.
Liebsch Expires April 25, 2013 [Page 6]
Internet-Draft DMM per-host locator October 2012
+--+
|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
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 to save encapsulation
overhead.
Liebsch Expires April 25, 2013 [Page 7]
Internet-Draft DMM per-host locator October 2012
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 reference to a suitable mapping system is out
of scope of the current version of this document. A generic view of
the operation between IRs and a mapping system is depicted in
Section 5. 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 25, 2013 [Page 8]
Internet-Draft DMM per-host locator October 2012
+--+
|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 25, 2013 [Page 9]
Internet-Draft DMM per-host locator October 2012
5. Ascertaining of an MN's current anchor
The routers, which function as DMM Ingress Router for an MN's data
traffic, are able to perform pre-routing destination NAT on the
traffic downlink path. In case the router has no per-host state for
the MN's IP address yet, the router can either forward the data
packet according to a longest prefix match and update the route after
the MN's IP address has been resolved into the currently valid
locator, or the router holds the packet until a per-host state has
been established after a query to a mapping system. The proposed
approach for DMM assumes the availability of a suitable mapping
system, maintaining mappings between MNs' HNP_id and the HNP_loc,
which is topologically anchored at the MN's current mobility anchor.
Mapping entries are set up and maintained by registration with a
mapping system. Routers can query a mapping from the mapping system.
Furthermore, the mapping system may maintain a list of routers, who
queried a mapping for a particular MN. This enables the mapping
system to update these routers, which have a (soft) state for the MN
to optimize routing of the MN's packets according to the HNP_loc,
after the MN's HNP_id resolves into a new HNP_loc, e.g. after the MN
has been assigned a new mobility anchor. Since pushing unsolicited
mapping updates to some routers exceeds the function of a mapping
database, the following description denotes such mapping system as
Mapping Control (MC) function.
5.1. Resolving an MN's Locator State at a Router
Figure 4 depicts an exemplary procedure of the registration of the
MN's mapping between its HNP_id (A:1::) and the HNP_loc (B:1::) after
anchor relocation. The MN's previous mobility anchor (pMA) serves as
initial anchor to the MN and has assigned the MN a prefix A:1:: from
its available prefix pool (A:x::) (1). After the MN has been changed
to a new mobility anchor (nMA), the nMA assigns a per-host prefix to
the MN (B:1::) from its available prefix pool (B:x::) (2), which is
used as HNP_loc and registered with the mapping control (MC) (3). As
soon as a router (Rt1) has to forward packets towards the MN, it can
query the MC about an HNP_loc while treating the destination IP
address in the packet being sent by the traffic source (S) as HNP_id
(4). According to the response, the router (Rt) can perform
destination NAT of the packet's HNP_id based destination IP address
(A:1::1) to the HNP_loc based address (B:1::1) and forward the packet
according to the translated address (6). The MN's current mobility
anchor performs reverse address translation of the HNP_loc based IP
address to the original HNP_id based IP address (A:1::1).
Liebsch Expires April 25, 2013 [Page 10]
Internet-Draft DMM per-host locator October 2012
(S) -> Traffic Source (e.g. local cache server) or local IXP
A:x:: B:x::
+--+ +---+ +---+ +---+ +---+ +--+
|MN|<MIP/PMIP>|pMA| |nMA| |Rt1| |Rt2| |MC|
+--+ +---+ +---+ +---+ +---+ +--+
| | | | | |
+--1)binding---+A:1::1 | | | |
anchor | | | | |
relocation | | | | |
+--2)binding-------------+A:1::1 | |
| | |B:1::1 3)Register(A:1::1,B:1::1) |
| | |--------------------------------------->|
| | | | |
| | data to A:1::1<--(S) 4)Resolve(A:1::1)|
| | |------------------------->|
| | | 5) Response(B:1:.1)|
| 7) A:1::1 | 6) B:1::1 |<-------------------------|
|<---------------------[NAT]<--------[NAT] | |
| | | | |
| | | | |
Figure 4: Exemplary per-host locator registration and mapping
As an alternative, the router (Rt1) can forward the downlink packet
towards the MN's initial mobility anchor according to its local
routing table using a longest prefix match, as depicted in Figure 4.
In parallel, the router (Rt1) can query the HNP_loc for the MN from
the MC (4). Such approach avoids holding the MN's downlink packet in
a buffer while the MC is contacted. However, the MN's initial anchor
(pMA) must ensure that the data packet will be forwarded to the MN's
current anchor, for example by holding a state about the MN's mapping
(4). The pMA can utilize the same NAT rules as the router (Rt1) and
forward the packet to the MN's current anchor according to the
address translated HNP_loc based IP address (5). After a completed
mapping query (6)(7), the router (Rt1) can perform address
translation and route the packet according to its HNP_loc based IP
address (8). For any packet, which arrives at the current anchor
(nMA) using the HNP_loc address, the nMA translates the packet's
destination address back to the original HNP_id based IP address (9).
Liebsch Expires April 25, 2013 [Page 11]
Internet-Draft DMM per-host locator October 2012
(S) -> Traffic Source (e.g. local cache server) or local IXP
A:x:: B:x::
+--+ +---+ +---+ +---+ +---+ +--+
|MN|<MIP/PMIP>|pMA| |nMA| |Rt1| |Rt2| |MC|
+--+ +---+ +---+ +---+ +---+ +--+
| | | | | |
+--1)binding---+A:1::1 | | | |
anchor | | | | |
relocation | | | | |
+--2)binding-------------+A:1::1 | |
| | |B:1::1 3)Register(A:1::1,B:1::1) |
| | |--------------------------------------->|
| | 4)Notify(A:1::1,B:1::1) |
| |<-------------------------------------------------|
| | | | |
| | 5) | data to A:1::1<--(S) |
| |<----------------------| 6)Resolve(A:1::1) |
| [NAT]------>| |------------------------->|
|<---------------------[NAT] | 7)Response(B:1::1)|
| | | |<-------------------------|
| | | | |
| 9) A:1::1 | 8) B:1::1 |<---(S) |
|<---------------------[NAT]<--------[NAT] |
| | | |
| | | |
Figure 5: Exemplary per-host locator registration and mapping with
fast forward
5.2. Maintenance of an MN's Locator State at a Router
After anchor relocation, the MN's current mobility anchor binds the
MN's HNP_id based prefix (A:1::) as well the HNP_loc based prefix
(B:1::) to the MN's registration (1), as depicted in Figure 6. The
MN has two active IP sessions from different sources (S), whose
downlink packets are directed to the MN's current mobility anchor by
different routers (Rt1)(Rt2), which function as DMM Ingress Routers.
After the MN has been assigned a new mobility anchor (nMA), the MN
receives an updated HNP_loc from the nMA's prefix pool (C:1::), which
is then registered with the MC (3). The MC updates the routers,
which maintain a mapping (soft) state for the MN (4). This results
in a translation of the packets' downlink address into a locator,
which is based on the HNP_loc assigned by the nMA (5).
Liebsch Expires April 25, 2013 [Page 12]
Internet-Draft DMM per-host locator October 2012
(S) -> Traffic Source (e.g. local cache server) or local IXP
B:x:: C:x::
+--+ +---+ +---+ +---+ +---+ +--+
|MN|<MIP/PMIP>|pMA| |nMA| |Rt1| |Rt2| |MC|
+--+ +---+ +---+ +---+ +---+ +--+
| 1) | | | | |
+--------------+A:1::1, | | | |
| |B:1::1 | 2) | | |
|<-----------[NAT]<----------------[NAT]<--(S) | |
|<-----------[NAT]<--------------------------[NAT]<---(S) |
| | | | | |
anchor | | | | |
relocation | | | | |
+----binding-------------+A:1::1 | |
| | |C:1::1 3) Register(A:1::1,C:1::1) |
| | |-------------------------------------->|
| | | |<--------------------------|
| | | | 4)Notify(A:1::1,C:1::1) |
| | | 5) | |<----------------|
|<---------------------[NAT]<------[NAT]<--(S) | |
|<---------------------[NAT]<----------------[NAT]---(S) |
| | | | | |
| | | | | |
Figure 6: Exemplary per-host locator update
Liebsch Expires April 25, 2013 [Page 13]
Internet-Draft DMM per-host locator October 2012
6. Function of the DMM Ingress Router
The DMM Ingress Router (IR) is a regular IP router in the mobile
operator's network, which can apply host rules to forward traffic to
a MN's current mobility anchor. The router must be able to receive
and enforce mapping policies. According to these mapping policies,
the router can use the locator information to either tunnel the
packet to the MN's current mobility anchor, or use destination NAT to
allow routing the plain data packet to the MN's current mobility
anchor while saving encapsulation overhead.
Figure 7 depicts the key functional architecture of such a router,
which is able to use network address translation before routing the
MN's packet to the currently used mobility anchor by means of an
HNP_loc based IP address.
:
:data
V
+-----------------[I/F]-----+
| : |
|+-----------+ : |
||pre-routing|<--(Policy) |
|| NAT |----->: |
|+-----------+ : |
| V |
| +-------+ |
| |Routing| |
| +-------+ |
| : : |
| V V |
+--------------[I/F]-[I/F]--+
: :
: :
V V
Figure 7: Pre-routing destination NAT at a router, which supports the
use of per-host locators according to the specified DMM approach
Liebsch Expires April 25, 2013 [Page 14]
Internet-Draft DMM per-host locator October 2012
7. 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 25, 2013 [Page 15]
Internet-Draft DMM per-host locator October 2012
8. IANA Considerations
So far no need for IANA actions has been identified.
Liebsch Expires April 25, 2013 [Page 16]
Internet-Draft DMM per-host locator October 2012
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Liebsch Expires April 25, 2013 [Page 17]
Internet-Draft DMM per-host locator October 2012
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 25, 2013 [Page 18]
