Internet DRAFT - draft-bernardos-dmm-distributed-anchoring
draft-bernardos-dmm-distributed-anchoring
DMM Working Group CJ. Bernardos
Internet-Draft UC3M
Intended status: Standards Track JC. Zuniga
Expires: November 30, 2017 SIGFOX
May 29, 2017
PMIPv6-based distributed anchoring
draft-bernardos-dmm-distributed-anchoring-09
Abstract
Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does
not rely on centralized deployed anchors to provide IP mobility
support.
There are many different approaches to address Distributed Mobility
Management, as for example extending network-based mobility protocols
(like Proxy Mobile IPv6), or client-based mobility protocols (as
Mobile IPv6), among others. This document follows the former
approach, and proposes a solution based on Proxy Mobile IPv6 in which
mobility sessions are anchored at the last IP hop router (called
distributed gateway). The distributed gateway is an enhanced access
router which is also able to operate as local mobility anchor or
mobility access gateway, on a per prefix basis. The draft focuses on
the required extensions to effectively support simultaneously
anchoring several flows at different distributed gateways.
This draft introduces the concept of distributed logical interface
(at the distributed gateway), which is a software construct that
allows to easily hide the change of anchor from the mobile node.
Additionally, the draft describes how to provide session continuity
in inter-domain scenarios in which dynamic tunneling or signaling
between distributed gateways from different operators is not allowed.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bernardos & Zuniga Expires November 30, 2017 [Page 1]
Internet-Draft PMIPv6 distributed anchoring May 2017
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 November 30, 2017.
Copyright Notice
Copyright (c) 2017 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution's overview . . . . . . . . . . . . . . . . . . . . . 5
4. Simultaneous anchoring of multiple flows (single operator) . 7
4.1. The Distributed Logical Interface (DLIF) concept . . . . 7
4.2. D-GW protocol operation . . . . . . . . . . . . . . . . . 10
4.3. Message format . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Proxy Binding Update . . . . . . . . . . . . . . . . 14
4.3.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 14
4.3.3. Anchored Prefix Option . . . . . . . . . . . . . . . 15
4.3.4. Local Prefix Option . . . . . . . . . . . . . . . . . 16
4.3.5. DLIF Link-local Address Option . . . . . . . . . . . 17
4.3.6. DLIF Link-layer Address Option . . . . . . . . . . . 18
5. Simultaneous anchoring of multiple flows (multiple operators) 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Bernardos & Zuniga Expires November 30, 2017 [Page 2]
Internet-Draft PMIPv6 distributed anchoring May 2017
Appendix A. Comparison with Requirement document . . . . . . . . 22
A.1. Distributed mobility management . . . . . . . . . . . . . 23
A.2. Bypassable network-layer mobility support for
each application session . . . . . . . . . . . 23
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 23
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 24
A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 24
A.6. Operation and management considerations . . . . . . . . . 24
A.7. Security considerations . . . . . . . . . . . . . . . . . 24
A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Implementation experience . . . . . . . . . . . . . 25
Appendix C. Public demonstrations . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Distributed Mobility Management (DMM) paradigm aims at minimizing
the impact of currently standardized mobility management solutions,
which are centralized (at least to a considerable extent).
Centralized mobility solutions, such as Mobile IPv6 or the different
macro-level mobility management solutions of 3GPP EPS, base their
operation on the existence of a central entity (e.g., HA, LMA, PGW or
GGSN) that anchors the IP address used by the mobile node and is in
charge of coordinating the mobility management (MM) (sometimes helped
by a third entity like the MME or the HSS). This central anchor
point is in charge of tracking the location of the mobile and
redirecting its traffic towards its current topological location.
While this way of addressing mobility management has been fully
developed by the Mobile IP protocol family and its many extensions,
there are also several limitations that have been identified
[RFC7333]. Among them, we can just highlight sub-optimal routing,
scalability problems (in the network and in the centralized anchor)
and reliability [RFC7333].
Several DMM-based approaches are being proposed and explored now
[RFC7429], [commag.dmm-standards]. One of them is based on extending
network-based mobility protocols (such as Proxy Mobile IPv6 [RFC5213]
or GTP) to operate in distributed fashion. This document proposes a
solution that falls in this category, defining a new logical entity,
called Distributed Gateway (D-GW) which basically encompasses the
functionalities of plain IPv6 access router, MAG and LMA, on a per-
IPv6 prefix basis. The main contribution of this draft is the
definition of the mechanisms required to support the operation of
such a network-based mobility solution when several flows are
simultaneously anchored [I-D.ietf-dmm-distributed-mobility-anchoring]
at different D-GWs, by introducing the concept of Distributed Logical
Bernardos & Zuniga Expires November 30, 2017 [Page 3]
Internet-Draft PMIPv6 distributed anchoring May 2017
Interface (DLIF). The document also defines the required PMIPv6
signaling extensions. Last, but not least, the solution is also
extended to provide session continuity across different domains.
2. Terminology
The following terms used in this document are defined in the Proxy
Mobile IPv6 specification [RFC5213]:
Local Mobility Anchor (LMA)
Mobile Access Gateway (MAG)
Mobile Node (MN)
Binding Cache Entry (BCE)
Proxy Care-of Address (P-CoA)
Proxy Binding Update (PBU)
Proxy Binding Acknowledgment (PBA)
The following terms are defined and/or used in this document:
D-GW (Distributed Gateway). First IP hop router used by the mobile
node. It provides an IPv6 prefix (topologically anchored at the
D-GW) to each attaching mobile node.
Anchoring D-GW. A previously visited D-GW anchoring an IPv6 prefix
which is still used by a mobile node.
Serving D-GW. The D-GW the MN is currently attached to.
DLIF (Distributed Logical Interface). It is a logical interface at
the IP stack of the D-GW. For each active prefix used by the
mobile node, the serving D-GW has a DLIF configured (associated to
the anchoring D-GW). In this way, a serving D-GW exposes itself
towards each MN as multiple routers, one per active anchoring
D-GW.
HSS (Home Subscriber Server). In a 3GPP architecture, it is the
master user database that contains the subscription-related
information (subscriber profiles), performs authentication and
authorization of the user, and can provide information about the
subscriber's location and IP information.
Bernardos & Zuniga Expires November 30, 2017 [Page 4]
Internet-Draft PMIPv6 distributed anchoring May 2017
3. Solution's overview
A new logical network entity, called Distributed Gateway (D-GW) is
introduced at the edge of the network, close to the MN. It
implements the functionality of a plain IPv6 access router (AR), a
mobile access gateway (MAG) and a local mobility anchor (LMA), on a
per-MN and per-IPv6-prefix, as described later.
The solution basically extends Proxy Mobile IPv6 [RFC5213] to behave
in a distributed fashion, similarly as what has been proposed in
[I-D.seite-dmm-dma] and [I-D.bernardos-dmm-pmip]. This is achieved
by the D-GW logically behaving as a distributed mobility anchor,
which comprises the following:
o When a mobile node attaches to a D-GW (initial attachment or
handover), the D-GW provides an IPv6 prefix to the MN, acting as a
regular IPv6 router (with the only difference that the delegated
prefix is only assigned to one single MN, not being shared with
any other node). The D-GW that the mobile node is currently
attached to is called "serving D-GW".
o When a mobile node performs a handover, it attaches to a new D-GW
and configures a new IPv6 address out of the prefix provided and
anchored by the new serving D-GW. As before, the serving D-GW
behaves as a plain IPv6 router for that particular MN and the
delegated (locally anchored) prefix. If the MN has active traffic
using addresses anchored by other D-GWs (which are called
"anchoring D-GWs") or it just needs to keep the reachability of
these addresses, the current serving D-GW also acts as MAG, by
sending the required proxy binding update (PBU) to the
corresponding anchoring D-GWs. The anchoring D-GWs therefore
behave as LMA for this particular MN and the IPv6 prefixes they
are anchoring, replying with a PBA.
o Once the PBU/PBA signaling is completed, a bidirectional tunnel is
established between the serving D-GW and the anchoring D-GW (one
per D-GW anchoring an active prefix used by the MN). These
tunnels are used to provide IP address continuity to prefixes that
are not anchored at the serving D-GW.
o The means for a serving D-GW to obtain the information about the
prefixes that a locally attached mobile node wants to keep
reachable, and the associated anchoring D-GWs are out of the scope
of this draft. Among the possible mechanisms that can be used to
let the D-GW know about the prefixes that should be kept
reachable, we can cite for instance layer-2 triggers/signaling.
Regarding the mapping of IPv6 prefixes to anchoring D-GWs, there
might be either fully distributed mechanisms in place, or the
Bernardos & Zuniga Expires November 30, 2017 [Page 5]
Internet-Draft PMIPv6 distributed anchoring May 2017
information can be maintained in a centralized repository (e.g.,
in the HSS, using a centralized LMA [I-D.bernardos-dmm-pmip],
etc.).
The basic operation of the solution is shown with an example in
Figure 1. MN1 attaches to D-GW1 (thus becoming its serving D-GW) and
configures an IPv6 address (prefA::MN1) out of a prefix locally
anchored at D-GW1 (prefA::/64). At this point, MN1 can communicate
with any correspondent node of the Internet, being the traffic
anchored at D-GW1. If later on MN1 moves to D-GW2, a new IPv6
address (PrefB::MN1) is configured by the mobile node, this time out
of prefB::/64, which is anchored at D-GW2 (which becomes the new
serving D-GW). D-GW2 also exchanges the required PBU/PBA signaling
to ensure that data traffic using prefA::MN1 still reaches the mobile
node, by setting up a bidirectional tunnel between D-GW1 (anchoring
D-GW) and D-GW2 (serving D-GW).
+-----+ +-------+ +-------+ +-------------+
| MN1 | | D-GW1 | | D-GW2 | | CN@Internet |
+-----+ +-------+ +-------+ +-------------+
| | | |
| attachment | | |
|<...........>| | |
| prefA::/64 | | |
|<------------| | |
configures | | | |
prefA::MN1 | | | |
| (traffic using prefA::MN1) |
|<------------|------------------------------->|
| | | |
| handover | |
/............................/ |
| | prefB::/64 | |
|<---------------------------| |
configures | | PBU | |
prefB::MN1 | tunnel |<-------------| |
and keeps | set-up | PBA | |
using | |------------->| tunnel |
prefA::MN1 | | | set-up |
| (traffic using prefB::MN1) |
|<---------------------------|---------------->|
| (traffic using prefA::MN1) |
| |<------------------------------>|
| |<============>| |
|<-------------------------->| |
| | | |
Figure 1: Basic operation of the solution
Bernardos & Zuniga Expires November 30, 2017 [Page 6]
Internet-Draft PMIPv6 distributed anchoring May 2017
The next sections of this draft focus on the detailed operation of
the D-GWs when a mobile node has multiple flows anchored at different
distributed gateways.
4. Simultaneous anchoring of multiple flows (single operator)
In this section we describe the mechanisms required in the network to
enable simultaneous anchoring of several flows at different D-GWs
within the same operator.
4.1. The Distributed Logical Interface (DLIF) concept
One of the main challenges of a network-based DMM solution is how to
allow a mobile node to simultaneously send/receive traffic which is
anchored at different D-GWs, and how to influence on the preference
of the mobile selecting the source IPv6 address for a new
communication, without requiring special support on the mobile node
stack. This document defines the Distributed Logical Interface
(DLIF), which is a software construct that allows to easily hide the
change of anchor from the mobile node.
+---------------------------------------------------+
( Operator's )
( core )
+---------------------------------------------------+
| |
+---------------+ tunnel +---------------+
| IP stack |===============| IP stack |
+---------------+ +-------+-------+
| mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+
+---------------+ | | +-------+-------+ |
| phy interface | | | | phy interface | |
+---------------+ | | +---------------+ |
D-GW1 (o) (o) D-GW2 (o)
x x
x x
prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x
(o)
|
+-----+
prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+
Figure 2: DLIF: exposing multiple routers (one per active anchoring
D-GW)
Bernardos & Zuniga Expires November 30, 2017 [Page 7]
Internet-Draft PMIPv6 distributed anchoring May 2017
The basic idea of the DLIF concept is the following. Each serving
D-GW exposes itself towards a given MN as multiple routers, one per
active anchoring D-GW associated to the MN. Let's consider the
example shown in Figure 2, MN1 initially attaches to D-GW1,
configuring an IPv6 address (prefA::MN1) from a prefix locally
anchored at D-GW1 (prefA::/64). At this stage, D-GW1 plays both the
role of anchoring and serving D-GW, and also it behaves as a plain
IPv6 access router. D-GW1 creates a distributed logical interface to
communicate (point-to-point link) with MN1, exposing itself as a
(logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and
IPv6 addresses (e.g., prefA::DGW1/64 and fe80:211:22ff:fe33:101/64)
using the DLIF mn1dgw1. As explained below, these addresses
represent the "logical" identity of D-GW1 towards MN1, and will
"follow" the mobile node while roaming within the domain (note that
the place where all this information is maintained and updated is
out-of-scope of this draft; potential examples are to keep it on the
HSS or the user's profile).
If MN1 moves and attaches to a different D-GW of the domain (D-GW2 in
the example of Figure 2), this D-GW will create a new logical
interface (mn1dgw2) to expose itself towards MN1, providing it with a
locally anchored prefix (prefB::/64). In this case, since the MN1
has another active IPv6 address anchored at a D-GW1, D-GW2 also needs
to create an additional logical interface configured to exactly
resemble the one used by D-GW1 to communicate with MN1. In this
example, there is only one active anchoring D-GW (in addition to
D-GW2, which is the serving one): D-GW1, so only the logical
interface mn1dgw1 is created, but the same process would be repeated
in case there were more active anchoring D-GWs involved. In order to
maintain the prefix anchored at D-GW1 reachable, a tunnel between
D-GW1 and D-GW2 is established and the routing is modified
accordingly. The PBU/PBA signaling is used to set-up the bi-
directional tunnel between D-GW1 and D-GW2, and it might also be used
to convey to D-GW2 the information about the prefix(es) anchored at
D-GW1 and about the addresses of the associated DLIF (i.e., mn1dgw1).
Bernardos & Zuniga Expires November 30, 2017 [Page 8]
Internet-Draft PMIPv6 distributed anchoring May 2017
+------------------------------------------+ +----------------------+
| D-GW1 | | D-GW2 |
|+----------------------------------------+| |+--------------------+|
||+------------------++------------------+|| ||+------------------+||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||||mn3dgw1||mn3dgw2||||mn2dgw1||mn2dgw2|||| ||||mn1dgw1||mn1dgw2||||
|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
||+------------------++------------------+|| ||+------------------+||
|| HMAC1 (phy if D-GW1) || ||HMAC2 (phy if D-GW2)||
|+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+
x x x
x x x
(o) (o) (o)
| | |
+--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+
Figure 3: Distributed Logical Interface concept
Figure 3 shows the logical interface concept in more detail. The
figure shows two D-GWs and three MNs. D-GW1 is currently serving MN2
and MN3, while D-GW2 is serving MN1. MN1, MN2 and MN3 have two
active anchoring D-GWs: D-GW1 and D-GW2. Note that a serving D-GW
always plays the role of anchoring D-GW for the attached (served)
MNs. Each D-GW has one single physical wireless interface.
As introduced before, each MN always "sees" multiple logical routers
-- one per active anchoring D-GW -- independently of to which serving
D-GW the MN is currently attached. From the point of view of the MN,
these D-GWs are portrayed as different routers, although the MN is
physically attached to one single interface . The way this is
achieved is by the serving D-GW configuring different logical
interfaces. If we focus on MN1, it is currently attached to D-GW2
(i.e., D-GW2 is its serving D-GW) and, therefore, it has configured
an IPv6 address from D-GW2's pool (e.g., prefB::/64). D-GW2 has set-
up a logical interface (mn1dgw2) on top of its wireless physical
interface (phy if D-GW2) which is used to serve MN1. This interface
has a logical MAC address (LMAC6), different from the hardware MAC
address (HMAC2) of the physical interface of D-GW2. Over the mn1dgw2
interface, D-GW2 advertises its locally anchored prefix prefB::/64.
Before attaching to D-GW2, MN1 visited D-GW1, configuring also an
address locally anchored at this D-GW, which is still being used by
the MN1 in active communications. MN1 keeps "seeing" an interface
connecting to D-GW1, as if it were directly connected to the two
Bernardos & Zuniga Expires November 30, 2017 [Page 9]
Internet-Draft PMIPv6 distributed anchoring May 2017
D-GWs. This is achieved by the serving D-GW (D-GW1) configuring an
additional distributed logical interface: mn1dgw1, which behaves
exactly as the logical interface configured by the actual D-GW1 when
MN1 was attached to it. This means that both the MAC and IPv6
addresses configured on this logical interface remain the same
regardless of the physical D-GW which is serving the MN. The
information required by a serving D-GW to properly configure this
logical interfaces can be obtained in different ways: as part of the
information conveyed in the PBA, from an external database (e.g., the
HSS) or by other means. As shown in the figure, each D-GW may have
several logical interfaces associated to each attached MN, having
always at least one (since a serving D-GW is also an anchoring D-GW
for the attached MN).
In order to enforce the use of the prefix locally anchored at the
serving D-GW, the router advertisements sent over those logical
interfaces playing the role of anchoring D-GWs (different from the
serving one) include a zero prefix lifetime. The goal is to
deprecate the prefixes delegated by these D-GWs (which will be no
longer serving the MN). Note that on-going communications keep on
using those addresses, even if they are deprecated, so this only
affects to new sessions.
The distributed logical interface concept also enables the following
use case. Suppose that access to a local IP network is provided by a
given D-GW (e.g., D-GW1 in the example shown in Figure 2) and that
the resources available at that network cannot be reached from
outside the local network (e.g., cannot be accessed by an MN attached
to D-GW2). This is similar to the LIPA scenario currently being
consider by 3GPP. The goal is to allow an MN to be able to roam
while still being able to have connectivity to this local IP network.
The solution adopted to support this case makes use of RFC 4191
[RFC4191] more specific routes when the MN moves to a D-GW different
from the one providing access to the local IP network (D-GW1 in the
example). These routes are advertised through the distributed
logical interface representing the D-GW providing access to the local
network (D-GW1 in this example). In this way, if MN1 moves from
D-GW1 to D-GW2, any active session that MN1 may have with a node of
the local network connected to D-GW1 will survive, being the traffic
forwarded via the tunnel between D-GW1 and D-GW2. Also, any
potential future connection attempt towards the local network will be
supported, even though MN1 is no longer attached to D-GW1.
4.2. D-GW protocol operation
This section describes the D-GW operation in more detail.
Figure 4 shows an example of the D-GW operation:
Bernardos & Zuniga Expires November 30, 2017 [Page 10]
Internet-Draft PMIPv6 distributed anchoring May 2017
1. MN1 attaches to D-GW1. This event is detected by D-GW1 (based on
layer 2 signaling/triggers or the reception of a Router
Solicitation sent by MN1).
2. An IPv6 prefix from the pool of locally anchored prefixes is
selected by D-GW1 to be delegated to MN1 (prefA::/64). D-GW1
sets up a distributed logical interface aimed at interfacing with
MN1, called mn1dgw1. D-GW1 starts sending router advertisements
to MN1, including the delegated prefix.
3. D-GW1 learns if it is an attachment due to a handover (how this
is done is out-of-scope of this draft). In this case it is an
initial attachment, so nothing else is required.
4. The DLIF mn1dgw1 is used by D-GW1 to advertise the locally
anchored prefix (prefA::/64) to MN1. Using this prefix, MN1
configures an IPv6 address (prefA::MN1/64) that can be used to
start new sessions (which will be anchored at D-GW1). Traffic
using the address prefA::MN1 is received at the interface mn1dgw1
and directly forwarded by D-GW1 towards its destination. Traffic
between MN1 and the local network reachable via D-GW1 (localnet)
is handled normally by D-GW1 (as MN1 is locally attached).
5. MN1 performs a handover to D-GW2. This event is detected by
D-GW2.
6. An IPv6 prefix from the pool of locally anchored prefixes is
selected by D-GW2 to be delegated to MN1 (prefB::/64). D-GW2
sets up a distributed logical interface aimed at interfacing with
MN1, called mn1dgw2. D-GW2 starts sending router advertisements
to MN1, including the delegated prefix. Traffic using the
address prefB::MN1 is received at the interface mn1dgw2 and
directly forwarded by D-GW2 towards its destination.
7. D-GW2 learns that this is a handover of MN1, and that it
previously visited D-GW1. D-GW2 sends a PBU to D-GW1, which
replies with a PBA. This PBA MAY include information about the
prefix(es) anchored at D-GW1, the parameters needed by D-GW2 to
set-up the DLIF mn1dgw1, and the prefixes of local networks
reachable via D-GW (if any). Alternatively, this information MAY
be obtained using a different approach (such as storing it in the
HSS or some other external repository). A bi-directional tunnel
between D-GW1 and D-GW2 is set-up, as well as the required
routing entries.
8. D-GW2 sets up the DLIF mn1dgw1, aimed at "logically" resembling
D-GW1, so MN1 does not detect any change at layer-3. D-GW2
starts sending router advertisements to MN1 through mn1dgw2,
Bernardos & Zuniga Expires November 30, 2017 [Page 11]
Internet-Draft PMIPv6 distributed anchoring May 2017
which include the prefix anchored at D-GW1 (prefA::/64) with zero
lifetime to deprecate the prefix (or alternatively it MAY include
a low Default Router Preference [RFC4191] if communication to
this D-GW is still needed in the future). In this way,
prefA::MN1 is not preferred for new communications. The RAs MAY
also include a Route Information Option (RIO) [RFC4191] with the
prefix of localnet, which is the network that is only locally
reachable via D-GW1 (e.g., as in the LIPA scenarios considered by
the 3GPP), so MN1 picks D-GW1 (the "logical" version of it
portrayed by D-GW2) when sending traffic to that network ,
including the delegated prefix. Traffic using the address
prefA::MN1 is received at the interface mn1dgw1 and forwarded via
the tunnel with D-GW1, which then forwards it towards its
destination. Traffic between MN1 and the network locally
reachable via D-GW1 (localnet) is also handled via mn1dgw1 and
sent through the tunnel.
Bernardos & Zuniga Expires November 30, 2017 [Page 12]
Internet-Draft PMIPv6 distributed anchoring May 2017
+-----+ +-------+ +-------+ +-------------+
| MN1 | | D-GW1 | | D-GW2 | | CN@Internet |
+-----+ +-------+ +-------+ +-------------+
| | | |
| attachment | | |
|<...........>|set-up of new | |
| RA@mn1dgw1 |DLIF: mn1dgw1 | |
|<------------| | |
configures | (prefA::/64)| | |
prefA::MN1 | | | |
| (traffic using prefA::MN1) |
|<------------|------------------------------->|
| (traffic with local net) | |
|<----------->|<----> | |
| | | |
| handover | |
/............................/set-up of new |
| | RA@mn1dwg2 |DLIF: mn1dgw2 |
configures |<---------------------------| |
prefB::MN1 | | (prefB::/64)| |
and keeps | | PBU | |
using | tunnel |<-------------| |
prefA::MN1 | set-up | PBA(mn1dgw1, | |
| | prefA::/64, | |
| | preflocalnet)| |
| |------------->|set-up of tunnel |
| | RA@mn1dgw1 | & DLIF mn1dgw1 |
|<---------------------------| |
| | (prefA::/64, lft=0, |
| | RIO: preflocalnet) |
| | | |
| (traffic using prefB::MN1) |
|<-------------------------->|<--------------->|
| | | |
| (traffic using prefA::MN1) |
|<-------------------------->| |
| |<============>| |
| |<------------------------------>|
| | | |
| (traffic with local net) | |
|<-------------------------->| |
| |<============>| |
| |<---> | |
| | | |
Figure 4: D-GW protocol operation
Bernardos & Zuniga Expires November 30, 2017 [Page 13]
Internet-Draft PMIPv6 distributed anchoring May 2017
4.3. Message format
This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages.
4.3.1. Proxy Binding Update
A new flag (D) is included in the Proxy Binding Update to indicate
that the Proxy Binding Update is coming from a Distributed Gateway
and not from a mobile access gateway. The rest of the Proxy Binding
Update format remains the same as defined in [RFC5213].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Distributed Gateway Flag (D)
The Distributed Gateway Flag is set to indicate to the receiver of
the message that the Proxy Binding Update is from a Distributed
Gateway.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of
[RFC6275]. The distributed gateway MUST ignore and skip any
options that it does not understand.
4.3.2. Proxy Binding Acknowledgment
A new flag (D) is included in the Proxy Binding Acknowledgment to
indicate that the sender supports operating as a distributed gateway.
The rest of the Proxy Binding Acknowledgment format remains the same
as defined in [RFC5213].
Bernardos & Zuniga Expires November 30, 2017 [Page 14]
Internet-Draft PMIPv6 distributed anchoring May 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|D| Reser |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Distributed Gateway Flag (D)
The Distributed Gateway Flag is set to indicate that the sender of
the message supports operating as a distributed gateway.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of
[RFC6275]. The distributed gateway MUST ignore and skip any
options that it does not understand.
4.3.3. Anchored Prefix Option
A new Anchored Prefix option is defined for use with the Proxy
Binding Update and Proxy Binding Acknowledgment messages exchanged
between distributed gateways. This option is used for exchanging the
mobile node's prefix anchored at the anchoring D-GW. There can be
multiple Anchored Prefix options present in the message.
The Anchored Prefix Option has an alignment requirement of 8n+4. Its
format is as follows:
Bernardos & Zuniga Expires November 30, 2017 [Page 15]
Internet-Draft PMIPv6 distributed anchoring May 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Anchored Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be
set to 18.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored
Prefix.
4.3.4. Local Prefix Option
A new Local Prefix option is defined for use with the Proxy Binding
Update and Proxy Binding Acknowledgment messages exchanged between
distributed gateways. This option is used for exchanging a prefix of
a local network that is only reachable via the anchoring D-GW. There
can be multiple Local Prefix options present in the message.
Bernardos & Zuniga Expires November 30, 2017 [Page 16]
Internet-Draft PMIPv6 distributed anchoring May 2017
The Local Prefix Option has an alignment requirement of 8n+4. Its
format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be
set to 18.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Local Prefix
A sixteen-byte field containing the IPv6 Local Prefix.
4.3.5. DLIF Link-local Address Option
A new DLIF Link-local Address option is defined for use with the
Proxy Binding Update and Proxy Binding Acknowledgment messages
exchanged between distributed gateways. This option is used for
exchanging the link-local address of the DLIF to be configured on the
Bernardos & Zuniga Expires November 30, 2017 [Page 17]
Internet-Draft PMIPv6 distributed anchoring May 2017
serving D-GW so it resembles the DLIF configured on the anchoring
D-GW.
The DLIF Link-local Address option has an alignment requirement of
8n+6. Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DLIF Link-local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be
set to 16.
DLIF Link-local Address
A sixteen-byte field containing the link-local address of the
logical interface.
4.3.6. DLIF Link-layer Address Option
A new DLIF Link-layer Address option is defined for use with the
Proxy Binding Update and Proxy Binding Acknowledgment messages
exchanged between distributed gateways. This option is used for
exchanging the link-layer address of the DLIF to be configured on the
serving D-GW so it resembles the DLIF configured on the anchoring
D-GW.
The format of the DLIF Link-layer Address option is shown below.
Based on the size of the address, the option MUST be aligned
appropriately, as per mobility option alignment requirements
specified in [RFC6275].
Bernardos & Zuniga Expires November 30, 2017 [Page 18]
Internet-Draft PMIPv6 distributed anchoring May 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ DLIF Link-layer Address +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
DLIF Link-layer Address
A variable length field containing the link-layer address of the
logical interface to be configured on the serving distributed
gateway.
The content and format of this field (including byte and bit
ordering) is as specified in Section 4.6 of [RFC4861] for carrying
link-layer addresses. On certain access links, where the link-
layer address is not used or cannot be determined, this option
cannot be used.
5. Simultaneous anchoring of multiple flows (multiple operators)
An MN may roam between D-GWs that do not belong to the same operator,
and therefore might end up having multiple simultaneous flows,
anchored at different operators. Since dynamically setting up
tunnels between different operators (i.e., between D-GWs belonging to
different operators) is usually not supported, a solution should be
devised to ensure session continuity in this scenario, even if it is
at the cost of a sub-optimal routing.
Bernardos & Zuniga Expires November 30, 2017 [Page 19]
Internet-Draft PMIPv6 distributed anchoring May 2017
In this section we describe the required extensions to support inter-
domain operation. The basic solution consists in using a centralized
LMA (usually located in the home domain) as top-level anchor to
guarantee session continuity when crossing operator borders. We
assume that the necessary roaming agreements are in place in order to
support setting up tunnels between the LMA located at the home domain
of the MN and the visited D-GWs.
+---------------------------------------------------+
( Home Operator's core )
( )
( +-----+ )
( /| LMA |\ )
( //+-----+\\ )
( // \\ )
+------------------//-----------\\------------------+
. (tunnel) // \\ (tunnel) .
. // \\ .
. // \\ .
. // \\ .
+---------------+ +---------------+
| IP stack | | IP stack |
+---------------+ +-------+-------+
| mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+
+---------------+ | | +-------+-------+ |
| phy interface | | | | phy interface | |
+---------------+ | | +---------------+ |
D-GW1@OperatorA (o) (o) D-GW2@OperatorB (o)
x x
x x
prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x
(o)
|
+-----+
prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+
Figure 5: Simultaneous anchoring of multiple flows across multiple
operators
Figure 5 shows an example of the inter-domain operation. MN1
initially attaches to D-GW1 (which belongs to OperatorA), and
configures prefA::MN1 address out of one prefix anchored at D-GW1
(prefA::/64). If MN1 moves to D-GW2, which is managed by OperatorB,
tunnels need to be established via the centralized LMA at the MN1's
operators core, since we assume that no direct tunneling is possible
between D-GWs belonging to different operators. In this case, D-GW3
Bernardos & Zuniga Expires November 30, 2017 [Page 20]
Internet-Draft PMIPv6 distributed anchoring May 2017
establishes one tunnel with the centralized LMA to send/receive
traffic using prefA::/64. From the point of view of D-GW2, the
operation is just as if the LMA was the D-GW anchoring this prefix.
Analogously, the LMA establishes one tunnel with D-GW1 (from the
point of view of D-GW1, the LMA is the current serving D-GW of MN1).
Regarding the signaling, it is similar to the intra-operator
scenario, though in this case the PBU/PBA sequence is performed
twice, once between D-GW2 and the LMA, and another one between the
LMA and D-GW1 (i.e., because two different tunnels are created).
6. IANA Considerations
This document defines new mobility options that require IANA actions.
7. Security Considerations
The protocol extensions defined in this document share the same
security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended
that the signaling messages, Proxy Binding Update and Proxy Binding
Acknowledgment, exchanged between the distributed gateways, or
between a distributed gateway and a centralized local mobility
anchor, are protected using IPsec using the established security
association between them. This essentially eliminates the threats
related to the impersonation of a distributed gateway or the local
mobility anchor.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>.
Bernardos & Zuniga Expires November 30, 2017 [Page 21]
Internet-Draft PMIPv6 distributed anchoring May 2017
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>.
8.2. Informative References
[commag.dmm-standards]
Zuniga, JC., Bernardos, CJ., de la Oliva, A., Melia, T.,
Costa, R., and A. Reznik, "Distributed mobility
management: a standards landscape", IEEE Communications
Magazine Vol. 51, No. 3, March 2013.
[I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
solution for Distributed Mobility Management", draft-
bernardos-dmm-pmip-08 (work in progress), March 2017.
[I-D.ietf-dmm-distributed-mobility-anchoring]
Chan, A., Wei, X., Lee, J., Jeon, S., Petrescu, A., and F.
Templin, "Distributed Mobility Anchoring", draft-ietf-dmm-
distributed-mobility-anchoring-05 (work in progress), May
2017.
[I-D.seite-dmm-dma]
Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-07 (work in progress),
February 2014.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<http://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015,
<http://www.rfc-editor.org/info/rfc7429>.
Appendix A. Comparison with Requirement document
In this section we descrbe how our solution addresses the DMM
requirements listed in [RFC7333].
Bernardos & Zuniga Expires November 30, 2017 [Page 22]
Internet-Draft PMIPv6 distributed anchoring May 2017
A.1. Distributed mobility management
"IP mobility, network access solutions, and forwarding solutions
provided by DMM MUST enable traffic to avoid traversing a single
mobility anchor far from the optimal route."
In our solution, the anchoring D-GW is responsible to handle the
mobility for those IP flows started when the MN is attached to it.
As long as the MN remains connected to the anchoring D-GW's access
links, the IP packets of such flows can benefit from the optimal
path. When the MN moves to another D-GW, the path becomes non-
optimal for ongoing flows, but newly started IP sessions are
forwarded by the serving D-GW through the optimal path.
A.2. Bypassable network-layer mobility support for each application
session
"DMM solutions MUST enable network-layer mobility, but it MUST be
possible for any individual active application session (flow) to not
use it. Mobility support is needed, for example, when a mobile host
moves and an application cannot cope with a change in the IP address.
Mobility support is also needed when a mobile router changes its IP
address as it moves together with a host and, in the presence of
ingress filtering, an application in the host is interrupted.
However, mobility support at the network layer is not always needed;
a mobile node can often be stationary, and mobility support can also
be provided at other layers. It is then not always necessary to
maintain a stable IP address or prefix for an active application
session."
The solution operates at the IP layer, hence upper layers are totally
transparent to the mobility operations. In particular, ongoing IP
sessions are not disrupted after a change of access network. The
routability of the old address is ensured by the IP tunnel with the
anchoring D-GW. New IP sessions are started with the new address.
From the application's perspective, those processes which sockets are
bound to a unique IP address do not suffer any impact. For the other
applications, the sockets bound to the old address are preserved,
whereas next sockets use the new address.
Additionally, the use of the DLIF makes easier to implement more
complex policies regarding how traffic is forwarded at the D-GW.
A.3. IPv6 deployment
"DMM solutions SHOULD target IPv6 as the primary deployment
environment and SHOULD NOT be tailored specifically to support IPv4,
Bernardos & Zuniga Expires November 30, 2017 [Page 23]
Internet-Draft PMIPv6 distributed anchoring May 2017
particularly in situations where private IPv4 addresses and/or NATs
are used."
The solution targets IPv6 only.
A.4. Existing mobility protocols
"A DMM solution MUST first consider reusing and extending IETF
standard protocols before specifying new protocols."
The is derived from the operations and messages specified in
[RFC5213].
A.5. Coexistence with deployed networks/hosts and operability across
different networks
"A DMM solution may require loose, tight, or no integration into
existing mobility protocols and host IP stacks. Regardless of the
integration level, DMM implementations MUST be able to coexist with
existing network deployments, end hosts, and routers that may or may
not implement existing mobility protocols. Furthermore, a DMM
solution SHOULD work across different networks, possibly operated as
separate administrative domains, when the needed mobility management
signaling, forwarding, and network access are allowed by the trust
relationship between them."
The solution can be extended to provide a fallback mechanism to
operate as legacy Proxy Mobile IPv6. It is necessary to instruct
D-GWs to always establish a tunnel with the same anchoring D-GW,
working as LMA.
A.6. Operation and management considerations
"A DMM solution needs to consider configuring a device, monitoring
the current operational state of a device, and responding to events
that impact the device, possibly by modifying the configuration and
storing the data in a format that can be analyzed later.
The proposed solution can re-use existing mechanisms defined for the
operation and management of Proxy Mobile IPv6.
A.7. Security considerations
"A DMM solution MUST support any security protocols and mechanisms
needed to secure the network and to make continuous security
improvements. In addition, with security taken into consideration
early in the design, a DMM solution MUST NOT introduce new security
Bernardos & Zuniga Expires November 30, 2017 [Page 24]
Internet-Draft PMIPv6 distributed anchoring May 2017
risks or amplify existing security risks that cannot be mitigated by
existing security protocols and mechanisms."
The proposed solution does not specify a security mechanism, given
that the same mechanism for PMIPv6 can be used.
A.8. Multicast
"DMM SHOULD enable multicast solutions to be developed to avoid
network inefficiency in multicast traffic delivery."
This solution in its current version does not specify any support for
multicast traffic, which is left for study in future versions.
Appendix B. Implementation experience
The DLIF concept can be easily implemented using features that are
usually available on several OSs. Among the possible mechanisms that
can be used to do it, the Linux macvlan support allows the creation
of different logical interfaces over the same physical one. Each
logical interface appears as a regular interface to the Linux OS
(which can be configured normally), and it supports configuring the
MAC address exposed by the logical interface. The destination MAC
address is used by the OS to decide which logical interface
(configured on top of a physical interface) is in charge of
processing an incoming L2 frame.
The EU FP7 MEDIEVAL project implemented a prototype of the DLIF
concept using the Linux macvlan support, the radvd daemon, the Linux
Advanced Routing and Traffic Control features and the standard
iproute2 collection of utilities:
o The macvlan support enables iproute2 tools to be able to create,
destroy and configure DLIFs on demand over a single physical
interface. One of the important features that needs to be
configured is the logical MAC address exposed by the DLIF, as well
as the IPv6 addresses, as they should remain the same regardless
of the serving D-GW where the DLIF is configured.
o Since the distributed logical interfaces created using the macvlan
support appear as regular network interfaces, they can be used
normally in the radvd configuration file. Them, by dynamically
modifying the radvd configuration file and reloading it, we can
control the router advertisements sent to each MN (e.g.,
advertizing new IPv6 prefixes, deprecating prefixes anchored at
other serving D-GWs, announcing RFC 4191 specific routes or
changing router preferences).
Bernardos & Zuniga Expires November 30, 2017 [Page 25]
Internet-Draft PMIPv6 distributed anchoring May 2017
o Each time a DLIF is created, it is also needed to properly
configure source-based IPv6 routes, as well as tunnels (in case of
handover). This is supported by the Linux Advanced Routing and
Traffic Control features.
o Last, but not least, current Linux kernels support the
configuration of RFC 4191 specific routes (by processing Route
Information Options contained in RAs). The kernel support can be
easily enabled by using the
net.conf.ipv6.*.accept_ra_rt_info_max_plen kernel configuration
parameter.
The DLIF concept is implemented by the Open Distributed Mobility
Management (ODMM) project (http://www.odmm.net/), as part of the
Mobility Anchors Distribution for PMIPv6 (MAD-PMIPv6). The ODMM
platform is intended to foster DMM development and deployment, by
serving as a framework to host open source implementations.
Appendix C. Public demonstrations
The DLIF concept has been demonstrated, together with the network-
based DMM solution described in [I-D.bernardos-dmm-pmip], during the
83rd IETF in Paris (March 2012) and the 87th IETF in Berlin (August
2013).
The first demo showcased a scenario composed of three "anchor
routers", a "centralized LMA" for control plane, a "mobile node" and
two "correspondent nodes" (one of them being a legacy IPv6 camera).
The mobile node could move between the different anchor routers,
getting a different locally anchor IPv6 address at each location, and
being the reachability of each address maintained.
In the second demo, integration with content delivery nodes (CDNs)
was also shown, showcasing the advantages that the use of a DMM
solution brings to this popular scenario. These concepts were
further explored in the EU project MEDIEVAL.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Bernardos & Zuniga Expires November 30, 2017 [Page 26]
Internet-Draft PMIPv6 distributed anchoring May 2017
Juan Carlos Zuniga
SIGFOX
425 rue Jean Rostand
Labege 31670
France
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Bernardos & Zuniga Expires November 30, 2017 [Page 27]
