Internet DRAFT - draft-bernardos-dmm-pmip
draft-bernardos-dmm-pmip
DMM Working Group CJ. Bernardos
Internet-Draft A. de la Oliva
Intended status: Standards Track UC3M
Expires: March 12, 2018 F. Giust
NEC
September 8, 2017
A PMIPv6-based solution for Distributed Mobility Management
draft-bernardos-dmm-pmip-09
Abstract
The number of mobile users and their traffic demand is expected to be
ever-increasing in future years, and this growth can represent a
limitation for deploying current mobility management schemes that are
intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6.
For this reason it has been waved a need for distributed and dynamic
mobility management approaches, with the objective of reducing
operators' burdens, evolving to a cheaper and more efficient
architecture.
This draft describes multiple solutions for network-based distributed
mobility management inspired by the well known Proxy Mobile IPv6.
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.
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 March 12, 2018.
Bernardos, et al. Expires March 12, 2018 [Page 1]
Internet-Draft A DMM solution for PMIPv6 September 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. Partially distributed solution . . . . . . . . . . . . . . . 4
3.1. Initial registration . . . . . . . . . . . . . . . . . . 6
3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 7
3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 9
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 10
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 11
3.6. Message Format . . . . . . . . . . . . . . . . . . . . . 11
3.6.1. Previous MAAR Option . . . . . . . . . . . . . . . . 11
3.6.2. Serving MAAR Option . . . . . . . . . . . . . . . . . 13
4. Fully distributed solution . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Comparison with Requirement document . . . . . . . . 15
A.1. Distributed mobility management . . . . . . . . . . . . . 15
A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . 16
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 16
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 16
A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 17
A.6. Operation and management considerations . . . . . . . . . 17
A.7. Security considerations . . . . . . . . . . . . . . . . . 17
A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Implementation experience . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Bernardos, et al. Expires March 12, 2018 [Page 2]
Internet-Draft A DMM solution for PMIPv6 September 2017
1. Introduction
Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two
most relevant examples, offer mobility support at the cost of
handling operations at a cardinal point, the mobility anchor, and
burdening it with data forwarding and control mechanisms for a great
amount of users. As stated in [RFC7333], centralized mobility
solutions are prone to several problems and limitations: longer (sub-
optimal) routing paths, scalability problems, signaling overhead (and
most likely a longer associated handover latency), more complex
network deployment, higher vulnerability due to the existence of a
potential single point of failure, and lack of granularity on the
mobility management service (i.e., mobility is offered on a per-node
basis, not being possible to define finer granularity policies, as
for example per-application).
The purpose of Distributed Mobility Management is to overcome the
limitations of the traditional centralized mobility management
[RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed
bringing the mobility anchor closer to the MN. Following this idea,
in our proposal, the central anchor is moved to the edge of the
network, being deployed in the default gateway of the mobile node.
That is, the first elements that provide IP connectivity to a set of
MNs are also the mobility managers for those MNs. In the following,
we will call these entities Mobility Anchor and Access Routers
(MAARs).
This document focuses on network-based DMM, hence the starting point
is making PMIPv6 working in a distributed manner [RFC7429]. In our
proposal, as in PMIPv6, mobility is handled by the network without
the MNs involvement, but, differently from PMIP, when the MN moves
from one access network to another, it also changes anchor router,
hence requiring signaling between the anchors to retrieve the MN's
previous location(s). Also, a key-aspect of network-based DMM, is
that a prefix pool belongs exclusively to each MAAR, in the sense
that those prefixes are assigned by the MAAR to the MNs attached to
it, and they are routable at that MAAR.
In the following, we consider two main approaches to design our DMM
solutions:
o Partially distributed schemes, where the data plane only is
distributed among access routers similar to MAGs, whereas the
control plane is kept centralized towards a cardinal node used as
information store, but relieved from any route management and MN's
data forwarding task.
Bernardos, et al. Expires March 12, 2018 [Page 3]
Internet-Draft A DMM solution for PMIPv6 September 2017
o Fully distributed schemes, where both data and control planes are
distributed among the access routers.
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 Acknowledgement (PBA)
The following terms are defined and used in this document:
MAAR (Mobility Anchor and Access Router). First hop router where the
mobile nodes attach to. It also plays the role of mobility
manager for the IPv6 prefixes it anchors, running the
functionalities of PMIP's MAG and LMA.
CMD (Central Mobility Database). Node that stores the BCEs allocated
for the MNs in the mobility domain.
P-MAAR (Previous MAAR). MAAR which was previously visited by the MN
and is still involved in an active flow using an IPv6 prefix it
has advertised to the MN (i.e., MAAR where that IPv6 prefix is
anchored). There might be multiple P-MAARs for an MN's mobility
session.
S-MAAR (Serving MAAR). MAAR which the MN is currently attached to.
3. Partially distributed solution
The following solution consists in de-coupling the entities that
participates in the data and the control planes: the data plane
becomes distributed and managed by the MAARs near the edge of the
network, while the control plane, besides on the MAARs, relies on a
central entity called Central Mobility Database (CMD). In the
Bernardos, et al. Expires March 12, 2018 [Page 4]
Internet-Draft A DMM solution for PMIPv6 September 2017
proposed architecture, the hierarchy present in PMIP between LMA and
MAG is preserved, but with the following substantial variations:
o The LMA is relieved from the data forwarding role, only the
Binding Cache and its management operations are maintained. Hence
the LMA is renamed into Central Mobility Database (CMD). Also,
the CMD is able to send and parse both PBU and PBA messages.
o The MAG is enriched with the LMA functionalities, hence the name
Mobility Anchor and Access Router (MAAR). It maintains a local
Binding Cache for the MNs that are attached to it and it is able
to send and parse PBU and PBA messages.
o The binding cache will have to be extended to include information
regarding previous MAARs where the mobile node was anchored and
still retains active data sessions, see Appendix B for further
details.
o Each MAAR has a unique set of global prefixes (which are
configurable), that can be allocated by the MAAR to the MNs, but
must be exclusive to that MAAR, i.e. no other MAAR can allocate
the same prefixes.
The MAARs leverage on the Central Mobility Database (CMD) to access
and update information related to the MNs, stored as mobility
sessions; hence, a centralized node maintains a global view on the
status of the network. The CMD is queried whenever a MN is detected
to join/leave the mobility domain. It might be a fresh attachment, a
detachment or a handover, but as MAARs are not aware of past
information related to a mobility session, they contact the CMD to
retrieve the data of interest and eventually take the appropriate
action. The procedure adopted for the query and the messages
exchange sequence might vary to optimize the update latency and/or
the signaling overhead. Here is presented one method for the initial
registration, and three different approaches to update the mobility
sessions using PBUs and PBAs. Each approach assigns a different role
to the CMD:
o The CMD is a PBU/PBA relay;
o The CMD is only a MAAR locator;
o The CMD is a PBU/PBA proxy.
Bernardos, et al. Expires March 12, 2018 [Page 5]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.1. Initial registration
Upon the MN's attachment to a MAAR, say MAAR1, if the MN is
authorized for the service, an IPv6 global prefix belonging to the
MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding
Cache Entry (BCE) allocated locally. The prefix is sent in a
[RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which,
since the session is new, stores a permanent BCE containing as main
fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA.
The CMD replies to MAAR1 with a PBA including the usual options
defined in PMIP/RFC5213, meaning that the MN's registration is fresh
and no past status is available. MAAR1 definitely stores the
temporal BCE previously allocated and unicasts a Router Advertisement
(RA) to the MN including the prefix reserved before, that can be used
by the MN to configure an IPv6 address (e.g., with stateless auto-
configuration). The address is routable at the MAAR, in the sense
that it is on the path of packets addressed to the MN. Moreover, the
MAAR acts as plain router for those packets, as no encapsulation nor
special handling takes place. Figure 1 illustrates this scenario.
+-----+ +---+ +--+
|MAAR1| |CMD| |CN|
+-----+ +---+ +*-+
| | *
MN | * +---+
attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \
| | * / | \
local BCE | * / | \
allocation | * / | \
|--- PBU -->| +---*-+-' +--+--+ `+-----+
| BCE | * | | | | |
| creation |MAAR1+------+MAAR2+-----+MAAR3|
|<-- PBA ---| | * | | | | |
local BCE | +---*-+ +-----+ +-----+
finalized | *
| | Pref1 *
| | +*-+
| | |MN|
| | +--+
Operations sequence Packets flow
Figure 1: First attachment to the network
Bernardos, et al. Expires March 12, 2018 [Page 6]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.2. The CMD as PBU/PBA relay
When the MN moves from its current access and associates to MAAR2
(now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it
stores a temporal BCE, and it sends a plain PBU to the CMD for
registration. Upon PBU reception and BC lookup, the CMD retrieves an
already existing entry for the MN, binding the MN-ID to its former
location; thus, the CMD forwards the PBU to the MAAR indicated as
Proxy CoA (MAAR1), including a new mobility option to communicate the
S-MAAR's global address to MAAR1, defined as Serving MAAR Option in
Section 3.6.2. The CMD updates the P-CoA field in the BCE related to
the MN with the S-MAAR's address.
Upon PBU reception, MAAR1 can install a tunnel on its side towards
MAAR2 and the related routes for Pref1. Then MAAR1 replies to the
CMD with a PBA (including the option mentioned before) to ensure that
the new location has successfully changed, containing the prefix
anchored at MAAR1 in the Home Network Prefix option. The CMD, after
receiving the PBA, updates the BCE populating an instance of the
P-MAAR list. The P-MAAR list is an additional field on the BCE that
contains an element for each P-MAAR involved in the MN's mobility
session. The list element contains the P-MAAR's global address and
the prefix it has delegated (see Appendix B for further details).
Also, the CMD send a PBA to the new S-MAAR, containing the previous
Proxy-CoA and the prefix anchored to it embedded into a new mobility
option called Previous MAAR Option (defined in Section 3.6.1), so
that, upon PBA arrival, a bi-directional tunnel can be established
between the two MAARs and new routes are set appropriately to recover
the IP flow(s) carrying Pref1.
Now packets destined to Pref1 are first received by MAAR1,
encapsulated into the tunnel and forwarded to MAAR2, which finally
delivers them to their destination. In uplink, when the MN transmits
packets using Pref1 as source address, they are sent to MAAR2, as it
is MN's new default gateway, then tunneled to MAAR1 which routes them
towards the next hop to destination. Conversely, packets carrying
Pref2 are routed by MAAR2 without any special packet handling both
for uplink and downlink. The procedure is depicted in Figure 2.
Bernardos, et al. Expires March 12, 2018 [Page 7]
Internet-Draft A DMM solution for PMIPv6 September 2017
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+
| | route ---move-->|*MN*|
| | update +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 2: Scenario after a handover, CMD as relay
For next MN's movements the process is repeated except for the number
of P-MAARs involved, that rises accordingly to the number of prefixes
that the MN wishes to maintain. Indeed, once the CMD receives the
first PBU from the new S-MAAR, it forwards copies of the PBU to all
the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR
prior to handover) and in the P-MAARs list. They reply with a PBA to
the CMD, which aggregates them into a single one to notify the
S-MAAR, that finally can establish the tunnels with the P-MAARs.
It should be noted that this design separates the mobility management
at the prefix granularity, and it can be tuned in order to erase old
mobility sessions when not required, while the MN is reachable
through the latest prefix acquired. Moreover, the latency associated
to the mobility update is bound to the PBA sent by the furthest
P-MAAR, in terms of RTT, that takes the longest time to reach the
CMD. The drawback can be mitigated introducing a timeout at the CMD,
by which, after its expiration, all the PBAs so far collected are
transmitted, and the remaining are sent later upon their arrival.
Bernardos, et al. Expires March 12, 2018 [Page 8]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.3. The CMD as MAAR locator
The handover latency experienced in the approach shown before can be
reduced if the P-MAARs are allowed to signal directly their
information to the new S-MAAR. This procedure reflect what was
described in Section 3.2 up to the moment the P-MAAR receives the PBU
with the P-MAAR option. At that point a P-MAAR is aware of the new
MN's location (because of the S-MAAR's address in the S-MAAR option),
and, besides sending a PBA to the CMD, it also sends a PBA to the
S-MAAR including the prefix it is anchoring. This latter PBA does
not need to include new options, as the prefix is embedded in the HNP
option and the P-MAAR's address OS taken from the message's source
address. The CMD is relieved from forwarding the PBA to the S-MAAR,
as the latter receives a copy directly from the P-MAAR with the
necessary information to build the tunnels and set the appropriate
routes. In Figure 3 is illustrated the new messages sequence, while
the data forwarding is unaltered.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * *
| BCE update Pref1 * *Pref2
| update | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 3: Scenario after a handover, CMD as locator
Bernardos, et al. Expires March 12, 2018 [Page 9]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.4. The CMD as MAAR proxy
A further enhancement of previous solutions can be achieved when the
CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of
the location change. Indeed, when the CMD receives the PBU for the
new registration, it is already in possess of all the information
that the new S-MAAR requires to set up the tunnels and the routes.
Thus the PBA is sent to the S-MAAR immediately after a PBU is
received, including also in this case the P-MAAR option. In
parallel, a PBU is sent by the CMD to the P-MAARs containing the
S-MAAR option, to notify them about the new MN's location, so they
receive the information to establish the tunnels and routes on their
side. When P-MAARs complete the update, they send a PBA to the CMD
to indicate that the operation is concluded and the information are
updated in all network nodes. This procedure is obtained from the
first one re-arranging the order of the messages, but the parameters
communicated are the same. This scheme is depicted in Figure 4,
where, again, the data forwarding is kept untouched.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| | | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 4: Scenario after a handover, CMD as proxy
Bernardos, et al. Expires March 12, 2018 [Page 10]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.5. De-registration
The de-registration mechanism devised for PMIPv6 is no longer valid
in the Partial DMM architecture. This is motivated by the fact that
each MAAR handles an independent mobility session (i.e., a single or
a set of prefixes) for a given MN, whereas the aggregated session is
stored at the CMD. Indeed, when a previous MAAR initiates a de-
registration procedure, because the MN is no longer present on the
MAAR's access link, it removes the routing state for that (those)
prefix(es), that would be deleted by the CMD as well, hence defeating
any prefix continuity attempt. The simplest approach to overcome
this limitation is to deny an old MAAR to de-register a prefix, that
is, allowing only a serving MAAR to de-register the whole MN session.
This can be achieved by first removing any layer-2 detachment event,
so that de-registration is triggered only when the session lifetime
expires, hence providing a guard interval for the MN to connect to a
new MAAR. Then, a change in the MAAR operations is required, and at
this stage two possible solutions can be deployed:
o A previous MAAR stops the BCE timer upon receiving a PBU from the
CMD containing a "Serving MAAR" option. In this way only the
Serving MAAR is allowed to de-register the mobility session,
arguing that the MN left definitely the domain.
o Previous MAARs can, upon BCE expiry, send de-registration messages
to the CMD, which, instead of acknowledging the message with a 0
lifetime, send back a PBA with a non-zero lifetime, hence re-
newing the session, if the MN is still connected to the domain.
The evaluation of these methods is left for future work.
3.6. Message Format
This section defines two Mobility Options to be used in the PBU and
PBA messages:
Previous MAAR Option;
Serving MAAR Option.
In the current draft the messages reflect IPv6 format only. IPv4
compatibility will be added in next release.
3.6.1. Previous MAAR Option
This new option is defined for use with the Proxy Binding
Acknowledgement messages exchanged by the CMD to a MAAR. This option
is used to notify the S-MAAR about the previous MAAR's global address
Bernardos, et al. Expires March 12, 2018 [Page 11]
Internet-Draft A DMM solution for PMIPv6 September 2017
and the prefix anchored to it. There can be multiple Previous MAAR
options present in the message. 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 | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ P-MAAR's address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network 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 34.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Previous MAAR's address
A sixteen-byte field containing the P-MAAR's IPv6 global address.
Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix.
Bernardos, et al. Expires March 12, 2018 [Page 12]
Internet-Draft A DMM solution for PMIPv6 September 2017
3.6.2. Serving MAAR Option
This new option is defined for use with the Proxy Binding Update and
Proxy Binding Acknowledgement messages exchanged between the CMD and
a Previous MAAR. This option is used to notify the P-MAAR about the
current Serving MAAR's global address. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ S-MAAR's 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.
Serving MAAR's address
A sixteen-byte field containing the S-MAAR's IPv6 global address.
4. Fully distributed solution
In this section we introduce the guidelines to evolve our partially
DMM solution into a fully distributed one. We list the key concepts
in the following (some of the points are already enforced in previous
sections of this document):
o All MAARs have a pool of global routable IPv6 prefixes to be
assigned to MNs on the access link.
Bernardos, et al. Expires March 12, 2018 [Page 13]
Internet-Draft A DMM solution for PMIPv6 September 2017
o Any central control entity is removed from the architecture and
each MAAR will retain it's own cache for the mobile nodes directly
anchored to it.
o Both control and data planes are now entirely handled by the
MAARs.
Because we aim for a fully distributed approach, the lack of
knowledge of other MAARs and their advertised prefixes becomes a
serious obstacle. In this particular case, when a MN attaches to a
MAAR, there are two main pieces ofi nformation that this MAAR
requires to know, to properly assure a mobile node's mobility and
continuity of its data flows: i) if the node has any P-MAARs and
their addresses; ii) if it has P-MAARs, which prefixes were
advertised by which MAAR.
There are several methods to achieve this:
o Make before approaches, employing Layer 2 or Layer 3 mechanisms.
The target MAAR is known in advance by the current MAAR before
handover, hence the mobility context can be transferred.
o Distributed schemes for MAAR discovery: it can based on a peer-to-
peer approach; or it can employ a unicast, multicast or broadcast
query system.
o Explicit notification by the MN. For example, extending the layer
three IP address configuration mechanisms (e.g., ND).
o Other MN to MAAR communication protocol (e.g., IEEE 802.21).
5. IANA Considerations
TBD.
6. Security Considerations
The solution assumes that the nodes are trusted and secure MAAR-to-
MAAR communications are in place, for instance re-using the security
mechanisms defined for PMIPv6. Thus, the solution does not introduce
any new security vulnerability.
7. Acknowledgments
The authors would like to thank Marco Liebsch for his comments and
discussion on this document.
Bernardos, et al. Expires March 12, 2018 [Page 14]
Internet-Draft A DMM solution for PMIPv6 September 2017
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, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
8.2. Informative References
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-09
(work in progress), May 2017.
[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,
<https://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, <https://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].
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."
Bernardos, et al. Expires March 12, 2018 [Page 15]
Internet-Draft A DMM solution for PMIPv6 September 2017
In our solution, a MAAR 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 MAAR's access links, the IP packets of
such flows can benefit from the optimal path. When the MN moves to
another MAAR, the path becomes non-optimal for ongoing flows, as they
are anchored to the previous MAAR, but newly started IP sessions are
forwarded by the new MAAR 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."
Our DMM 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 old MAAR. 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.
A.3. IPv6 deployment
"DMM solutions SHOULD target IPv6 as the primary deployment
environment and SHOULD NOT be tailored specifically to support IPv4,
particularly in situations where private IPv4 addresses and/or NATs
are used."
The DMM solution we propose targets IPv6 only.
A.4. Existing mobility protocols
"A DMM solution MUST first consider reusing and extending IETF
standard protocols before specifying new protocols."
Bernardos, et al. Expires March 12, 2018 [Page 16]
Internet-Draft A DMM solution for PMIPv6 September 2017
This DMM solution 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 partially DMM solution can be extended to provide a fallback
mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to
instruct MAARs to always establish a tunnel with the same MAAR,
working as LMA. The fully DMM solution can be extended as well, but
it requires more intervention. The partially DMM solution can be
deployed across different domains with trust agreements if the CMDs
ot the operators are enabled to transfer context from one node to
another. The fully DMM solution works across multiple domains if
both solution apply the same signalling scheme.
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
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.
Bernardos, et al. Expires March 12, 2018 [Page 17]
Internet-Draft A DMM solution for PMIPv6 September 2017
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 network-based DMM solution described in section Section 3.4 is
now available at the Open Distributed Mobility Management (ODMM)
project (http://www.odmm.net/), under the name of 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.
The MAD-PMIPv6 code is developed in ANSI C from the existing UMIP
implementation for PMIP. The most relevant changes with respect to
the UMIP original version are related to how to create the CMD and
MAAR's state machines from those of an LMA and a MAG; for this
purpose, part of the LMA code was copied to the MAG, in order to send
PBA messages and parse PBU. Also, the LMA routing functions were
removed completely, and moved to the MAG, because MAARs need to route
through the tunnels in downlink (as an LMA) and in uplink (as a MAG).
Tunnel management is hence a relevant technical aspect, as multiple
tunnels are established by a single MAAR, which keeps their status
directly into the MN's BCE. Indeed, from the implementation
experience it was chosen to create an ancillary data structure as
field within a BCE: the data structure is called "MAAR list" and
stores the previous MAARs' address and the corresponding prefix(es)
assigned for the MN. Only the CMD and the serving MAAR store this
data structure, because the CMD maintains the global MN's mobility
session formed during the MN's roaming within the domain, and the
serving MAAR needs to know which previous MAARs were visited, the
prefix(es) they assigned and the tunnels established with them.
Conversely, a previous MAAR only needs to know which is the current
Serving MAAR and establish a single tunnel with it. For this reason,
a MAAR that receives a PBU from the CMD (meaning that the MN attached
to another MAAR), first sets up the routing state for the MN's
prefix(es) it is anchoring, then stop the BCE expiry timer and
deletes the MAAR list (if present) since it is no longer useful.
In order to have the MN totally unaware of the changes in the access
link, all MAARs implement the Distributed Logical Interface (DLIF)
concept devised in [I-D.bernardos-dmm-distributed-anchoring].
Moreover, it should be noted that the protocols designed in the
Bernardos, et al. Expires March 12, 2018 [Page 18]
Internet-Draft A DMM solution for PMIPv6 September 2017
document work only at the network layer to handle the MNs joining or
leaving the domain. This should guarantee a certain independency to
a particular access technology. The implementation reflects this
reasoning, but we argue that an interaction with lower layers
produces a more effective attachment and detachment detection,
therefore improving the performance, also regarding de-registration
mechanisms.
It was chosen to implement the "proxy" solution because it produces
the shortest handover latency, but a slight modification on the CMD
state machine can produce the first scenario described ("relay")
which guarantees a more consistent request/ack scheme between the
MAARS. By modifying also the MAAR's state machine it can be
implemented the second solution ("locator").
An early MAD-PMIPv6 implementation was shown during a demo session at
the IETF 83rd, in Paris in March 2012. An enhancement version of the
prototype has been presented at the 87th IETF meeting in Berlin, July
2013. The updated demo included a use case scenario employing a CDN
system for video delivery. More, MAD-PMIPv6 has been extensively
used and evaluated within a testbed employing heterogeneous radio
accesses within the framework of the MEDIEVAL EU project. MAD-PMIPv6
software is currently part of a DMM test-bed comprising 3 MAARs, one
CMD, one MN and a CN. All the machines used in the demos were Linux
UBUNTU 10.04 systems with kernel 2.6.32, but the prototype has been
tested also under newer systems. This testbed was also used by the
iJOIN EU project.
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, et al. Expires March 12, 2018 [Page 19]
Internet-Draft A DMM solution for PMIPv6 September 2017
Antonio de la Oliva
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8803
Email: aoliva@it.uc3m.es
URI: http://www.it.uc3m.es/aoliva/
Fabio Giust
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg D-69115
Germany
Phone: +49 6221 4342216
Email: fabio.giust@neclab.eu
Bernardos, et al. Expires March 12, 2018 [Page 20]
