draft-ietf-dmm-pmipv6-dlif-00.txt   draft-ietf-dmm-pmipv6-dlif-01.txt 
DMM Working Group CJ. Bernardos DMM Working Group CJ. Bernardos
Internet-Draft A. de la Oliva Internet-Draft A. de la Oliva
Intended status: Standards Track UC3M Intended status: Standards Track UC3M
Expires: October 20, 2018 F. Giust Expires: December 31, 2018 F. Giust
NEC NEC
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
A. Mourad A. Mourad
InterDigital InterDigital
April 18, 2018 June 29, 2018
Proxy Mobile IPv6 extensions for Distributed Mobility Management Proxy Mobile IPv6 extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-00 draft-ietf-dmm-pmipv6-dlif-01
Abstract Abstract
Distributed Mobility Management solutions allow for setting up Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does networks so that traffic is distributed in an optimal way and does
not rely on centralized deployed anchors to provide IP mobility not rely on centralized deployed anchors to provide IP mobility
support. support.
There are many different approaches to address Distributed Mobility There are many different approaches to address Distributed Mobility
Management, as for example extending network-based mobility protocols Management, as for example extending network-based mobility protocols
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Mobile IPv6), among others. This document follows the former Mobile IPv6), among others. This document follows the former
approach, and proposes a solution based on Proxy Mobile IPv6 in which approach, and proposes a solution based on Proxy Mobile IPv6 in which
mobility sessions are anchored at the last IP hop router (called mobility sessions are anchored at the last IP hop router (called
mobility anchor and access router). The mobility anchor and access mobility anchor and access router). The mobility anchor and access
router is an enhanced access router which is also able to operate as router is an enhanced access router which is also able to operate as
local mobility anchor or mobility access gateway, on a per prefix local mobility anchor or mobility access gateway, on a per prefix
basis. The document focuses on the required extensions to basis. The document focuses on the required extensions to
effectively support simultaneously anchoring several flows at effectively support simultaneously anchoring several flows at
different distributed gateways. different distributed gateways.
This document introduces the concept of distributed logical
interface, which is a software construct that allows to easily hide
the change of anchor from the mobile node.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 20 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2018. This Internet-Draft will expire on December 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PMIPv6 DMM extenstions . . . . . . . . . . . . . . . . . . . 5 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5
3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7
3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8
3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12
3.6. The Distributed Logical Interface (DLIF) concept . . . . 12 3.6. The Distributed Logical Interface (DLIF) concept . . . . 12
3.7. Message Format . . . . . . . . . . . . . . . . . . . . . 16 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16
3.7.1. Proxy Binding Update . . . . . . . . . . . . . . . . 16 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 16
3.7.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 17 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 17
3.7.3. Anchored Prefix Option . . . . . . . . . . . . . . . 17 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 17
3.7.4. Local Prefix Option . . . . . . . . . . . . . . . . . 18 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 18
3.7.5. Previous MAAR Option . . . . . . . . . . . . . . . . 19 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 19
3.7.6. Serving MAAR Option . . . . . . . . . . . . . . . . . 21 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 21
3.7.7. DLIF Link-local Address Option . . . . . . . . . . . 21 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 21
3.7.8. DLIF Link-layer Address Option . . . . . . . . . . . 22 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Comparison with Requirement document . . . . . . . . 25 Appendix A. Comparison with Requirement document . . . . . . . . 25
A.1. Distributed mobility management . . . . . . . . . . . . . 25 A.1. Distributed mobility management . . . . . . . . . . . . . 25
A.2. Bypassable network-layer mobility support for each A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . . . . . . 26 application session . . . . . . . . . . . . . . . . . . . 26
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26
A.5. Coexistence with deployed networks/hosts and operability A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 27 across different networks . . . . . . . . . . . . . . . . 27
A.6. Operation and management considerations . . . . . . . . . 27 A.6. Operation and management considerations . . . . . . . . . 27
A.7. Security considerations . . . . . . . . . . . . . . . . . 27 A.7. Security considerations . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 38 skipping to change at page 3, line 31
1. Introduction 1. Introduction
The Distributed Mobility Management (DMM) paradigm aims at minimizing The Distributed Mobility Management (DMM) paradigm aims at minimizing
the impact of currently standardized mobility management solutions, the impact of currently standardized mobility management solutions,
which are centralized (at least to a considerable extent). which are centralized (at least to a considerable extent).
Current IP mobility solutions, standardized with the names of Mobile Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two
most relevant examples, offer mobility support at the cost of most relevant examples, offer mobility support at the cost of
handling operations at a cardinal point, the mobility anchor, and handling operations at a cardinal point, the mobility anchor (i.e.,
burdening it with data forwarding and control mechanisms for a great the home agent for Mobile IPv6, and the local mobility anchor for
amount of users. As stated in [RFC7333], centralized mobility Proxy Mobile IPv6), and burdening it with data forwarding and control
solutions are prone to several problems and limitations: longer (sub- mechanisms for a great amount of users. As stated in [RFC7333],
optimal) routing paths, scalability problems, signaling overhead (and centralized mobility solutions are prone to several problems and
most likely a longer associated handover latency), more complex limitations: longer (sub-optimal) routing paths, scalability
network deployment, higher vulnerability due to the existence of a problems, signaling overhead (and most likely a longer associated
potential single point of failure, and lack of granularity on the handover latency), more complex network deployment, higher
mobility management service (i.e., mobility is offered on a per-node vulnerability due to the existence of a potential single point of
basis, not being possible to define finer granularity policies, as failure, and lack of granularity on the mobility management service
for example per-application). (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 The purpose of Distributed Mobility Management is to overcome the
limitations of the traditional centralized mobility management limitations of the traditional centralized mobility management
[RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed
bringing the mobility anchor closer to the MN. Following this idea, bringing the mobility anchor closer to the MN. Following this idea,
in our proposal, the central anchor is moved to the edge of the in our proposal, the central anchor is moved to the edge of the
network, being deployed in the default gateway of the mobile node. network, being deployed in the default gateway of the mobile node.
That is, the first elements that provide IP connectivity to a set of 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, MNs are also the mobility managers for those MNs. In the following,
we will call these entities Mobility Anchor and Access Routers we will call these entities Mobility Anchor and Access Routers
(MAARs). (MAARs).
This document focuses on network-based DMM, hence the starting point This document focuses on network-based DMM, hence the starting point
skipping to change at page 5, line 22 skipping to change at page 5, line 15
The following terms are defined and used in this document: The following terms are defined and used in this document:
MAAR (Mobility Anchor and Access Router). First hop router where the MAAR (Mobility Anchor and Access Router). First hop router where the
mobile nodes attach to. It also plays the role of mobility mobile nodes attach to. It also plays the role of mobility
manager for the IPv6 prefixes it anchors, running the manager for the IPv6 prefixes it anchors, running the
functionalities of PMIP's MAG and LMA. Depending on the prefix, functionalities of PMIP's MAG and LMA. Depending on the prefix,
it plays the role of Access-DPN, Home-DPA and Access-CPN. it plays the role of Access-DPN, Home-DPA and Access-CPN.
CMD (Central Mobility Database). Node that stores the BCEs allocated CMD (Central Mobility Database). Node that stores the BCEs allocated
for the MNs in the mobility domain. It plays the role of Home- for the MNs in the mobility domain. It plays the role of H-CPA.
CPA.
P-MAAR (Previous MAAR). MAAR which was previously visited by the MN 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 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 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 anchored). There might be multiple P-MAARs for an MN's mobility
session. It plays the role of Home-DPA. session. It plays the role of Home-DPA.
S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. S-MAAR (Serving MAAR). MAAR which the MN is currently attached to.
Depending on the prefix, it plays the role of Access-DPN, Home-DPA Depending on the prefix, it plays the role of Access-DPN, Home-DPA
and Access-CPN. and Access-CPN.
DLIF (Distributed Logical Interface). It is a logical interface at DLIF (Distributed Logical Interface). It is a logical interface at
the IP stack of the MAAR. For each active prefix used by the the IP stack of the MAAR. For each active prefix used by the
mobile node, the serving MAAR has a DLIF configured (associated to mobile node, the serving MAAR has a DLIF configured (associated to
the anchoring MAAR). In this way, a serving MAAR exposes itself the anchoring MAAR). In this way, a serving MAAR exposes itself
towards each MN as multiple routers, one per active anchoring towards each MN as multiple routers, one per active anchoring
MAAR. MAAR.
3. PMIPv6 DMM extenstions 3. PMIPv6 DMM extensions
The solution consists in de-coupling the entities that participates The solution consists in de-coupling the entities that participate in
in the data and the control planes: the data plane becomes the data and the control planes: the data plane becomes distributed
distributed and managed by the MAARs near the edge of the network, and managed by the MAARs near the edge of the network, while the
while the control plane, besides on the MAARs, relies on a central control plane, besides on the MAARs, relies on a central entity
entity called Central Mobility Database (CMD). In the proposed called Central Mobility Database (CMD). In the proposed
architecture, the hierarchy present in PMIPv6 between LMA and MAG is architecture, the hierarchy present in PMIPv6 between LMA and MAG is
preserved, but with the following substantial variations: preserved, but with the following substantial variations:
o The LMA is relieved from the data forwarding role, only the o The LMA is relieved from the data forwarding role, only the
Binding Cache and its management operations are maintained. Hence Binding Cache and its management operations are maintained. Hence
the LMA is renamed into Central Mobility Database (CMD), which is the LMA is renamed into Central Mobility Database (CMD), which is
therefore a Home-CPA. Also, the CMD is able to send and parse therefore an H-CPA. Also, the CMD is able to send and parse both
both PBU and PBA messages. PBU and PBA messages.
o The MAG is enriched with the LMA functionalities, hence the name o The MAG is enriched with the LMA functionalities, hence the name
Mobility Anchor and Access Router (MAAR). It maintains a local Mobility Anchor and Access Router (MAAR). It maintains a local
Binding Cache for the MNs that are attached to it and it is able Binding Cache for the MNs that are attached to it and it is able
to send and parse PBU and PBA messages. to send and parse PBU and PBA messages.
o The binding cache will have to be extended to include information o The binding cache will have to be extended to include information
regarding previous MAARs where the mobile node was anchored and regarding previous MAARs where the mobile node was anchored and
still retains active data sessions, see Appendix B for further still retains active data sessions, see Appendix B for further
details. details.
skipping to change at page 7, line 7 skipping to change at page 6, line 46
o The CMD is a PBU/PBA proxy. o The CMD is a PBU/PBA proxy.
This solution can be categorized under Model-1: Split Home Anchor This solution can be categorized under Model-1: Split Home Anchor
Mode in [I-D.ietf-dmm-deployment-models]. As another note, the Mode in [I-D.ietf-dmm-deployment-models]. As another note, the
solution described in this document allows performing per-prefix solution described in this document allows performing per-prefix
anchoring decisions, to support e.g., some flows to be anchored at a anchoring decisions, to support e.g., some flows to be anchored at a
central Home-DPA (like a traditional LMA) or to enable an application central Home-DPA (like a traditional LMA) or to enable an application
to switch to the locally anchored prefix to gain route optimization, to switch to the locally anchored prefix to gain route optimization,
as indicated in [I-D.ietf-dmm-ondemand-mobility]. as indicated in [I-D.ietf-dmm-ondemand-mobility].
Note that an MN MAY move across diferent MAARs, which might involve
that several P-MAARs exist at a given moment of time, each of them
anchoring a prefix used by the MN.
3.1. Initial registration 3.1. Initial registration
Upon the MN's attachment to a MAAR, say MAAR1, if the MN is 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 authorized for the service, an IPv6 global prefix belonging to the
MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding MAAR's prefix pool is reserved for it (Pref1) into a temporary
Cache Entry (BCE) allocated locally. The prefix is sent in a 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, [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 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. 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 The CMD replies to MAAR1 with a PBA including the usual options
defined in PMIP/RFC5213, meaning that the MN's registration is fresh defined in PMIP/RFC5213, meaning that the MN's registration is fresh
and no past status is available. MAAR1 definitely stores the and no past status is available. MAAR1 definitely stores the
temporal BCE previously allocated and unicasts a Router Advertisement temporary BCE previously allocated and unicasts a Router
(RA) to the MN including the prefix reserved before, that can be used Advertisement (RA) to the MN including the prefix reserved before,
by the MN to configure an IPv6 address (e.g., with stateless auto- that can be used by the MN to configure an IPv6 address (e.g., with
configuration). The address is routable at the MAAR, in the sense stateless auto-configuration, SLAAC). Alternative IPv6 auto-
that it is on the path of packets addressed to the MN. Moreover, the configuration mechanisms can also be used, though this document
MAAR acts as plain router for those packets, as no encapsulation nor describe the SLAAC-based one. The address is routable at the MAAR,
special handling takes place. Figure 1 illustrates this scenario. 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| |MAAR1| |CMD| |CN|
+-----+ +---+ +*-+ +-----+ +---+ +*-+
| | * | | *
MN | * +---+ MN | * +---+
attach. | ***** _|CMD|_ attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \ detection | flow1 * / +-+-+ \
| | * / | \ | | * / | \
local BCE | * / | \ local BCE | * / | \
skipping to change at page 8, line 9 skipping to change at page 8, line 9
| | +--+ | | +--+
Operations sequence Packets flow Operations sequence Packets flow
Figure 1: First attachment to the network Figure 1: First attachment to the network
3.2. The CMD as PBU/PBA relay 3.2. The CMD as PBU/PBA relay
When the MN moves from its current access and associates to MAAR2 When the MN moves from its current access and associates to MAAR2
(now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it (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 stores a temporary BCE, and it sends a plain PBU to the CMD for
registration. Upon PBU reception and BC lookup, the CMD retrieves an registration. Upon PBU reception and BC lookup, the CMD retrieves an
already existing entry for the MN, binding the MN-ID to its former 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 location; thus, the CMD forwards the PBU to the MAAR indicated as
Proxy CoA (MAAR1), including a new mobility option to communicate the Proxy CoA (MAAR1), including a new mobility option to communicate the
S-MAAR's global address to MAAR1, defined as Serving MAAR Option in S-MAAR's global address to MAAR1, defined as Serving MAAR Option in
Section 3.7.6. The CMD updates the P-CoA field in the BCE related to Section 4.6. The CMD updates the P-CoA field in the BCE related to
the MN with the S-MAAR's address. the MN with the S-MAAR's address.
Upon PBU reception, MAAR1 can install a tunnel on its side towards Upon PBU reception, MAAR1 can install a tunnel on its side towards
MAAR2 and the related routes for Pref1. Then MAAR1 replies to the MAAR2 and the related routes for Pref1. Then MAAR1 replies to the
CMD with a PBA (including the option mentioned before) to ensure that CMD with a PBA (including the option mentioned before) to ensure that
the new location has successfully changed, containing the prefix the new location has successfully changed, containing the prefix
anchored at MAAR1 in the Home Network Prefix option. The CMD, after anchored at MAAR1 in the Home Network Prefix option. The CMD, after
receiving the PBA, updates the BCE populating an instance of the 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 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 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 session. The list element contains the P-MAAR's global address and
the prefix it has delegated (see Appendix B for further details). 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 Also, the CMD sends a PBA to the new S-MAAR, containing the previous
Proxy-CoA and the prefix anchored to it embedded into a new mobility Proxy-CoA and the prefix anchored to it embedded into a new mobility
option called Previous MAAR Option (defined in Section 3.7.5), so option called Previous MAAR Option (defined in Section 4.5), so that,
that, upon PBA arrival, a bi-directional tunnel can be established upon PBA arrival, a bi-directional tunnel can be established between
between the two MAARs and new routes are set appropriately to recover the two MAARs and new routes are set appropriately to recover the IP
the IP flow(s) carrying Pref1. flow(s) carrying Pref1.
Now packets destined to Pref1 are first received by MAAR1, Now packets destined to Pref1 are first received by MAAR1,
encapsulated into the tunnel and forwarded to MAAR2, which finally encapsulated into the tunnel and forwarded to MAAR2, which finally
delivers them to their destination. In uplink, when the MN transmits delivers them to their destination. In uplink, when the MN transmits
packets using Pref1 as source address, they are sent to MAAR2, as it 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 is MN's new default gateway, then tunneled to MAAR1 which routes them
towards the next hop to destination. Conversely, packets carrying towards the next hop to destination. Conversely, packets carrying
Pref2 are routed by MAAR2 without any special packet handling both Pref2 are routed by MAAR2 without any special packet handling both
for uplink and downlink. The procedure is depicted in Figure 2. for uplink and downlink. The procedure is depicted in Figure 2.
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+ | update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | | |<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3| route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | | update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+ |--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * * | BCE | * *
| update | Pref1 * *Pref2 | update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+ | |--- PBA*-->| +*--*+
| | route ---move-->|*MN*| | | route ---move-->|*MN*|
| | update +----+ | | update +----+
Operations sequence Data Packets flow Operations sequence Data Packets flow
PBU/PBA Messages with * contain PBU/PBA Messages with * contain
a new mobility option a new mobility option
Figure 2: Scenario after a handover, CMD as relay Figure 2: Scenario after a handover, CMD as relay
For next MN's movements the process is repeated except for the number 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 of P-MAARs involved, that rises accordingly to the number of prefixes
that the MN wishes to maintain. Indeed, once the CMD receives the 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 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 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 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 the CMD, which aggregates them into a single one to notify the
skipping to change at page 10, line 9 skipping to change at page 10, line 9
to the mobility update is bound to the PBA sent by the furthest 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 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, CMD. The drawback can be mitigated introducing a timeout at the CMD,
by which, after its expiration, all the PBAs so far collected are by which, after its expiration, all the PBAs so far collected are
transmitted, and the remaining are sent later upon their arrival. transmitted, and the remaining are sent later upon their arrival.
3.3. The CMD as MAAR locator 3.3. The CMD as MAAR locator
The handover latency experienced in the approach shown before can be The handover latency experienced in the approach shown before can be
reduced if the P-MAARs are allowed to signal directly their reduced if the P-MAARs are allowed to signal directly their
information to the new S-MAAR. This procedure reflect what was information to the new S-MAAR. This procedure reflects what was
described in Section 3.2 up to the moment the P-MAAR receives the PBU 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 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), 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 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 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 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 option and the P-MAAR's address is taken from the message's source
address. The CMD is relieved from forwarding the PBA to the S-MAAR, 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 as the latter receives a copy directly from the P-MAAR with the
necessary information to build the tunnels and set the appropriate necessary information to build the tunnels and set the appropriate
routes. In Figure 3 is illustrated the new messages sequence, while routes. In Figure 3 is illustrated the new messages sequence, while
the data forwarding is unaltered. the data forwarding is unaltered.
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+ | update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | | |<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3| route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | | update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+ |--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * * |--- PBA*-->| route * *
| BCE update Pref1 * *Pref2 | BCE update Pref1 * *Pref2
| update | +*--*+ | update | +*--*+
| | | ---move-->|*MN*| | | | ---move-->|*MN*|
| | | +----+ | | | +----+
Operations sequence Data Packets flow Operations sequence Data Packets flow
PBU/PBA Messages with * contain PBU/PBA Messages with * contain
a new mobility option a new mobility option
Figure 3: Scenario after a handover, CMD as locator Figure 3: Scenario after a handover, CMD as locator
3.4. The CMD as MAAR proxy 3.4. The CMD as MAAR proxy
A further enhancement of previous solutions can be achieved when the 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 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 the location change. Indeed, when the CMD receives the PBU for the
new registration, it is already in possess of all the information new registration, it is already in possession of all the information
that the new S-MAAR requires to set up the tunnels and the routes. 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 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 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 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 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 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 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 to indicate that the operation is concluded and the information are
updated in all network nodes. This procedure is obtained from the updated in all network nodes. This procedure is obtained from the
first one re-arranging the order of the messages, but the parameters first one re-arranging the order of the messages, but the parameters
skipping to change at page 11, line 34 skipping to change at page 11, line 34
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+ | update | +---*-+-' +--+-*+ `+-----+
|<-- PBU*---x--- PBA*-->| | * | | *| | | |<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3| route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | | update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+ |--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * * | BCE | * *
| update | Pref1 * *Pref2 | update | Pref1 * *Pref2
| | | +*--*+ | | | +*--*+
| | | ---move-->|*MN*| | | | ---move-->|*MN*|
| | | +----+ | | | +----+
Operations sequence Data Packets flow Operations sequence Data Packets flow
PBU/PBA Messages with * contain PBU/PBA Messages with * contain
a new mobility option a new mobility option
Figure 4: Scenario after a handover, CMD as proxy Figure 4: Scenario after a handover, CMD as proxy
3.5. De-registration 3.5. De-registration
The de-registration mechanism devised for PMIPv6 is no longer valid The de-registration mechanism devised for PMIPv6 cannot be used as is
in the Partial DMM architecture. This is motivated by the fact that in this solution. This is motivated by the fact that each MAAR
each MAAR handles an independent mobility session (i.e., a single or handles an independent mobility session (i.e., a single or a set of
a set of prefixes) for a given MN, whereas the aggregated session is prefixes) for a given MN, whereas the aggregated session is stored at
stored at the CMD. Indeed, when a previous MAAR initiates a de- the CMD. Indeed, when a previous MAAR initiates a de-registration
registration procedure, because the MN is no longer present on the procedure, because the MN is no longer present on the MAAR's access
MAAR's access link, it removes the routing state for that (those) link, it removes the routing state for that (those) prefix(es), that
prefix(es), that would be deleted by the CMD as well, hence defeating would be deleted by the CMD as well, hence defeating any prefix
any prefix continuity attempt. The simplest approach to overcome continuity attempt. The simplest approach to overcome this
this limitation is to deny an old MAAR to de-register a prefix, that limitation is to deny an old MAAR to de-register a prefix, that is,
is, allowing only a serving MAAR to de-register the whole MN session. allowing only a serving MAAR to de-register the whole MN session.
This can be achieved by first removing any layer-2 detachment event, This can be achieved by first removing any layer-2 detachment event,
so that de-registration is triggered only when the session lifetime so that de-registration is triggered only when the session lifetime
expires, hence providing a guard interval for the MN to connect to a 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 new MAAR. Then, a change in the MAAR operations is required, and at
this stage two possible solutions can be deployed: this stage two possible solutions can be deployed:
o A previous MAAR stops the BCE timer upon receiving a PBU from the 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 CMD containing a "Serving MAAR" option. In this way only the
Serving MAAR is allowed to de-register the mobility session, Serving MAAR is allowed to de-register the mobility session,
arguing that the MN left definitely the domain. arguing that the MN left definitely the domain.
skipping to change at page 12, line 41 skipping to change at page 12, line 41
lifetime, send back a PBA with a non-zero lifetime, hence re- lifetime, send back a PBA with a non-zero lifetime, hence re-
newing the session, if the MN is still connected to the domain. newing the session, if the MN is still connected to the domain.
The evaluation of these methods is left for future work. The evaluation of these methods is left for future work.
3.6. The Distributed Logical Interface (DLIF) concept 3.6. The Distributed Logical Interface (DLIF) concept
One of the main challenges of a network-based DMM solution is how to 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 allow a mobile node to simultaneously send/receive traffic which is
anchored at different MAARs, and how to influence on the preference anchored at different MAARs, and how to influence on the preference
of the mobile selecting the source IPv6 address for a new of the mobile node selecting the source IPv6 address for a new
communication, without requiring special support on the mobile node communication, without requiring special support on the mobile node
stack. This document defines the Distributed Logical Interface stack. This document defines the Distributed Logical Interface
(DLIF), which is a software construct that allows to easily hide the (DLIF), which is a software construct that allows to easily hide the
change of anchor from the mobile node. change of anchor from the mobile node.
+---------------------------------------------------+ +---------------------------------------------------+
( Operator's ) ( Operator's )
( core ) ( core )
+---------------------------------------------------+ +---------------------------------------------------+
| | | |
skipping to change at page 13, line 47 skipping to change at page 13, line 47
role of anchoring and serving MAAR, and also it behaves as a plain role of anchoring and serving MAAR, and also it behaves as a plain
IPv6 access router. MAAR1 creates a distributed logical interface to IPv6 access router. MAAR1 creates a distributed logical interface to
communicate (point-to-point link) with MN1, exposing itself as a 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 (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and
IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64)
using the DLIF mn1mar1. As explained below, these addresses using the DLIF mn1mar1. As explained below, these addresses
represent the "logical" identity of MAAR1 towards MN1, and will represent the "logical" identity of MAAR1 towards MN1, and will
"follow" the mobile node while roaming within the domain (note that "follow" the mobile node while roaming within the domain (note that
the place where all this information is maintained and updated is 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 out-of-scope of this draft; potential examples are to keep it on the
HSS or the user's profile). home subscriber server -- HSS -- or the user's profile).
If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in
the example of Figure 5), this MAAR will create a new logical the example of Figure 5), this MAAR will create a new logical
interface (mn1mar2) to expose itself towards MN1, providing it with a interface (mn1mar2) to expose itself towards MN1, providing it with a
locally anchored prefix (prefB::/64). In this case, since the MN1 locally anchored prefix (prefB::/64). In this case, since the MN1
has another active IPv6 address anchored at a MAAR1, MAAR2 also needs has another active IPv6 address anchored at a MAAR1, MAAR2 also needs
to create an additional logical interface configured to exactly to create an additional logical interface configured to exactly
resemble the one used by MAAR1 to communicate with MN1. In this resemble the one used by MAAR1 to communicate with MN1. In this
example, there is only one active anchoring MAAR (in addition to example, there is only one active anchoring MAAR (in addition to
MAAR2, which is the serving one): MAAR1, so only the logical MAAR2, which is the serving one): MAAR1, so only the logical
skipping to change at page 15, line 4 skipping to change at page 15, line 4
figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2
and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two
active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR
always plays the role of anchoring MAAR for the attached (served) always plays the role of anchoring MAAR for the attached (served)
MNs. Each MAAR has one single physical wireless interface. MNs. Each MAAR has one single physical wireless interface.
As introduced before, each MN always "sees" multiple logical routers As introduced before, each MN always "sees" multiple logical routers
-- one per active anchoring MAAR -- independently of to which serving -- one per active anchoring MAAR -- independently of to which serving
MAAR the MN is currently attached. From the point of view of the MN, MAAR the MN is currently attached. From the point of view of the MN,
these MAARs are portrayed as different routers, although the MN is these MAARs are portrayed as different routers, although the MN is
physically attached to one single interface . The way this is physically attached to one single interface. The way this is
achieved is by the serving MAAR configuring different logical achieved is by the serving MAAR configuring different logical
interfaces. If we focus on MN1, it is currently attached to MAAR2 interfaces. If we focus on MN1, it is currently attached to MAAR2
(i.e., MAAR2 is its serving MAAR) and, therefore, it has configured (i.e., MAAR2 is its serving MAAR) and, therefore, it has configured
an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set- an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set-
up a logical interface (mn1dgw2) on top of its wireless physical up a logical interface (mn1mar2) on top of its wireless physical
interface (phy if MAAR2) which is used to serve MN1. This interface interface (phy if MAAR2) which is used to serve MN1. This interface
has a logical MAC address (LMAC6), different from the hardware MAC has a logical MAC address (LMAC6), different from the hardware MAC
address (HMAC2) of the physical interface of MAAR2. Over the mn1dgw2 address (HMAC2) of the physical interface of MAAR2. Over the mn1mar2
interface, MAAR2 advertises its locally anchored prefix prefB::/64. interface, MAAR2 advertises its locally anchored prefix prefB::/64.
Before attaching to MAAR2, MN1 visited MAAR1, configuring also an Before attaching to MAAR2, MN1 visited MAAR1, configuring also an
address locally anchored at this MAAR, which is still being used by address locally anchored at this MAAR, which is still being used by
the MN1 in active communications. MN1 keeps "seeing" an interface the MN1 in active communications. MN1 keeps "seeing" an interface
connecting to MAAR1, as if it were directly connected to the two connecting to MAAR1, as if it were directly connected to the two
MAARs. This is achieved by the serving MAAR (MAAR1) configuring an MAARs. This is achieved by the serving MAAR (MAAR2) configuring an
additional distributed logical interface: mn1dgw1, which behaves additional distributed logical interface: mn1mar1, which behaves
exactly as the logical interface configured by the actual MAAR1 when exactly as the logical interface configured by the actual MAAR1 when
MN1 was attached to it. This means that both the MAC and IPv6 MN1 was attached to it. This means that both the MAC and IPv6
addresses configured on this logical interface remain the same addresses configured on this logical interface remain the same
regardless of the physical MAAR which is serving the MN. The regardless of the physical MAAR which is serving the MN. The
information required by a serving MAAR to properly configure this information required by a serving MAAR to properly configure this
logical interfaces can be obtained in different ways: as part of the logical interfaces can be obtained in different ways: as part of the
information conveyed in the PBA, from an external database (e.g., the information conveyed in the PBA, from an external database (e.g., the
HSS) or by other means. As shown in the figure, each MAAR may have HSS) or by other means. As shown in the figure, each MAAR may have
several logical interfaces associated to each attached MN, having several logical interfaces associated to each attached MN, having
always at least one (since a serving MAAR is also an anchoring MAAR always at least one (since a serving MAAR is also an anchoring MAAR
for the attached MN). for the attached MN).
In order to enforce the use of the prefix locally anchored at the In order to enforce the use of the prefix locally anchored at the
serving MAAR, the router advertisements sent over those logical serving MAAR, the router advertisements sent over those logical
interfaces playing the role of anchoring MAARs (different from the interfaces playing the role of anchoring MAARs (different from the
serving one) include a zero prefix lifetime. The goal is to serving one) include a zero preferred prefix lifetime (and a non-zero
deprecate the prefixes delegated by these MAARs (which will be no valid prefix lifetime, so the prefix remains valid, while being
longer serving the MN). Note that on-going communications keep on deprecated). The goal is to deprecate the prefixes delegated by
using those addresses, even if they are deprecated, so this only these MAARs (which will be no longer serving the MN). Note that on-
affects to new sessions. 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 The distributed logical interface concept also enables the following
use case. Suppose that access to a local IP network is provided by a use case. Suppose that access to a local IP network is provided by a
given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that
the resources available at that network cannot be reached from the resources available at that network cannot be reached from
outside the local network (e.g., cannot be accessed by an MN attached outside the local network (e.g., cannot be accessed by an MN attached
to MAAR2). This is similar to the LIPA scenario currently being to MAAR2). This is similar to the local IP access scenario
consider by 3GPP. The goal is to allow an MN to be able to roam considered 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. while still being able to have connectivity to this local IP network.
The solution adopted to support this case makes use of RFC 4191 The solution adopted to support this case makes use of RFC 4191
[RFC4191] more specific routes when the MN moves to a MAAR different [RFC4191] more specific routes when the MN moves to a MAAR different
from the one providing access to the local IP network (MAAR1 in the from the one providing access to the local IP network (MAAR1 in the
example). These routes are advertised through the distributed example). These routes are advertised through the distributed
logical interface representing the MAAR providing access to the local logical interface representing the MAAR providing access to the local
network (MAAR1 in this example). In this way, if MN1 moves from network (MAAR1 in this example). In this way, if MN1 moves from
MAAR1 to MAAR2, any active session that MN1 may have with a node of MAAR1 to MAAR2, any active session that MN1 may have with a node of
the local network connected to MAAR1 will survive, being the traffic the local network connected to MAAR1 will survive, being the traffic
forwarded via the tunnel between MAAR1 and MAAR2. Also, any forwarded via the tunnel between MAAR1 and MAAR2. Also, any
potential future connection attempt towards the local network will be potential future connection attempt towards the local network will be
supported, even though MN1 is no longer attached to MAAR1. supported, even though MN1 is no longer attached to MAAR1.
3.7. Message Format 4. Message Format
This section defines extensions to the Proxy Mobile IPv6 [RFC5213] This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages. protocol messages.
3.7.1. Proxy Binding Update 4.1. Proxy Binding Update
A new flag (D) is included in the Proxy Binding Update to indicate A new flag (D) is included in the Proxy Binding Update to indicate
that the Proxy Binding Update is coming from a Mobility Anchor and that the Proxy Binding Update is coming from a Mobility Anchor and
Access Router and not from a mobile access gateway. The rest of the Access Router and not from a mobile access gateway. The rest of the
Proxy Binding Update format remains the same as defined in [RFC5213]. Proxy Binding Update format remains the same as defined in [RFC5213].
0 1 2 3 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 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 # | | Sequence # |
skipping to change at page 17, line 8 skipping to change at page 17, line 8
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of and format of defined options are described in Section 6.2 of
[RFC6275]. The MAAR MUST ignore and skip any options that it does [RFC6275]. The MAAR MUST ignore and skip any options that it does
not understand. not understand.
3.7.2. Proxy Binding Acknowledgment 4.2. Proxy Binding Acknowledgment
A new flag (D) is included in the Proxy Binding Acknowledgment to A new flag (D) is included in the Proxy Binding Acknowledgment to
indicate that the sender supports operating as a distributed gateway. indicate that the sender supports operating as a distributed gateway.
The rest of the Proxy Binding Acknowledgment format remains the same The rest of the Proxy Binding Acknowledgment format remains the same
as defined in [RFC5213]. as defined in [RFC5213].
0 1 2 3 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 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 | | Status |K|R|P|D| Reser |
skipping to change at page 17, line 43 skipping to change at page 17, line 43
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of and format of defined options are described in Section 6.2 of
[RFC6275]. The MAAR MUST ignore and skip any options that it does [RFC6275]. The MAAR MUST ignore and skip any options that it does
not understand. not understand.
3.7.3. Anchored Prefix Option 4.3. Anchored Prefix Option
A new Anchored Prefix option is defined for use with the Proxy A new Anchored Prefix option is defined for use with the Proxy
Binding Update and Proxy Binding Acknowledgment messages exchanged Binding Update and Proxy Binding Acknowledgment messages exchanged
between distributed gateways. This option is used for exchanging the between distributed gateways. This option is used for exchanging the
mobile node's prefix anchored at the anchoring MAAR. There can be mobile node's prefix anchored at the anchoring MAAR. There can be
multiple Anchored Prefix options present in the message. multiple Anchored Prefix options present in the message.
The Anchored Prefix Option has an alignment requirement of 8n+4. Its The Anchored Prefix Option has an alignment requirement of 8n+4. Its
format is as follows: format is as follows:
skipping to change at page 18, line 44 skipping to change at page 18, line 44
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Anchored Prefix Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored A sixteen-byte field containing the mobile node's IPv6 Anchored
Prefix. Prefix.
3.7.4. Local Prefix Option 4.4. Local Prefix Option
A new Local Prefix option is defined for use with the Proxy Binding A new Local Prefix option is defined for use with the Proxy Binding
Update and Proxy Binding Acknowledgment messages exchanged between Update and Proxy Binding Acknowledgment messages exchanged between
MAARs. This option is used for exchanging a prefix of a local MAARs. This option is used for exchanging a prefix of a local
network that is only reachable via the anchoring MAAR. There can be network that is only reachable via the anchoring MAAR. There can be
multiple Local Prefix options present in the message. multiple Local Prefix options present in the message.
The Local Prefix Option has an alignment requirement of 8n+4. Its The Local Prefix Option has an alignment requirement of 8n+4. Its
format is as follows: format is as follows:
skipping to change at page 19, line 46 skipping to change at page 19, line 46
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Local Prefix Local Prefix
A sixteen-byte field containing the IPv6 Local Prefix. A sixteen-byte field containing the IPv6 Local Prefix.
3.7.5. Previous MAAR Option 4.5. Previous MAAR Option
This new option is defined for use with the Proxy Binding This new option is defined for use with the Proxy Binding
Acknowledgement messages exchanged by the CMD to a MAAR. This option 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 is used to notify the S-MAAR about the previous MAAR's global address
and the prefix anchored to it. There can be multiple Previous MAAR and the prefix anchored to it. There can be multiple Previous MAAR
options present in the message. Its format is as follows: options present in the message. Its format is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 35 skipping to change at page 20, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. To be assigned by IANA.
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 34. set to 33.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Previous MAAR's address Previous MAAR's address
A sixteen-byte field containing the P-MAAR's IPv6 global address. A sixteen-byte field containing the P-MAAR's IPv6 global address.
Home Network Prefix Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix. Network Prefix.
3.7.6. Serving MAAR Option 4.6. Serving MAAR Option
This new option is defined for use with the Proxy Binding Update and This new option is defined for use with the Proxy Binding Update and
Proxy Binding Acknowledgement messages exchanged between the CMD and Proxy Binding Acknowledgement messages exchanged between the CMD and
a Previous MAAR. This option is used to notify the P-MAAR about the 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: current Serving MAAR's global address. Its format is as follows:
0 1 2 3 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 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 | | Type | Length |
skipping to change at page 21, line 40 skipping to change at page 21, line 40
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 16. set to 16.
Serving MAAR's address Serving MAAR's address
A sixteen-byte field containing the S-MAAR's IPv6 global address. A sixteen-byte field containing the S-MAAR's IPv6 global address.
3.7.7. DLIF Link-local Address Option 4.7. DLIF Link-local Address Option
A new DLIF Link-local Address option is defined for use with the A new DLIF Link-local Address option is defined for use with the
Proxy Binding Update and Proxy Binding Acknowledgment messages Proxy Binding Update and Proxy Binding Acknowledgment messages
exchanged between MAARs. This option is used for exchanging the exchanged between MAARs. This option is used for exchanging the
link-local address of the DLIF to be configured on the serving MAAR link-local address of the DLIF to be configured on the serving MAAR
so it resembles the DLIF configured on the anchoring MAAR. so it resembles the DLIF configured on the anchoring MAAR.
The DLIF Link-local Address option has an alignment requirement of The DLIF Link-local Address option has an alignment requirement of
8n+6. Its format is as follows: 8n+6. Its format is as follows:
skipping to change at page 22, line 34 skipping to change at page 22, line 34
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 16. set to 16.
DLIF Link-local Address DLIF Link-local Address
A sixteen-byte field containing the link-local address of the A sixteen-byte field containing the link-local address of the
logical interface. logical interface.
3.7.8. DLIF Link-layer Address Option 4.8. DLIF Link-layer Address Option
A new DLIF Link-layer Address option is defined for use with the A new DLIF Link-layer Address option is defined for use with the
Proxy Binding Update and Proxy Binding Acknowledgment messages Proxy Binding Update and Proxy Binding Acknowledgment messages
exchanged between MAARs. This option is used for exchanging the exchanged between MAARs. This option is used for exchanging the
link-layer address of the DLIF to be configured on the serving MAAR link-layer address of the DLIF to be configured on the serving MAAR
so it resembles the DLIF configured on the anchoring MAAR. so it resembles the DLIF configured on the anchoring MAAR.
The format of the DLIF Link-layer Address option is shown below. The format of the DLIF Link-layer Address option is shown below.
Based on the size of the address, the option MUST be aligned Based on the size of the address, the option MUST be aligned
appropriately, as per mobility option alignment requirements appropriately, as per mobility option alignment requirements
skipping to change at page 23, line 33 skipping to change at page 23, line 33
octets, excluding the type and length fields. octets, excluding the type and length fields.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
DLIF Link-layer Address DLIF Link-layer Address
A variable length field containing the link-layer address of the A variable length field containing the link-layer address of the
logical interface to be configured on the serving distributed logical interface to be configured on the S-MAAR.
gateway.
The content and format of this field (including byte and bit The content and format of this field (including byte and bit
ordering) is as specified in Section 4.6 of [RFC4861] for carrying ordering) is as specified in Section 4.6 of [RFC4861] for carrying
link-layer addresses. On certain access links, where the link- link-layer addresses. On certain access links, where the link-
layer address is not used or cannot be determined, this option layer address is not used or cannot be determined, this option
cannot be used. cannot be used.
4. IANA Considerations 5. IANA Considerations
This document defines new mobility options that require IANA actions. This document defines new mobility options that require IANA actions.
TBD. TBD.
5. Security Considerations 6. Security Considerations
The protocol extensions defined in this document share the same The protocol extensions defined in this document share the same
security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended
that the signaling messages, Proxy Binding Update and Proxy Binding that the signaling messages, Proxy Binding Update and Proxy Binding
Acknowledgment, exchanged between the MAARs are protected using IPsec Acknowledgment, exchanged between the MAARs are protected using IPsec
using the established security association between them. This using the established security association between them. This
essentially eliminates the threats related to the impersonation of a essentially eliminates the threats related to the impersonation of a
MAAR. MAAR.
6. Acknowledgments 7. Acknowledgments
The authors would like to thank Marco Liebsch for his comments and The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex
discussion on the documents [I-D.bernardos-dmm-distributed-anchoring] Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and
and [I-D.bernardos-dmm-pmip] on which the present document is based. Satoru Matsushima for their comments and discussion on the documents
[I-D.bernardos-dmm-distributed-anchoring] and
[I-D.bernardos-dmm-pmip] on which the present document is based.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 24, line 42 skipping to change at page 24, line 43
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>. <https://www.rfc-editor.org/info/rfc5213>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
7.2. Informative References 8.2. Informative References
[I-D.bernardos-dmm-distributed-anchoring] [I-D.bernardos-dmm-distributed-anchoring]
Bernardos, C. and J. Zuniga, "PMIPv6-based distributed Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-09 anchoring", draft-bernardos-dmm-distributed-anchoring-09
(work in progress), May 2017. (work in progress), May 2017.
[I-D.bernardos-dmm-pmip] [I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
solution for Distributed Mobility Management", draft- solution for Distributed Mobility Management", draft-
bernardos-dmm-pmip-09 (work in progress), September 2017. bernardos-dmm-pmip-09 (work in progress), September 2017.
[I-D.ietf-dmm-deployment-models] [I-D.ietf-dmm-deployment-models]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-03 (work in progress), November 2017. models-04 (work in progress), May 2018.
[I-D.ietf-dmm-ondemand-mobility] [I-D.ietf-dmm-ondemand-mobility]
Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S.
Jeon, "On Demand Mobility Management", draft-ietf-dmm- Jeon, "On Demand Mobility Management", draft-ietf-dmm-
ondemand-mobility-14 (work in progress), March 2018. ondemand-mobility-14 (work in progress), March 2018.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>. <https://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015, DOI 10.17487/RFC7429, January 2015,
<https://www.rfc-editor.org/info/rfc7429>. <https://www.rfc-editor.org/info/rfc7429>.
Appendix A. Comparison with Requirement document Appendix A. Comparison with Requirement document
In this section we descrbe how our solution addresses the DMM In this section we describe how our solution addresses the DMM
requirements listed in [RFC7333]. requirements listed in [RFC7333].
A.1. Distributed mobility management A.1. Distributed mobility management
"IP mobility, network access solutions, and forwarding solutions "IP mobility, network access solutions, and forwarding solutions
provided by DMM MUST enable traffic to avoid traversing a single provided by DMM MUST enable traffic to avoid traversing a single
mobility anchor far from the optimal route." mobility anchor far from the optimal route."
In our solution, a MAAR is responsible to handle the mobility for 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 those IP flows started when the MN is attached to it. As long as the
skipping to change at page 27, line 18 skipping to change at page 27, line 18
"A DMM solution may require loose, tight, or no integration into "A DMM solution may require loose, tight, or no integration into
existing mobility protocols and host IP stacks. Regardless of the existing mobility protocols and host IP stacks. Regardless of the
integration level, DMM implementations MUST be able to coexist with integration level, DMM implementations MUST be able to coexist with
existing network deployments, end hosts, and routers that may or may existing network deployments, end hosts, and routers that may or may
not implement existing mobility protocols. Furthermore, a DMM not implement existing mobility protocols. Furthermore, a DMM
solution SHOULD work across different networks, possibly operated as solution SHOULD work across different networks, possibly operated as
separate administrative domains, when the needed mobility management separate administrative domains, when the needed mobility management
signaling, forwarding, and network access are allowed by the trust signaling, forwarding, and network access are allowed by the trust
relationship between them" relationship between them"
The partially DMM solution can be extended to provide a fallback The partially distributed DMM solution (distributed data plane and
centralized control plane) can be extended to provide a fallback
mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to
instruct MAARs to always establish a tunnel with the same MAAR, instruct MAARs to always establish a tunnel with the same MAAR,
working as LMA. The fully DMM solution can be extended as well, but working as LMA. The fully distributed DMM solution (distributed data
it requires more intervention. The partially DMM solution can be and control plane) can be extended as well, but it requires more
deployed across different domains with trust agreements if the CMDs intervention. The partially distributed DMM solution can be deployed
ot the operators are enabled to transfer context from one node to across different domains with trust agreements if the CMDs of the
another. The fully DMM solution works across multiple domains if operators are enabled to transfer context from one node to another.
both solution apply the same signalling scheme. The fully distributed DMM solution works across multiple domains if
the same signalling scheme is used in both domains.
A.6. Operation and management considerations A.6. Operation and management considerations
"A DMM solution needs to consider configuring a device, monitoring "A DMM solution needs to consider configuring a device, monitoring
the current operational state of a device, and responding to events the current operational state of a device, and responding to events
that impact the device, possibly by modifying the configuration and that impact the device, possibly by modifying the configuration and
storing the data in a format that can be analyzed later. storing the data in a format that can be analyzed later.
The proposed solution can re-use existing mechanisms defined for the The proposed solution can re-use existing mechanisms defined for the
operation and management of Proxy Mobile IPv6. operation and management of Proxy Mobile IPv6.
skipping to change at page 28, line 46 skipping to change at page 28, line 46
stores the previous MAARs' address and the corresponding prefix(es) stores the previous MAARs' address and the corresponding prefix(es)
assigned for the MN. Only the CMD and the serving MAAR store this assigned for the MN. Only the CMD and the serving MAAR store this
data structure, because the CMD maintains the global MN's mobility data structure, because the CMD maintains the global MN's mobility
session formed during the MN's roaming within the domain, and the session formed during the MN's roaming within the domain, and the
serving MAAR needs to know which previous MAARs were visited, the serving MAAR needs to know which previous MAARs were visited, the
prefix(es) they assigned and the tunnels established with them. prefix(es) they assigned and the tunnels established with them.
Conversely, a previous MAAR only needs to know which is the current Conversely, a previous MAAR only needs to know which is the current
Serving MAAR and establish a single tunnel with it. For this reason, 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 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 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 prefix(es) it is anchoring, then stops the BCE expiry timer and
deletes the MAAR list (if present) since it is no longer useful. 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 In order to have the MN totally unaware of the changes in the access
link, all MAARs implement the Distributed Logical Interface (DLIF) link, all MAARs implement the Distributed Logical Interface (DLIF)
concept. Moreover, it should be noted that the protocols designed in concept. Moreover, it should be noted that the protocols designed in
the document work only at the network layer to handle the MNs joining the document work only at the network layer to handle the MNs joining
or leaving the domain. This should guarantee a certain independency or leaving the domain. This should guarantee a certain independency
to a particular access technology. The implementation reflects this to a particular access technology. The implementation reflects this
reasoning, but we argue that an interaction with lower layers reasoning, but we argue that an interaction with lower layers
produces a more effective attachment and detachment detection, produces a more effective attachment and detachment detection,
skipping to change at page 30, line 6 skipping to change at page 30, line 6
As the community has recently been developing the 5G applications and As the community has recently been developing the 5G applications and
their technical requirements, it has become clear that certain their technical requirements, it has become clear that certain
applications would require very low latency which is extremely applications would require very low latency which is extremely
challenging and stressing for the network to deliver through a pure challenging and stressing for the network to deliver through a pure
centralized architecture. The need to provide networking, computing, centralized architecture. The need to provide networking, computing,
and storage capabilities closer to the users has therefore emerged, and storage capabilities closer to the users has therefore emerged,
leading to what is known today as the concept of intelligent edge. leading to what is known today as the concept of intelligent edge.
ETSI has been the first to address this need recently by developing ETSI has been the first to address this need recently by developing
the framework of mobile edge computing (MEC). the framework of multi-access edge computing (MEC).
Such an intelligent edge could not be envisaged without Such an intelligent edge could not be envisaged without
virtualization. Beyond applications, it raises a clear opportunity virtualization. Beyond applications, it raises a clear opportunity
for networking functions to execute at the edge benefiting from for networking functions to execute at the edge benefiting from
inherent low latencies. inherent low latencies.
Whilst it is appreciated the particular challenge for the intelligent Whilst it is appreciated the particular challenge for the intelligent
edge concept in dealing with mobile users, the edge virtualization edge concept in dealing with mobile users, the edge virtualization
substrate has been largely assumed to be fixed or stationary. substrate has been largely assumed to be fixed or stationary.
Although little developed, the intelligent edge concept is being Although little developed, the intelligent edge concept is being
skipping to change at page 30, line 32 skipping to change at page 30, line 32
edge remain an exciting area of future research. edge remain an exciting area of future research.
Figure 7 shows a diagram representing the fog virtualization concept. Figure 7 shows a diagram representing the fog virtualization concept.
The fog is composed by virtual resources on top of heterogeneous The fog is composed by virtual resources on top of heterogeneous
resources available at the edge and even further in the RAN and end- resources available at the edge and even further in the RAN and end-
user devices. These resources are therefore owned by different user devices. These resources are therefore owned by different
stakeholders who collaboratively form a single hosting environment stakeholders who collaboratively form a single hosting environment
for the VNFs to run. As an example, virtual resources provided to for the VNFs to run. As an example, virtual resources provided to
the fog might be running on eNBs, APs, at micro data centers deployed the fog might be running on eNBs, APs, at micro data centers deployed
in shopping malls, cars, trains, etc. The fog is connected to data in shopping malls, cars, trains, etc. The fog is connected to data
centers deeper into the network architecture (at the edge ir the centers deeper into the network architecture (at the edge or the
core). core).
+--------------------------------+ +-------------------+ +--------------------------------+ +-------------------+
| ------- -------- -------- | | ---------- | | ------- -------- -------- | | ---------- |
| | | | | | | | | ---------- | | | | | | | | | | | ---------- | |
| | @UE | | @car | | @eNB | | | ---------- | | | | | @UE | | @car | | @eNB | | | ---------- | | |
| ------- -------- -------- | | | Data | | | | | ------- -------- -------- | | | Data | | | |
| | | | Center | | - | | | | | Center | | - |
| -------- Heterogeneous ------- | | | (DC) |- | | -------- Heterogeneous ------- | | | (DC) |- |
phy | | | computing | | | | ---------- | phy | | | computing | | | | ---------- |
 End of changes. 63 change blocks. 
129 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/