draft-ietf-dmm-pmipv6-dlif-05.txt   draft-ietf-dmm-pmipv6-dlif-06.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: Experimental UC3M Intended status: Experimental UC3M
Expires: May 5, 2020 F. Giust Expires: September 9, 2020 F. Giust
Athonet Athonet
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
A. Mourad A. Mourad
InterDigital InterDigital
November 2, 2019 March 8, 2020
Proxy Mobile IPv6 extensions for Distributed Mobility Management Proxy Mobile IPv6 extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-05 draft-ietf-dmm-pmipv6-dlif-06
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 centrally deployed anchors to provide IP mobility not rely on centrally 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 2, line 15 skipping to change at page 2, line 15
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 May 5, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 extensions . . . . . . . . . . . . . . . . . . . . 5 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 11 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13
3.6. The Distributed Logical Interface (DLIF) concept . . . . 14 3.6. Retransmissions and Rate Limiting . . . . . . . . . . . . 14
3.7. The Distributed Logical Interface (DLIF) concept . . . . 14
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18
4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19
4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19
4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 20 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 21
4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22
4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23
4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 23 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 24
4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 24 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Comparison with Requirement document . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 28
A.1. Distributed mobility management . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . . . . . . 28
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 29
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 29
A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 29
A.6. Operation and management considerations . . . . . . . . . 30
A.7. Security considerations . . . . . . . . . . . . . . . . . 30
A.8. Multicast considerations . . . . . . . . . . . . . . . . 30
Appendix B. Implementation experience . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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) [RFC7333].
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 (PMIPv6) [RFC5213], just to cite IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite
the two most relevant examples, offer mobility support at the cost of the two most relevant examples, offer mobility support at the cost of
handling operations at a cardinal point, the mobility anchor (i.e., handling operations at a cardinal point, the mobility anchor (i.e.,
the home agent for Mobile IPv6, and the local mobility anchor for the home agent for Mobile IPv6, and the local mobility anchor for
Proxy Mobile IPv6), and burdening it with data forwarding and control Proxy Mobile IPv6), and burdening it with data forwarding and control
mechanisms for a great amount of users. As stated in [RFC7333], mechanisms for a great amount of users. As stated in [RFC7333],
centralized mobility solutions are prone to several problems and centralized mobility solutions are prone to several problems and
limitations: longer (sub-optimal) routing paths, scalability limitations: longer (sub-optimal) routing paths, scalability
skipping to change at page 3, line 49 skipping to change at page 3, line 39
handover latency), more complex network deployment, higher handover latency), more complex network deployment, higher
vulnerability due to the existence of a potential single point of vulnerability due to the existence of a potential single point of
failure, and lack of granularity of the mobility management service failure, and lack of granularity of the mobility management service
(i.e., mobility is offered on a per-node basis, not being possible to (i.e., mobility is offered on a per-node basis, not being possible to
define finer granularity policies, as for example per-application). 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 Mobile Node (MN). bringing the mobility anchor closer to the Mobile Node (MN).
Following this idea, in our proposal, the central anchor is moved to Following this idea, the central anchor is moved to the edge of the
the edge of the network, being deployed in the default gateway of the network, being deployed in the default gateway of the mobile node.
mobile node. That is, the first elements that provide IP That is, the first elements that provide IP connectivity to a set of
connectivity to a set of MNs are also the mobility managers for those MNs are also the mobility managers for those MNs. In this document,
MNs. In this document, we call these entities Mobility Anchors and we call these entities Mobility Anchors and Access Routers (MAARs).
Access Routers (MAARs).
This document focuses on network-based DMM, hence the starting point This document focuses on network-based DMM, hence the starting point
is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is
handled by the network without the MNs involvement, but, differently handled by the network without the MNs involvement, but, differently
from PMIPv6, when the MN moves from one access network to another, it from PMIPv6, when the MN moves from one access network to another, it
may also change anchor router, hence requiring signaling between the may also change anchor router, hence requiring signaling between the
anchors to retrieve the MN's previous location(s). Also, a key- anchors to retrieve the MN's previous location(s). Also, a key-
aspect of network-based DMM, is that a prefix pool belongs aspect of network-based DMM, is that a prefix pool belongs
exclusively to each MAAR, in the sense that those prefixes are 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 assigned by the MAAR to the MNs attached to it, and they are routable
at that MAAR. at that MAAR. Prefixes are assigned to MNs attached a MAAR at that
time, but remain with those MNs as mobility occurs, remaining always
routable at that MAAR as well as towards the MN itself.
We consider partially distributed schemes, where the data plane only We consider partially distributed schemes, where only the data plane
is distributed among access routers similar to MAGs, whereas the is distributed among access routers similar to MAGs, whereas the
control plane is kept centralized towards a cardinal node used as control plane is kept centralized towards a cardinal node used as
information store, but relieved from any route management and MN's information store, but relieved from any route management and MN's
data forwarding task. data forwarding task.
2. Terminology 2. Terminology
The following terms used in this document are defined in the Proxy The following terms used in this document are defined in the Proxy
Mobile IPv6 specification [RFC5213]: Mobile IPv6 specification [RFC5213]:
skipping to change at page 4, line 44 skipping to change at page 4, line 34
Mobile Node (MN) Mobile Node (MN)
Binding Cache Entry (BCE) Binding Cache Entry (BCE)
Proxy Care-of Address (P-CoA) Proxy Care-of Address (P-CoA)
Proxy Binding Update (PBU) Proxy Binding Update (PBU)
Proxy Binding Acknowledgement (PBA) Proxy Binding Acknowledgement (PBA)
The following terms used in this document are defined in the DMM The following terms are used in this document:
Deployment Models and Architectural Considerations document
[I-D.ietf-dmm-deployment-models]:
Home Control-Plane Anchor (Home-CPA) Home Control-Plane Anchor (Home-CPA or H-CPA): The Home-CPA function
hosts the mobile node (MN)'s mobility session. There can be more
than one mobility session for a mobile node and those sessions may
be anchored on the same or different Home-CPA's. The home-CPA
will interface with the home-DPA for managing the forwarding
state.
Home Data Plane Anchor (Home-DPA) Home Data Plane Anchor (Home-DPA or H-DPA): The Home-DPA is the
Access Control Plane Node (Access-CPN) topological anchor for the MN's IP address/ prefix(es). The Home-
DPA is chosen by the Home-CPA on a session- basis. The Home-DPA
is in the forwarding path for all the mobile node's IP traffic.
Access Data Plane Node (Access-DPN) Access Control Plane Node (Access-CPN or A-CPN): The Access-CPN is
responsible for interfacing with the mobile node's Home-CPA and
with the Access-DPN. The Access-CPN has a protocol interface to
the Home-CPA.
Access Data Plane Node (Access-DPN or A-DPN): The Access-DPN
function is hosted on the first-hop router where the mobile node
is attached. This function is not hosted on a layer-2 bridging
device such as a eNode(B) or Access Point.
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). The node that stores the BCEs CMD (Central Mobility Database). The node that stores the BCEs
skipping to change at page 5, line 33 skipping to change at page 5, line 40
becomes the P-MAAR. It is still the anchor point for the IPv6 becomes the P-MAAR. It is still the anchor point for the IPv6
prefixes it had allocated to the MN in the past and serves as the prefixes it had allocated to the MN in the past and serves as the
Home-DPA for flows using these prefixes. There might be several Home-DPA for flows using these prefixes. There might be several
P-MAARs serving a MN when the MN is frequently switching points of P-MAARs serving a MN when the MN is frequently switching points of
attachment while maintaining long-lasting flows. attachment while maintaining long-lasting flows.
S-MAAR (Serving MAAR). The MAAR which the MN is currently attached S-MAAR (Serving MAAR). The MAAR which the MN is currently attached
to. Depending on the prefix, it plays the role of Access-DPN, to. Depending on the prefix, it plays the role of Access-DPN,
Home-DPA and Access-CPN. Home-DPA and Access-CPN.
Anchoring MAAR. A MAAR anchoring an IPv6 prefix used by an MN.
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 MN, the IP stack of the MAAR. For each active prefix used by the MN,
the S-MAAR has a DLIF configured (associated to each MAAR still the S-MAAR has a DLIF configured (associated to each MAAR still
anchoring flows). In this way, an S-MAAR exposes itself towards anchoring flows). In this way, an S-MAAR exposes itself towards
each MN as multiple routers, one as itself and one per P-MAAR. each MN as multiple routers, one as itself and one per P-MAAR.
3. PMIPv6 DMM extensions 3. PMIPv6 DMM extensions
The solution consists of de-coupling the entities that participate in The solution consists of de-coupling the entities that participate in
the data and the control planes: the data plane becomes distributed the data and the control planes: the data plane becomes distributed
and managed by the MAARs near the edge of the network, while the and managed by the MAARs near the edge of the network, while the
control plane, besides those on the MAARs, relies on a central entity control plane, besides those on the MAARs, relies on a central 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 CMD, which is therefore a Home-CPA. Also,
therefore a Home-CPA. Also, the CMD is able to send and parse the CMD is able to send and parse both PBU and PBA messages.
both 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 be extended to include information o The binding cache will be extended to include information
regarding P-MAARs where the mobile node was anchored and still regarding P-MAARs where the mobile node was anchored and still
retains active data sessions, see Appendix B for further details. retains active data sessions.
o Each MAAR has a unique set of global prefixes (which are o Each MAAR has a unique set of global prefixes (which are
configurable), that can be allocated by the MAAR to the MNs, but 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 must be exclusive to that MAAR, i.e. no other MAAR can allocate
the same prefixes. the same prefixes.
The MAARs leverage the Central Mobility Database (CMD) to access and The MAARs leverage the CMD to access and update information related
update information related to the MNs, stored as mobility sessions; to the MNs, stored as mobility sessions; hence, a centralized node
hence, a centralized node maintains a global view of the network maintains a global view of the network status. The CMD is queried
status. The CMD is queried whenever a MN is detected to join/leave whenever a MN is detected to join/leave the mobility domain. It
the mobility domain. It might be a fresh attachment, a detachment or might be a fresh attachment, a detachment or a handover, but as MAARs
a handover, but as MAARs are not aware of past information related to are not aware of past information related to a mobility session, they
a mobility session, they contact the CMD to retrieve the data of contact the CMD to retrieve the data of interest and eventually take
interest and eventually take the appropriate action. The procedure the appropriate action. The procedure adopted for the query and the
adopted for the query and the messages exchange sequence might vary message exchange sequence might vary to optimize the update latency
to optimize the update latency and/or the signaling overhead. Here and/or the signaling overhead. Here is presented one method for the
is presented one method for the initial registration, and three initial registration, and three different approaches for updating the
different approaches for updating the mobility sessions using PBUs mobility sessions using PBUs and PBAs. Each approach assigns a
and PBAs. Each approach assigns a different role to the CMD: different role to the CMD:
o The CMD is a PBU/PBA relay; o The CMD is a PBU/PBA relay;
o The CMD is only a MAAR locator; o The CMD is only a MAAR locator;
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 The solution described in this document allows performing per-prefix
Mode in [I-D.ietf-dmm-deployment-models]. As another note, the
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 [RFC8563]. This type of per-prefix treatment would as indicated in [RFC8563]. This type of per-prefix treatment would
potentially require additional extensions to the MAARs and signaling potentially require additional extensions to the MAARs and signaling
between the MAARs and the MNs to convey the per-flow anchor between the MAARs and the MNs to convey the per-flow anchor
preference (central, distributed), which are not covered in this preference (central, distributed), which are not covered in this
document. document.
Note that a MN MAY move across different MAARs, which might result in Note that a MN may move across different MAARs, which might result in
several P-MAARs existing at a given moment of time, each of them several P-MAARs existing at a given moment of time, each of them
anchoring a different prefix used by the MN. anchoring a different prefix used by the MN.
3.1. Initial registration 3.1. Initial registration
Initial registration is performed when an MN attaches to a network Initial registration is performed when an MN attaches to a network
for the first time (rather than attaching to a new network after for the first time (rather than attaching to a new network after
moving from a previous one). moving from a previous one).
In this description (shown in Figure 1), it is assumed that: In this description (shown in Figure 1), it is assumed that:
1. The MN is attaching to MAAR1. 1. The MN is attaching to MAAR1.
2. The MN is authorized to attach to the network. 2. The MN is authorized to attach to the network.
Upon MN attachment, the following operations take place: Upon MN attachment, the following operations take place:
1. MAAR1 assigns an IPv6 global prefix from its own prefix pool to 1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to
the MN (Pref1). It also stores this prefix (Pref1) in the the MN (Pref1). It also stores this prefix (Pref1) in the
locally allocated temporary Binding Cache Entry (BCE). locally allocated temporary Binding Cache Entry (BCE).
2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the
CMD. CMD.
3. Since this is an initial registration, the CMD stores a permanent 3. Since this is an initial registration, the CMD stores a BCE
BCE containing as primary fields the MN-ID, Pref1 and MAAR1's containing as primary fields the MN-ID, Pref1 and MAAR1's address
address as a Proxy-CoA. as a Proxy-CoA.
4. The CMD replies with a PBA with the usual options defined in 4. The CMD replies with a PBA with the usual options defined in
PMIPv6 [RFC5213], meaning that the MN's registration is fresh and PMIPv6 [RFC5213], meaning that the MN's registration is fresh and
no past status is available. no past status is available.
5. MAAR1 stores the BCE described in (1) and unicasts a Router 5. MAAR1 stores the BCE described in (1) and unicasts a Router
Advertisement (RA) to the MN with Pref1. Advertisement (RA) to the MN with Pref1.
6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with 6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with
stateless auto-configuration, SLAAC). stateless auto-configuration, SLAAC).
skipping to change at page 8, line 46 skipping to change at page 9, line 6
Note that the registration process does not change regardless of the Note that the registration process does not change regardless of the
CMD's modes (relay, locator or proxy) described next. The procedure CMD's modes (relay, locator or proxy) described next. The procedure
is depicted in Figure 1. is depicted in Figure 1.
3.2. The CMD as PBU/PBA relay 3.2. The CMD as PBU/PBA relay
Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following
operations take place: operations take place:
1. When the MN moves from its current point of attachment and 1. When the MN moves from its current point of attachment and
attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix
prefix (Pref2), it stores a temporary BCE, and it sends a plain (Pref2), it stores a temporary BCE, and it sends a PBU to the CMD
PBU to the CMD for registration. for registration.
2. Upon PBU reception and BC lookup, the CMD retrieves an already 2. Upon PBU reception and BC lookup, the CMD retrieves an already
existing entry for the MN, binding the MN-ID to its former 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 Proxy CoA (MAAR1), including a new mobility option to communicate
the S-MAAR's global address to MAAR1, defined as Serving MAAR the S-MAAR's global address to MAAR1, defined as Serving MAAR
Option in Section 4.6. The CMD updates the P-CoA field in the Option in Section 4.6. The CMD updates the P-CoA field in the
BCE related to the MN with the S-MAAR's address. BCE related to the MN with the S-MAAR's address.
3. Upon PBU reception, MAAR1 can install a tunnel on its side 3. Upon PBU reception, MAAR1 can install a tunnel on its side
towards MAAR2 and the related routes for Pref1. Then MAAR1 towards MAAR2 and the related routes for Pref1. Then MAAR1
replies to the CMD with a PBA (including the option mentioned replies to the CMD with a PBA (including the option mentioned
before) to ensure that the new location has successfully changed, before) to ensure that the new location has successfully changed,
containing the prefix anchored at MAAR1 in the Home Network containing the prefix anchored at MAAR1 in the Home Network
Prefix option. Prefix option.
4. The CMD, after receiving the PBA, updates the BCE populating an 4. The CMD, after receiving the PBA, updates the BCE populating an
instance of the P-MAAR list. The P-MAAR list is an additional 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 field on the BCE that contains an element for each P-MAAR
involved in the MN's mobility session. The list element contains involved in the MN's mobility session. The list element contains
the P-MAAR's global address and the prefix it has delegated (see the P-MAAR's global address and the prefix it has delegated.
Appendix B for further details). Also, the CMD sends a PBA to Also, the CMD sends a PBA to the new S-MAAR, containing the
the new S-MAAR, containing the previous Proxy-CoA and the prefix previous Proxy-CoA and the prefix anchored to it embedded into a
anchored to it embedded into a new mobility option called new mobility option called Previous MAAR Option (defined in
Previous MAAR Option (defined in Section 4.5), so that, upon PBA Section 4.5), so that, upon PBA arrival, a bi-directional tunnel
arrival, a bi-directional tunnel can be established between the can be established between the two MAARs and new routes are set
two MAARs and new routes are set appropriately to recover the IP appropriately to recover the IP flow(s) carrying Pref1.
flow(s) carrying Pref1.
5. Now packets destined to Pref1 are first received by MAAR1, 5. Now packets destined to Pref1 are first received by MAAR1,
encapsulated into the tunnel and forwarded to MAAR2, which encapsulated into the tunnel and forwarded to MAAR2, which
finally delivers them to their destination. In uplink, when the finally delivers them to their destination. In uplink, when the
MN transmits packets using Pref1 as source address, they are sent MN transmits packets using Pref1 as source address, they are sent
to MAAR2, as it is MN's new default gateway, then tunneled to to MAAR2, as it is MN's new default gateway, then tunneled to
MAAR1 which routes them towards the next hop to destination. MAAR1 which routes them towards the next hop to destination.
Conversely, packets carrying Pref2 are routed by MAAR2 without Conversely, packets carrying Pref2 are routed by MAAR2 without
any special packet handling both for uplink and downlink. any special packet handling both for uplink and downlink.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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 MN's next movements the process is repeated except the number of For MN's next movements the process is repeated except the number of
P-MAARs involved increases (accordingly to the number of prefixes P-MAARs involved increases (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, namely the one registered as
prior to handover) and in the P-MAARs list. They reply with a PBA to current P-CoA (i.e., the MAAR prior to handover) plus the ones in the
the CMD, which aggregates them into a single one to notify the P-MAARs list. They reply with a PBA to the CMD, which aggregates
S-MAAR, that finally can establish the tunnels with the P-MAARs. 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 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 at the prefix granularity, and it can be tuned in order to erase old
mobility sessions when not required, while the MN is reachable mobility sessions when not required, while the MN is reachable
through the latest prefix acquired. Moreover, the latency associated through the latest prefix acquired. Moreover, the latency associated
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.
Note that in this case the S-MAAR might receive multiple PBAs from Note that in this case the S-MAAR might receive multiple PBAs from
the CMD in response to a PBU. When aggregating and relaying PBAs, the CMD in response to a PBU. The CMD SHOULD follow the
the CMD SHOULD make use of the timeout also to deal with missing PBAs retransmissions and rate limiting considerations described in
(to retransmit PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD Section 3.6, especially when aggregating and relaying PBAs.
be used for configuring the retransmission timer.
When there are multiple previous MAARs, e.g., k MAARs, a single PBU When there are multiple previous MAARs, e.g., k MAARs, a single PBU
received by the CMD triggers k outgoing packets from a single received by the CMD triggers k outgoing packets from a single
incoming packet. This may lead to packet bursts originated from the incoming packet. This may lead to packet bursts originated from the
CMD, albeit to different targets. Pacing mechanisms MAY be CMD, albeit to different targets. Pacing mechanisms MUST be
introduced to avoid bursts on the outgoing link. introduced to avoid bursts on the outgoing link.
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 reflects 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 S-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 is 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. Figure 3 illustrates the new message sequence, while the routes. Figure 3 illustrates the new message sequence, while the
data forwarding is unaltered. data forwarding is unaltered.
skipping to change at page 13, line 34 skipping to change at page 13, line 34
| | | +----+ | | | +----+
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 cannot be used as is The de-registration mechanism devised for PMIPv6 cannot be used as-is
in this solution. The reason for this is that each MAAR handles an in this solution. The reason for this is that each MAAR handles an
independent mobility session (i.e., a single or a set of prefixes) 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. for a given MN, whereas the aggregated session is stored at the CMD.
Indeed, when a previous MAAR initiates a de-registration procedure, Indeed, if a previous MAAR initiates a de-registration procedure,
because the MN is no longer present on the MAAR's access link, it 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 removes the routing state for that (those) prefix(es), that would be
deleted by the CMD as well, hence defeating any prefix continuity deleted by the CMD as well, hence defeating any prefix continuity
attempt. The simplest approach to overcome this limitation is to attempt. The simplest approach to overcome this limitation is to
deny a P-MAAR to de-register a prefix, that is, allowing only a deny a P-MAAR to de-register a prefix, that is, allowing only a
serving MAAR to de-register the whole MN session. This can be serving MAAR to de-register the whole MN session. This can be
achieved by first removing any layer-2 detachment event, so that de- achieved by first removing any layer-2 detachment event, so that de-
registration is triggered only when the session lifetime expires, registration is triggered only when the binding lifetime expires,
hence providing a guard interval for the MN to connect to a new MAAR. 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 Then, a change in the MAAR operations is required, and at this stage
two possible solutions can be deployed: 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 definitely left the domain. arguing that the MN definitely left the domain.
o Previous MAARs can, upon BCE expiry, send de-registration messages o Previous MAARs can, upon BCE expiry, send de-registration messages
to the CMD, which, instead of acknowledging the message with a 0 to the CMD, which, instead of acknowledging the message with a 0
lifetime, sends back a PBA with a non-zero lifetime, hence re- lifetime, sends 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.
3.6. The Distributed Logical Interface (DLIF) concept 3.6. Retransmissions and Rate Limiting
When sending PBUs, the node sending them (the CMD or S-MAAR) SHOULD
make use of the timeout also to deal with missing PBAs (to retransmit
PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for
configuring the retransmission timer. The retransmissions by the
node MUST use an exponential backoff process in which the timeout
period is doubled upon each retransmission, until either the node
receives a response or the timeout period reaches the value
MAX_BINDACK_TIMEOUT [RFC6275]. The node MAY continue to send these
messages at this slower rate indefinitely. The node MUST NOT send
PBU messages to a particular node more than MAX_UPDATE_RATE times
within a second [RFC6275].
3.7. 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 the mobile node's anchored at different MAARs, and how to influence the mobile node's
selection process of its source IPv6 address for a new flow, without selection process of its source IPv6 address for a new flow, without
requiring special support from the mobile node's IP stack. This requiring special support from the mobile node's IP stack. This
document defines the Distributed Logical Interface (DLIF), which is a document defines the Distributed Logical Interface (DLIF), which is a
software construct that allows to easily hide the change of software construct in the MAAR that allows to easily hide the change
associated anchors from the mobile node. of associated anchors from the mobile node.
+---------------------------------------------------+ +---------------------------------------------------+
( Operator's ) ( Operator's )
( core ) ( core )
+---------------------------------------------------+ +---------------------------------------------------+
| | | |
+---------------+ tunnel +---------------+ +---------------+ tunnel +---------------+
| IP stack |===============| IP stack | | IP stack |===============| IP stack |
+---------------+ +-------+-------+ +---------------+ +-------+-------+
| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
skipping to change at page 15, line 9 skipping to change at page 15, line 39
The basic idea of the DLIF concept is the following: each serving The basic idea of the DLIF concept is the following: each serving
MAAR exposes itself towards a given MN as multiple routers, one per MAAR exposes itself towards a given MN as multiple routers, one per
P-MAAR associated to the MN. Let's consider the example shown in P-MAAR associated to the MN. Let's consider the example shown in
Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6
address (prefA::MN1) from a prefix locally anchored at MAAR1 address (prefA::MN1) from a prefix locally anchored at MAAR1
(prefA::/64). At this stage, MAAR1 plays both the role of anchoring (prefA::/64). At this stage, MAAR1 plays both the role of anchoring
and serving MAAR, and also behaves as a plain IPv6 access router. and serving MAAR, and also behaves as a plain IPv6 access router.
MAAR1 creates a distributed logical interface to communicate (point- MAAR1 creates a distributed logical interface to communicate (point-
to-point link) with MN1, exposing itself as a (logical) router with a to-point link) with MN1, exposing itself as a (logical) router with a
specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and
prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF fe80::MAAR1/64) using the DLIF mn1mar1. As explained below, these
mn1mar1. As explained below, these addresses represent the "logical" addresses represent the "logical" identity of MAAR1 towards MN1, and
identity of MAAR1 towards MN1, and will "follow" the mobile node will "follow" the mobile node while roaming within the domain (note
while roaming within the domain (note that the place where all this that the place where all this information is maintained and updated
information is maintained and updated is out-of-scope of this draft; is out-of-scope of this draft; potential examples are to keep it on
potential examples are to keep it on the home subscriber server -- the home subscriber server -- HSS -- or the user's profile).
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 resemble the
resemble the one used by MAAR1 to communicate with MN1. In this one used by MAAR1 to communicate with MN1. In this example, there is
example, there is only one P-MAAR (in addition to MAAR2, which is the only one P-MAAR (in addition to MAAR2, which is the serving one):
serving one): MAAR1, so only the logical interface mn1mar1 is MAAR1, so only the logical interface mn1mar1 is created, but the same
created, but the same process would be repeated in case there were process would be repeated in case there were more P-MAARs involved.
more P-MAARs involved. In order to maintain the prefix anchored at In order to maintain the prefix anchored at MAAR1 reachable, a tunnel
MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and between MAAR1 and MAAR2 is established and the routing is modified
the routing is modified accordingly. The PBU/PBA signaling is used accordingly. The PBU/PBA signaling is used to set-up the bi-
to set-up the bi-directional tunnel between MAAR1 and MAAR2, and it directional tunnel between MAAR1 and MAAR2, and it might also be used
might also be used to convey to MAAR2 the information about the to convey to MAAR2 the information about the prefix(es) anchored at
prefix(es) anchored at MAAR1 and about the addresses of the MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1).
associated DLIF (i.e., mn1mar1).
+------------------------------------------+ +----------------------+ +------------------------------------------+ +----------------------+
| MAAR1 | | MAAR2 | | MAAR1 | | MAAR2 |
|+----------------------------------------+| |+--------------------+| |+----------------------------------------+| |+--------------------+|
||+------------------++------------------+|| ||+------------------+|| ||+------------------++------------------+|| ||+------------------+||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+||| |||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||
|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+||| |||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
||+------------------++------------------+|| ||+------------------+|| ||+------------------++------------------+|| ||+------------------+||
|| HMAC1 (phy if MAAR1) || ||HMAC2 (phy if MAAR2)|| || MAC1 (phy if MAAR1) || || MAC2 (phy if MAAR2)||
|+----------------------------------------+| |+--------------------+| |+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+ +------------------------------------------+ +----------------------+
x x x x x x
x x x x x x
(o) (o) (o) (o) (o) (o)
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 | | MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 6: Distributed Logical Interface concept Figure 6: Distributed Logical Interface concept
Figure 6 shows the logical interface concept in more detail. The Figure 6 shows the logical interface concept in more detail. The
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. Note that a serving MAAR always
P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the plays the role of anchoring MAAR for the attached (served) MNs. Each
role of anchoring MAAR for the attached (served) MNs. Each MAAR has MAAR has one single physical wireless interface as depicted in this
one single physical wireless interface. example.
As introduced before, each MN always "sees" multiple logical routers As introduced before, each MN always "sees" multiple logical routers
-- one per P-MAAR -- independently of its currently serving MAAR. -- one per anchoring MAAR -- independently of its currently serving
From the point of view of the MN, these MAARs are portrayed as MAAR. From the point of view of the MN, these MAARs are portrayed as
different routers, although the MN is physically attached to one different routers, although the MN is physically attached to one
single interface. The way this is achieved is by the serving MAAR single interface. The way this is achieved is by the serving MAAR
configuring different logical interfaces. Focusing on MN1, it is configuring different logical interfaces. Focusing on MN1, it is
currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and, currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and,
therefore, it has configured an IPv6 address from MAAR2's pool (e.g., therefore, it has configured an IPv6 address from MAAR2's pool (e.g.,
prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top
of its wireless physical interface (phy if MAAR2) which is used to of its wireless physical interface (phy if MAAR2) which is used to
serve MN1. This interface has a logical MAC address (LMAC6), serve MN1. This interface has a logical MAC address (LMAC6),
different from the hardware MAC address (HMAC2) of the physical different from the hardware MAC address (MAC2) of the physical
interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its
locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1
was attached to MAAR1, configuring also an address locally anchored was attached to MAAR1, configuring also an address locally anchored
at that MAAR, which is still being used by MN1 in active at that MAAR, which is still being used by MN1 in active
communications. MN1 keeps "seeing" an interface connecting to MAAR1, communications. MN1 keeps "seeing" an interface connecting to MAAR1,
as if it were directly connected to the two MAARs. This is achieved as if it were directly connected to the two MAARs. This is achieved
by the serving MAAR (MAAR2) configuring an additional distributed by the serving MAAR (MAAR2) configuring an additional distributed
logical interface: mn1mar1, which behaves exactly as the logical logical interface: mn1mar1, which behaves as the logical interface
interface configured by MAAR1 when MN1 was attached to it. This configured by MAAR1 when MN1 was attached to it. This means that
means that both the MAC and IPv6 addresses configured on this logical both the MAC and IPv6 addresses configured on this logical interface
interface remain the same regardless of the physical MAAR which is remain the same regardless of the physical MAAR which is serving the
serving the MN. The information required by a serving MAAR to MN. The information required by a serving MAAR to properly configure
properly configure this logical interfaces can be obtained in this logical interfaces can be obtained in different ways: as part of
different ways: as part of the information conveyed in the PBA, from the information conveyed in the PBA, from an external database (e.g.,
an external database (e.g., the HSS) or by other means. As shown in the HSS) or by other means. As shown in the figure, each MAAR may
the figure, each MAAR may have several logical interfaces associated have several logical interfaces associated to each attached MN,
to each attached MN, having always at least one (since a serving MAAR having always at least one (since a serving MAAR is also an anchoring
is also an anchoring MAAR for the attached MN). MAAR 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 preferred prefix lifetime (and a non-zero serving one) include a zero preferred prefix lifetime (and a non-zero
valid prefix lifetime, so the prefix remains valid, while being valid prefix lifetime, so the prefix remains valid, while being
deprecated). The goal is to deprecate the prefixes delegated by deprecated). The goal is to deprecate the prefixes delegated by
these MAARs (which will be no longer serving the MN). Note that on- these MAARs (so that they will no longer be serving the MN). Note
going communications may keep on using those addresses, even if they that on-going communications may keep on using those addresses, even
are deprecated, so this only affects the establishment of new if they are deprecated, so this only affects the establishment of new
sessions. 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 local IP access scenario to MAAR2). This is similar to the local IP access scenario
considered by 3GPP, where a local gateway node is selected for considered by 3GPP, where a local gateway node is selected for
sessions requiring access to services provided locally (instead of sessions requiring access to services provided locally (instead of
skipping to change at page 18, line 13 skipping to change at page 18, line 21
though MN1 is no longer attached to MAAR1. though MN1 is no longer attached to MAAR1.
4. 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.
4.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 MAAR or a CMD and not
Access Router and not from a mobile access gateway. The rest of the from a mobile access gateway. The rest of the Proxy Binding Update
Proxy Binding Update format remains the same as defined in [RFC5213]. 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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|B|S|D| Reser | Lifetime | |A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR Flag (D) DMM Flag (D)
The D Flag is set to indicate to the receiver of the message that The D Flag is set to indicate to the receiver of the message that
the Proxy Binding Update is from a MAAR. When an LMA that does the Proxy Binding Update is from a MAAR or a CMD. When an LMA
not support the extensions described in this document receives a that does not support the extensions described in this document
message with the D-Flag set, the PBU in that case MUST NOT be receives a message with the D-Flag set, the PBU in that case MUST
processed by the LMA and an error MUST be returned. NOT be processed by the LMA and an error MUST be returned.
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 receiving node MUST ignore and skip any options
not understand. that it does not understand.
4.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 Mobility Anchor and indicate that the sender supports operating as a MAAR or CMD. The
Access Router. The rest of the Proxy Binding Acknowledgment format rest of the Proxy Binding Acknowledgment format remains the same as
remains the same as defined in [RFC5213]. 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|T|B|S|D| | | Status |K|R|P|T|B|S|D| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR (D) DMM Flag (D)
The D is set to indicate that the sender of the message supports The D flag is set to indicate that the sender of the message
operating as a Mobility Anchor and Access Router. When a MAG that supports operating as a MAAR or a CMD. When a MAG that does not
does not support the extensions described in this document support the extensions described in this document receives a
receives a message with the D-Flag set, it MUST ignore the message message with the D-Flag set, it MUST ignore the message and an
and an error MUST be returned. error MUST be returned.
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.
skipping to change at page 20, line 8 skipping to change at page 20, line 10
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 MAARs and CMDs. Therefore, this option can only appear if between MAARs and CMDs. Therefore, this option can only appear if
the D bit is set in a PBU/PBA. This option is used for exchanging the D bit is set in a PBU/PBA. This option is used for exchanging
the mobile node's prefix anchored at the anchoring MAAR. There can the mobile node's prefix anchored at the anchoring MAAR. There can
be multiple Anchored Prefix options present in the message. be 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:
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 | Reserved | Prefix Length | | Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Anchored Prefix + + Anchored Prefix +
| | | |
+ + + +
| | | |
skipping to change at page 20, line 39 skipping to change at page 20, line 41
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 18. set to 18.
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.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length in bits of the
prefix contained in the option. IPv6 prefix contained in the option.
Anchored Prefix Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored A sixteen-octet field containing the mobile node's IPv6 Anchored
Prefix. Only the first Prefix Length bytes are valid for the Prefix. Only the first Prefix Length bits are valid for the
Anchored Prefix. The rest of the bytes MUST be ignored. Anchored Prefix. The rest of the bits MUST be ignored.
4.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. Therefore, this option can only appear if the D bit is set in MAARs or between a MAAR and a CMD. Therefore, this option can only
a PBU/PBA. This option is used for exchanging a prefix of a local appear if the D bit is set in a PBU/PBA. This option is used for
network that is only reachable via the anchoring MAAR. There can be exchanging a prefix of a local network that is only reachable via the
multiple Local Prefix options present in the message. anchoring MAAR. There can be 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:
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 | Reserved | Prefix Length | | Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Local Prefix + + Local Prefix +
| | | |
+ + + +
| | | |
skipping to change at page 21, line 42 skipping to change at page 21, line 49
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 18. set to 18.
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.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length in bits of the
prefix contained in the option. IPv6 prefix contained in the option.
Local Prefix Local Prefix
A sixteen-octet field containing the IPv6 Local Prefix. Only the
A sixteen-byte field containing the IPv6 Local Prefix. Only the first Prefix Length bits are valid for the IPv6 Local Prefix. The
first Prefix Length bytes are valid for the IPv6 Local Prefix. rest of the bits MUST be ignored.
The rest of the bytes MUST be ignored.
4.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:
The Previous MAAR Option has an alignment requirement of 8n+4. 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 | Prefix Length | | Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ P-MAAR's address + + P-MAAR's address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 22, line 43 skipping to change at page 22, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
IANA-3. IANA-3.
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 33. set to 34.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length in bits of the
prefix contained in the option. IPv6 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-octet 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-octet field containing the mobile node's IPv6 Home
Network Prefix. Only the first Prefix Length bytes are valid for Network Prefix. Only the first Prefix Length bits are valid for
the mobile node's IPv6 Home Network Prefix. The rest of the bytes the mobile node's IPv6 Home Network Prefix. The rest of the bits
MUST be ignored. MUST be ignored.
4.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
Proxy Binding Acknowledgement messages exchanged between the CMD and message exchanged between the CMD and a Previous MAAR. This option
a Previous MAAR. This option is used to notify the P-MAAR about the is used to notify the P-MAAR about the current Serving MAAR's global
current Serving MAAR's global address. Its format is as follows: address. Its format is as follows:
The Serving MAAR Option has an alignment requirement of 8n+6. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ S-MAAR's address + + S-MAAR's address +
skipping to change at page 23, line 45 skipping to change at page 24, line 13
IANA-4. IANA-4.
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-octet field containing the S-MAAR's IPv6 global address.
4.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 Acknowledgment message exchanged between MAARs and
exchanged between MAARs. This option is used for exchanging the between a MAAR and a CMD. 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 P-MAAR. so it resembles the DLIF configured on the P-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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DLIF Link-local Address + + DLIF Link-local Address +
| | | |
+ + + +
| | | |
skipping to change at page 24, line 35 skipping to change at page 25, line 4
IANA-5. IANA-5.
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.
DLIF Link-local Address DLIF Link-local Address
A sixteen-octet field containing the link-local address of the
A sixteen-byte field containing the link-local address of the
logical interface. logical interface.
4.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 Acknowledgment message exchanged between MAARs and
exchanged between MAARs. This option is used for exchanging the betwwe a MAAR and a CMD. 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 P-MAAR. so it resembles the DLIF configured on the P-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
specified in [RFC6275]. specified in [RFC6275].
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 | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ DLIF Link-layer Address + + DLIF Link-layer Address +
. ... . . ... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 25, line 35 skipping to change at page 25, line 50
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 S-MAAR. logical interface to be configured on the S-MAAR.
The content and format of this field (including byte and bit The content and format of this field (including octet 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.
5. IANA Considerations 5. IANA Considerations
This document defines six new mobility options that need to be This document defines six new mobility options, the Anchored Prefix
registered in the Mobility Options registry on the Mobile IPv6 Option, the Local Prefix Option, the Previous MAAR Option, the
parameters registry. The required IANA actions are marked as IANA-1 Serving MAAR Option, the DLIF Link-local Address Option and the DLIF
to IANA-6. Link-layer Address Option. The Type value for these options needs to
be assigned from the same numbering space as allocated for the other
mobility options in the "Mobility Options" registry defined in
http://www.iana.org/assignments/mobility-parameters. The required
IANA actions are marked as IANA-1 to IANA-6.
This document reserves a new flag (D) in the "Binding Update Flags"
and a new flag (D) in the "Binding Acknowledgment Flags" of the
"Mobile IPv6 parameters" registry http://www.iana.org/assignments/
mobility-parameters.
6. 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.
When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a
single PBU to multiple previous MAARs. In situations of many fast single PBU to multiple previous MAARs. In situations of many fast
handovers (e.g., with vehicular networks), there may exist multiple handovers (e.g., with vehicular networks), there may exist multiple
previous (e.g., k) MAARs exist. In this situation, the CMD creates k previous (e.g., k) MAARs. In this situation, the CMD creates k
outgoing packets from a single incoming packet. This bears a certain outgoing packets from a single incoming packet. This bears a certain
amplification risk. The CMD SHOULD use a pacing approach to limit amplification risk. The CMD MUST use a pacing approach in the
this amplification risk. outgoing queue to cap the output traffic (i.e., the rate of PBUs
sent) to limit this amplification risk.
When the CMD acts as MAAR locator, mobility signaling (PBAs) is When the CMD acts as MAAR locator, mobility signaling (PBAs) is
exchanged between P-MAARs and current S-MAAR. This requires security exchanged between P-MAARs and current S-MAAR. Hence, security
associations to exist between the involved MAARs (in addition to the associations are REQUIRED to exist between the involved MAARs (in
ones needed with the CMD). addition to the ones needed with the CMD).
Since deregistration is performed by timeout, measures SHOULD be Since deregistration is performed by timeout, measures SHOULD be
implemented to minimize the risks associated to continued resource implemented to minimize the risks associated to continued resource
consumption (DoS attacks), e.g., imposing a limit of the number of consumption (DoS attacks), e.g., imposing a limit of the number of
P-MAARs associated to a given MN. P-MAARs associated to a given MN.
The CMD and the participating MAARs MUST be trusted parties,
authorized perform all operations relevant to their role.
There are some privacy considerations to consider. While the
involved parties trust each other, the signalling involves disclosing
information about the previous locations visited by each MN, as well
as the active prefixes they are using at a given point of time.
Therefore, mechanisms MUST be in place to ensure that MAARs and CMD
do not disclose this information to other parties nor use it for
other ends that providing the distributed mobility support specified
in this document.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Dirk von Hugo, John Kaippallimalil, The authors would like to thank Dirk von Hugo, John Kaippallimalil,
Ines Robles and Joerg Ott for the comments on this document. The Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja
authors would also like to thank Marco Liebsch, Dirk von Hugo, Alex Kuehlewind, Eric Vyncke, Adam Roach, Benjamin Kaduk and Roman Danyliw
Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and for the comments on this document. The authors would also like to
Satoru Matsushima for their comments and discussion on the documents thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo,
Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru Matsushima for
their comments and discussion on the documents
[I-D.bernardos-dmm-distributed-anchoring] and [I-D.bernardos-dmm-distributed-anchoring] and
[I-D.bernardos-dmm-pmip] on which the present document is based. [I-D.bernardos-dmm-pmip] on which the present document is based.
The authors would also like to thank Lyle Bertz and Danny Moses for The authors would also like to thank Lyle Bertz and Danny Moses for
their in-deep review of this document and their very valuable their in-deep review of this document and their very valuable
comments and suggestions. comments and suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 27, line 23 skipping to change at page 28, line 14
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.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]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment-
models-04 (work in progress), May 2018.
[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 [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>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
<https://www.rfc-editor.org/info/rfc8563>. <https://www.rfc-editor.org/info/rfc8563>.
Appendix A. Comparison with Requirement document
In this section we describe 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."
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."
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 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
instruct MAARs to always establish a tunnel with the same MAAR,
working as LMA. The fully distributed DMM solution (distributed data
and control plane) can be extended as well, but it requires more
intervention. The partially distributed DMM solution can be deployed
across different domains with trust agreements if the CMDs of the
operators are enabled to transfer context from one node to another.
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 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.
A.8. Multicast considerations
"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.
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 stops 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. Moreover, it should be noted that the protocols designed in
the 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 Authors' Addresses
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
 End of changes. 85 change blocks. 
416 lines changed or deleted 271 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/