draft-ietf-dmm-pmipv6-dlif-01.txt   draft-ietf-dmm-pmipv6-dlif-02.txt 
DMM Working Group CJ. Bernardos DMM Working Group CJ. Bernardos
Internet-Draft A. de la Oliva Internet-Draft A. de la Oliva
Intended status: Standards Track UC3M Intended status: Standards Track UC3M
Expires: December 31, 2018 F. Giust Expires: March 2, 2019 F. Giust
NEC Athonet
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
A. Mourad A. Mourad
InterDigital InterDigital
June 29, 2018 August 29, 2018
Proxy Mobile IPv6 extensions for Distributed Mobility Management Proxy Mobile IPv6 extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-01 draft-ietf-dmm-pmipv6-dlif-02
Abstract Abstract
Distributed Mobility Management solutions allow for setting up Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does networks so that traffic is distributed in an optimal way and does
not rely on centralized deployed anchors to provide IP mobility not rely on 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
(like Proxy Mobile IPv6), or client-based mobility protocols (as (like Proxy Mobile IPv6), or client-based mobility protocols (like
Mobile IPv6), among others. This document follows the former Mobile IPv6), among others. This document follows the former
approach, and proposes a solution based on Proxy Mobile IPv6 in which approach and proposes a solution based on Proxy Mobile IPv6 in which
mobility sessions are anchored at the last IP hop router (called mobility sessions are anchored at the last IP hop router (called
mobility anchor and access router). The mobility anchor and access mobility anchor and access router). The mobility anchor and access
router is an enhanced access router which is also able to operate as router is an enhanced access router which is also able to operate as
local mobility anchor or mobility access gateway, on a per prefix a local mobility anchor or mobility access gateway, on a per prefix
basis. The document focuses on the required extensions to basis. The document focuses on the required extensions to
effectively support simultaneously anchoring several flows at effectively support simultaneously anchoring several flows at
different distributed gateways. different distributed gateways.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2018. This Internet-Draft will expire on March 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5
3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7
3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8
3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12
3.6. The Distributed Logical Interface (DLIF) concept . . . . 12 3.6. The Distributed Logical Interface (DLIF) concept . . . . 12
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 16 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 16
4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 17 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 17
4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 17 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 18
4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 18 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 19
4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 19 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 20
4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 21 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 21
4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 21 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 22
4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 22 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Comparison with Requirement document . . . . . . . . 25 Appendix A. Comparison with Requirement document . . . . . . . . 25
A.1. Distributed mobility management . . . . . . . . . . . . . 25 A.1. Distributed mobility management . . . . . . . . . . . . . 25
A.2. Bypassable network-layer mobility support for each A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . . . . . . 26 application session . . . . . . . . . . . . . . . . . . . 26
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26
A.5. Coexistence with deployed networks/hosts and operability A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 27 across different networks . . . . . . . . . . . . . . . . 27
A.6. Operation and management considerations . . . . . . . . . 27 A.6. Operation and management considerations . . . . . . . . . 27
A.7. Security considerations . . . . . . . . . . . . . . . . . 27 A.7. Security considerations . . . . . . . . . . . . . . . . . 27
A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Implementation experience . . . . . . . . . . . . . 28 Appendix B. Implementation experience . . . . . . . . . . . . . 28
Appendix C. Applicability to the fog environment . . . . . . . . 29 Appendix C. Applicability to the fog environment . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Distributed Mobility Management (DMM) paradigm aims at minimizing The Distributed Mobility Management (DMM) paradigm aims at minimizing
the impact of currently standardized mobility management solutions, the impact of currently standardized mobility management solutions
which are centralized (at least to a considerable extent). which are centralized (at least to a considerable extent).
Current IP mobility solutions, standardized with the names of Mobile Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite
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
problems, signaling overhead (and most likely a longer associated problems, signaling overhead (and most likely a longer associated
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 on 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 MN. Following this idea, bringing the mobility anchor closer to the Mobile Node (MN).
in our proposal, the central anchor is moved to the edge of the Following this idea, in our proposal, the central anchor is moved to
network, being deployed in the default gateway of the mobile node. the edge of the network, being deployed in the default gateway of the
That is, the first elements that provide IP connectivity to a set of mobile node. That is, the first elements that provide IP
MNs are also the mobility managers for those MNs. In the following, connectivity to a set of MNs are also the mobility managers for those
we will call these entities Mobility Anchor and Access Routers MNs. In the following, we will call these entities Mobility Anchor
(MAARs). and 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 working in a distributed manner [RFC7429]. Mobility is making PMIPv6 working in a distributed manner [RFC7429]. Mobility
is handled by the network without the MNs involvement, but, is handled by the network without the MNs involvement, but,
differently from PMIPv6, when the MN moves from one access network to differently from PMIPv6, when the MN moves from one access network to
another, it also changes anchor router, hence requiring signaling another, it also changes anchor router, hence requiring signaling
between the anchors to retrieve the MN's previous location(s). Also, between the anchors to retrieve the MN's previous location(s). Also,
a key-aspect of network-based DMM, is that a prefix pool belongs a key-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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
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 used in this document are defined in the DMM
Deployment Models and Architectural Considerations document Deployment Models and Architectural Considerations document
[I-D.ietf-dmm-deployment-models]: [I-D.ietf-dmm-deployment-models]:
Home Control-Plane Anchor (H-CPA) Home Control-Plane Anchor (Home-CPA)
Home Data Plane Anchor (Home-DPA) Home Data Plane Anchor (Home-DPA)
Access Control Plane Node (Access-CPN) Access Control Plane Node (Access-CPN)
Access Data Plane Node (Access-DPN) Access Data Plane Node (Access-DPN)
The following terms are defined and used in this document: The following terms are defined and used in this document:
MAAR (Mobility Anchor and Access Router). First hop router where the MAAR (Mobility Anchor and Access Router). First hop router where the
mobile nodes attach to. It also plays the role of mobility mobile nodes attach to. It also plays the role of mobility
manager for the IPv6 prefixes it anchors, running the manager for the IPv6 prefixes it anchors, running the
functionalities of PMIP's MAG and LMA. Depending on the prefix, functionalities of PMIP's MAG and LMA. Depending on the prefix,
it plays the role of Access-DPN, Home-DPA and Access-CPN. it plays the role of Access-DPN, Home-DPA and Access-CPN.
CMD (Central Mobility Database). Node that stores the BCEs allocated CMD (Central Mobility Database). Node that stores the BCEs allocated
for the MNs in the mobility domain. It plays the role of H-CPA. for the MNs in the mobility domain. It plays the role of Home-
CPA.
P-MAAR (Previous MAAR). MAAR which was previously visited by the MN P-MAAR (Previous MAAR). MAAR which was previously visited by the MN
and is still involved in an active flow using an IPv6 prefix it and is still involved in an active flow using an IPv6 prefix it
has advertised to the MN (i.e., MAAR where that IPv6 prefix is has advertised to the MN (i.e., MAAR where that IPv6 prefix is
anchored). There might be multiple P-MAARs for an MN's mobility anchored). It plays the role of Home-DPA for the flows it is
session. It plays the role of Home-DPA. still serving for the MN's mobility session. There might be
multiple P-MAARs for an MN's mobility session.
S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. S-MAAR (Serving MAAR). MAAR which the MN is currently attached to.
Depending on the prefix, it plays the role of Access-DPN, Home-DPA Depending on the prefix, it plays the role of Access-DPN, Home-DPA
and Access-CPN. and Access-CPN.
DLIF (Distributed Logical Interface). It is a logical interface at DLIF (Distributed Logical Interface). It is a logical interface at
the IP stack of the MAAR. For each active prefix used by the the IP stack of the MAAR. For each active prefix used by the
mobile node, the serving MAAR has a DLIF configured (associated to mobile node, the S-MAAR has a DLIF configured (associated to each
the anchoring MAAR). In this way, a serving MAAR exposes itself MAAR still anchoring flows). In this way, a S-MAAR exposes itself
towards each MN as multiple routers, one per active anchoring towards each MN as multiple routers, one as itself and one per
MAAR. P-MAAR.
3. PMIPv6 DMM extensions 3. PMIPv6 DMM extensions
The solution consists in 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 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 Central Mobility Database (CMD), which is
therefore an H-CPA. Also, the CMD is able to send and parse both therefore an Home-CPA. Also, the CMD is able to send and parse
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 have to be extended to include information o The binding cache will be extended to include information
regarding previous MAARs where the mobile node was anchored and regarding P-MAARs where the mobile node was anchored and still
still retains active data sessions, see Appendix B for further retains active data sessions, see Appendix B for further details.
details.
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 on the Central Mobility Database (CMD) to access The MAARs leverage the Central Mobility Database (CMD) to access and
and update information related to the MNs, stored as mobility update information related to the MNs, stored as mobility sessions;
sessions; hence, a centralized node maintains a global view on the hence, a centralized node maintains a global view of the network
status of the network. The CMD is queried whenever a MN is detected status. The CMD is queried whenever a MN is detected to join/leave
to join/leave the mobility domain. It might be a fresh attachment, a the mobility domain. It might be a fresh attachment, a detachment or
detachment or a handover, but as MAARs are not aware of past a handover, but as MAARs are not aware of past information related to
information related to a mobility session, they contact the CMD to a mobility session, they contact the CMD to retrieve the data of
retrieve the data of interest and eventually take the appropriate interest and eventually take the appropriate action. The procedure
action. The procedure adopted for the query and the messages adopted for the query and the messages exchange sequence might vary
exchange sequence might vary to optimize the update latency and/or to optimize the update latency and/or the signaling overhead. Here
the signaling overhead. Here is presented one method for the initial is presented one method for the initial registration, and three
registration, and three different approaches to update the mobility different approaches to update the mobility sessions using PBUs and
sessions using PBUs and PBAs. Each approach assigns a different role PBAs. Each approach assigns a different role to the CMD:
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 This solution can be categorized under Model-1: Split Home Anchor
Mode in [I-D.ietf-dmm-deployment-models]. As another note, the Mode in [I-D.ietf-dmm-deployment-models]. As another note, the
solution described in this document allows performing per-prefix solution described in this document allows performing per-prefix
anchoring decisions, to support e.g., some flows to be anchored at a anchoring decisions, to support e.g., some flows to be anchored at a
central Home-DPA (like a traditional LMA) or to enable an application central Home-DPA (like a traditional LMA) or to enable an application
to switch to the locally anchored prefix to gain route optimization, to switch to the locally anchored prefix to gain route optimization,
as indicated in [I-D.ietf-dmm-ondemand-mobility]. as indicated in [I-D.ietf-dmm-ondemand-mobility].
Note that an MN MAY move across diferent MAARs, which might involve Note that a MN MAY move across different MAARs, which might result in
that several P-MAARs exist at a given moment of time, each of them several P-MAARs existing at a given moment of time, each of them
anchoring a prefix used by the MN. anchoring a prefix used by the MN.
3.1. Initial registration 3.1. Initial registration
Upon the MN's attachment to a MAAR, say MAAR1, if the MN is Upon the MN's attachment to a MAAR, say MAAR1 as shown in Figure 1,
authorized for the service, an IPv6 global prefix belonging to the if the MN is authorized for the service, an IPv6 global prefix
MAAR's prefix pool is reserved for it (Pref1) into a temporary belonging to the MAAR1's prefix pool is reserved for it (Pref1) into
Binding Cache Entry (BCE) allocated locally. The prefix is sent in a a temporary Binding Cache Entry (BCE) allocated locally. The prefix
[RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which, is sent in a [RFC5213] PBU with the MN's Identifier (MN-ID) to the
since the session is new, stores a permanent BCE containing as main CMD, which, since the session is new, stores a permanent BCE
fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. containing as primary fields the MN-ID, the MN's prefix and MAAR1's
The CMD replies to MAAR1 with a PBA including the usual options address as Proxy-CoA. The CMD replies to MAAR1 with a PBA including
defined in PMIP/RFC5213, meaning that the MN's registration is fresh the usual options defined in PMIPv6 [RFC5213], meaning that the MN's
and no past status is available. MAAR1 definitely stores the registration is fresh and no past status is available. MAAR1 stores
temporary BCE previously allocated and unicasts a Router the temporary BCE previously allocated and unicasts a Router
Advertisement (RA) to the MN including the prefix reserved before, Advertisement (RA) to the MN including the prefix reserved before,
that can be used by the MN to configure an IPv6 address (e.g., with that can be used by the MN to configure an IPv6 address (e.g., with
stateless auto-configuration, SLAAC). Alternative IPv6 auto- stateless auto-configuration, SLAAC). Alternative IPv6 auto-
configuration mechanisms can also be used, though this document configuration mechanisms can also be used, though this document
describe the SLAAC-based one. The address is routable at the MAAR, describes the SLAAC-based one. The address is routable at the MAAR,
in the sense that it is on the path of packets addressed to the MN. in the sense that it is on the path of packets addressed to the MN.
Moreover, the MAAR acts as plain router for those packets, as no Moreover, the MAAR acts as plain router for those packets, as no
encapsulation nor special handling takes place. Figure 1 illustrates encapsulation nor special handling takes place.
this scenario.
+-----+ +---+ +--+ +-----+ +---+ +--+
|MAAR1| |CMD| |CN| |MAAR1| |CMD| |CN|
+-----+ +---+ +*-+ +-----+ +---+ +*-+
| | * | | *
MN | * +---+ MN | * +---+
attach. | ***** _|CMD|_ attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \ detection | flow1 * / +-+-+ \
| | * / | \ | | * / | \
local BCE | * / | \ local BCE | * / | \
skipping to change at page 8, line 5 skipping to change at page 8, line 5
finalized | * finalized | *
| | Pref1 * | | Pref1 *
| | +*-+ | | +*-+
| | |MN| | | |MN|
| | +--+ | | +--+
Operations sequence Packets flow Operations sequence Packets flow
Figure 1: First attachment to the network Figure 1: First attachment to the network
Note that the registration process does not change regardless of the
CMD's modes (relay, locator or proxy) described next.
3.2. The CMD as PBU/PBA relay 3.2. The CMD as PBU/PBA relay
When the MN moves from its current access and associates to MAAR2 When the MN moves from its current access and attaches to MAAR2 (now
(now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a
stores a temporary BCE, and it sends a plain PBU to the CMD for temporary BCE, and it sends a plain PBU to the CMD for registration.
registration. Upon PBU reception and BC lookup, the CMD retrieves an Upon PBU reception and BC lookup, the CMD retrieves an already
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;
location; thus, the CMD forwards the PBU to the MAAR indicated as thus, the CMD forwards the PBU to the MAAR indicated as Proxy CoA
Proxy CoA (MAAR1), including a new mobility option to communicate the (MAAR1), including a new mobility option to communicate the S-MAAR's
S-MAAR's global address to MAAR1, defined as Serving MAAR Option in global address to MAAR1, defined as Serving MAAR Option in
Section 4.6. The CMD updates the P-CoA field in the BCE related to Section 4.6. The CMD updates the P-CoA field in the BCE related to
the MN with the S-MAAR's address. the MN with the S-MAAR's address.
Upon PBU reception, MAAR1 can install a tunnel on its side towards Upon PBU reception, MAAR1 can install a tunnel on its side towards
MAAR2 and the related routes for Pref1. Then MAAR1 replies to the MAAR2 and the related routes for Pref1. Then MAAR1 replies to the
CMD with a PBA (including the option mentioned before) to ensure that CMD with a PBA (including the option mentioned before) to ensure that
the new location has successfully changed, containing the prefix the new location has successfully changed, containing the prefix
anchored at MAAR1 in the Home Network Prefix option. The CMD, after anchored at MAAR1 in the Home Network Prefix option. The CMD, after
receiving the PBA, updates the BCE populating an instance of the receiving the PBA, updates the BCE populating an instance of the
P-MAAR list. The P-MAAR list is an additional field on the BCE that P-MAAR list. The P-MAAR list is an additional field on the BCE that
skipping to change at page 9, line 32 skipping to change at page 9, line 32
| |--- PBA*-->| +*--*+ | |--- PBA*-->| +*--*+
| | route ---move-->|*MN*| | | route ---move-->|*MN*|
| | update +----+ | | update +----+
Operations sequence Data Packets flow Operations sequence Data Packets flow
PBU/PBA Messages with * contain PBU/PBA Messages with * contain
a new mobility option a new mobility option
Figure 2: Scenario after a handover, CMD as relay Figure 2: Scenario after a handover, CMD as relay
For next MN's movements the process is repeated except for the number For MN's next movements the process is repeated except the number of
of P-MAARs involved, that rises accordingly to the number of prefixes P-MAARs involved increases, that rises accordingly to the number of
that the MN wishes to maintain. Indeed, once the CMD receives the prefixes that the MN wishes to maintain. Indeed, once the CMD
first PBU from the new S-MAAR, it forwards copies of the PBU to all receives the first PBU from the new S-MAAR, it forwards copies of the
the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e.,
prior to handover) and in the P-MAARs list. They reply with a PBA to the MAAR prior to handover) and in the P-MAARs list. They reply with
the CMD, which aggregates them into a single one to notify the a PBA to the CMD, which aggregates them into a single one to notify
S-MAAR, that finally can establish the tunnels with the P-MAARs. 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.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
described in Section 3.2 up to the moment the P-MAAR receives the PBU described in Section 3.2 up to the moment the P-MAAR receives the PBU
with the P-MAAR option. At that point a P-MAAR is aware of the new with the P-MAAR option. At that point a P-MAAR is aware of the new
MN's location (because of the S-MAAR's address in the S-MAAR option), MN's location (because of the S-MAAR's address in the S-MAAR option),
and, besides sending a PBA to the CMD, it also sends a PBA to the and, besides sending a PBA to the CMD, it also sends a PBA to the
S-MAAR including the prefix it is anchoring. This latter PBA does S-MAAR including the prefix it is anchoring. This latter PBA does
not need to include new options, as the prefix is embedded in the HNP not need to include new options, as the prefix is embedded in the HNP
option and the P-MAAR's address 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. In Figure 3 is illustrated the new messages sequence, while routes. Figure 3 illustrates the new message sequence, while the
the data forwarding is unaltered. data forwarding is unaltered.
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
skipping to change at page 12, line 34 skipping to change at page 12, line 34
o A previous MAAR stops the BCE timer upon receiving a PBU from the o A previous MAAR stops the BCE timer upon receiving a PBU from the
CMD containing a "Serving MAAR" option. In this way only the CMD containing a "Serving MAAR" option. In this way only the
Serving MAAR is allowed to de-register the mobility session, Serving MAAR is allowed to de-register the mobility session,
arguing that the MN left definitely the domain. arguing that the MN left definitely the domain.
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, send back a PBA with a non-zero lifetime, hence re- lifetime, send back a PBA with a non-zero lifetime, hence re-
newing the session, if the MN is still connected to the domain. newing the session, if the MN is still connected to the domain.
The evaluation of these methods is left for future work.
3.6. The Distributed Logical Interface (DLIF) concept 3.6. The Distributed Logical Interface (DLIF) concept
One of the main challenges of a network-based DMM solution is how to One of the main challenges of a network-based DMM solution is how to
allow a mobile node to simultaneously send/receive traffic which is allow a mobile node to simultaneously send/receive traffic which is
anchored at different MAARs, and how to influence on the preference anchored at different MAARs, and how to influence on the preference
of the mobile node selecting the source IPv6 address for a new of the mobile node selecting the source IPv6 address for a new
communication, without requiring special support on the mobile node communication, without requiring special support on the mobile node
stack. This document defines the Distributed Logical Interface stack. This document defines the Distributed Logical Interface
(DLIF), which is a software construct that allows to easily hide the (DLIF), which is a software construct that allows to easily hide the
change of anchor from the mobile node. change of anchor from the mobile node.
skipping to change at page 13, line 28 skipping to change at page 13, line 28
x x x x
x x x x
prefA::/64 x x prefB::/64 prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x (AdvPrefLft=0) x x
(o) (o)
| |
+-----+ +-----+
prefA::MN1 | MN1 | prefB::MN1 prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+ (deprecated) +-----+
Figure 5: DLIF: exposing multiple routers (one per active anchoring Figure 5: DLIF: exposing multiple routers (one per P-MAAR)
MAAR)
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
active anchoring MAAR associated to the MN. Let's consider the P-MAAR associated to the MN. Let's consider the example shown in
example shown in Figure 5, MN1 initially attaches to MAAR1, Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6
configuring an IPv6 address (prefA::MN1) from a prefix locally address (prefA::MN1) from a prefix locally anchored at MAAR1
anchored at MAAR1 (prefA::/64). At this stage, MAAR1 plays both the (prefA::/64). At this stage, MAAR1 plays both the role of anchoring
role of anchoring and serving MAAR, and also it behaves as a plain and serving MAAR, and also it behaves as a plain IPv6 access router.
IPv6 access router. MAAR1 creates a distributed logical interface to MAAR1 creates a distributed logical interface to communicate (point-
communicate (point-to-point link) with MN1, exposing itself as a to-point link) with MN1, exposing itself as a (logical) router with a
(logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g.,
IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF
using the DLIF mn1mar1. As explained below, these addresses mn1mar1. As explained below, these addresses represent the "logical"
represent the "logical" identity of MAAR1 towards MN1, and will identity of MAAR1 towards MN1, and will "follow" the mobile node
"follow" the mobile node while roaming within the domain (note that while roaming within the domain (note that the place where all this
the place where all this information is maintained and updated is information is maintained and updated is out-of-scope of this draft;
out-of-scope of this draft; potential examples are to keep it on the potential examples are to keep it on the home subscriber server --
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 exactly
resemble the one used by MAAR1 to communicate with MN1. In this resemble the one used by MAAR1 to communicate with MN1. In this
example, there is only one active anchoring MAAR (in addition to example, there is only one P-MAAR (in addition to MAAR2, which is the
MAAR2, which is the serving one): MAAR1, so only the logical serving one): MAAR1, so only the logical interface mn1mar1 is
interface mn1mar1 is created, but the same process would be repeated created, but the same process would be repeated in case there were
in case there were more active anchoring MAARs involved. In order to more P-MAARs involved. In order to maintain the prefix anchored at
maintain the prefix anchored at MAAR1 reachable, a tunnel between MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and
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 |||
skipping to change at page 14, line 44 skipping to change at page 14, line 43
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| 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. MN1, MN2 and MN3 have two
active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the
always plays the role of anchoring MAAR for the attached (served) role of anchoring MAAR for the attached (served) MNs. Each MAAR has
MNs. Each MAAR has one single physical wireless interface. one single physical wireless interface.
As introduced before, each MN always "sees" multiple logical routers As introduced before, each MN always "sees" multiple logical routers
-- one per active anchoring MAAR -- independently of to which serving -- one per P-MAAR -- independently of to which serving MAAR the MN is
MAAR the MN is currently attached. From the point of view of the MN, currently attached. From the point of view of the MN, these MAARs
these MAARs are portrayed as different routers, although the MN is are portrayed as different routers, although the MN is physically
physically attached to one single interface. The way this is attached to one single interface. The way this is achieved is by the
achieved is by the serving MAAR configuring different logical serving MAAR configuring different logical interfaces. If we focus
interfaces. If we focus on MN1, it is currently attached to MAAR2 on MN1, it is currently attached to MAAR2 (i.e., MAAR2 is its serving
(i.e., MAAR2 is its serving MAAR) and, therefore, it has configured MAAR) and, therefore, it has configured an IPv6 address from MAAR2's
an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set- pool (e.g., prefB::/64). MAAR2 has set-up a logical interface
up a logical interface (mn1mar2) on top of its wireless physical (mn1mar2) on top of its wireless physical interface (phy if MAAR2)
interface (phy if MAAR2) which is used to serve MN1. This interface which is used to serve MN1. This interface has a logical MAC address
has a logical MAC address (LMAC6), different from the hardware MAC (LMAC6), different from the hardware MAC address (HMAC2) of the
address (HMAC2) of the physical interface of MAAR2. Over the mn1mar2 physical interface of MAAR2. Over the mn1mar2 interface, MAAR2
interface, MAAR2 advertises its locally anchored prefix prefB::/64. advertises its locally anchored prefix prefB::/64. Before attaching
Before attaching to MAAR2, MN1 visited MAAR1, configuring also an to MAAR2, MN1 visited MAAR1, configuring also an address locally
address locally anchored at this MAAR, which is still being used by anchored at this MAAR, which is still being used by the MN1 in active
the MN1 in active communications. MN1 keeps "seeing" an interface communications. MN1 keeps "seeing" an interface connecting to MAAR1,
connecting to MAAR1, as if it were directly connected to the two as if it were directly connected to the two MAARs. This is achieved
MAARs. This is achieved by the serving MAAR (MAAR2) configuring an by the serving MAAR (MAAR2) configuring an additional distributed
additional distributed logical interface: mn1mar1, which behaves logical interface: mn1mar1, which behaves exactly as the logical
exactly as the logical interface configured by the actual MAAR1 when interface configured by the actual MAAR1 when MN1 was attached to it.
MN1 was attached to it. This means that both the MAC and IPv6 This means that both the MAC and IPv6 addresses configured on this
addresses configured on this logical interface remain the same logical interface remain the same regardless of the physical MAAR
regardless of the physical MAAR which is serving the MN. The which is serving the MN. The information required by a serving MAAR
information required by a serving MAAR to properly configure this to properly configure this logical interfaces can be obtained in
logical interfaces can be obtained in different ways: as part of the different ways: as part of the information conveyed in the PBA, from
information conveyed in the PBA, from an external database (e.g., the an external database (e.g., the HSS) or by other means. As shown in
HSS) or by other means. As shown in the figure, each MAAR may have the figure, each MAAR may have several logical interfaces associated
several logical interfaces associated to each attached MN, having to each attached MN, having always at least one (since a serving MAAR
always at least one (since a serving MAAR is also an anchoring MAAR is also an anchoring MAAR for the attached MN).
for the attached MN).
In order to enforce the use of the prefix locally anchored at the In order to enforce the use of the prefix locally anchored at the
serving MAAR, the router advertisements sent over those logical serving MAAR, the router advertisements sent over those logical
interfaces playing the role of anchoring MAARs (different from the interfaces playing the role of anchoring MAARs (different from the
serving one) include a zero 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 (which will be no longer serving the MN). Note that on-
going communications keep on using those addresses, even if they are going communications keep on using those addresses, even if they are
deprecated, so this only affects to new sessions. deprecated, so this only affects to new sessions.
The distributed logical interface concept also enables the following The distributed logical interface concept also enables the following
use case. Suppose that access to a local IP network is provided by a use case. Suppose that access to a local IP network is provided by a
given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that
the resources available at that network cannot be reached from the resources available at that network cannot be reached from
outside the local network (e.g., cannot be accessed by an MN attached outside the local network (e.g., cannot be accessed by an MN attached
to MAAR2). This is similar to the local IP access scenario to MAAR2). This is similar to the local IP access scenario
considered by 3GPP. The goal is to allow an MN to be able to roam considered by 3GPP, where a local gateway node is selected for
while still being able to have connectivity to this local IP network. sessions requiring access to services provided locally (instead of
The solution adopted to support this case makes use of RFC 4191 going through a central gateway). The goal is to allow an MN to be
[RFC4191] more specific routes when the MN moves to a MAAR different able to roam while still being able to have connectivity to this
from the one providing access to the local IP network (MAAR1 in the local IP network. The solution adopted to support this case makes
example). These routes are advertised through the distributed use of RFC 4191 [RFC4191] more specific routes when the MN moves to a
logical interface representing the MAAR providing access to the local MAAR different from the one providing access to the local IP network
network (MAAR1 in this example). In this way, if MN1 moves from (MAAR1 in the example). These routes are advertised through the
MAAR1 to MAAR2, any active session that MN1 may have with a node of distributed logical interface representing the MAAR providing access
the local network connected to MAAR1 will survive, being the traffic to the local network (MAAR1 in this example). In this way, if MN1
forwarded via the tunnel between MAAR1 and MAAR2. Also, any moves from MAAR1 to MAAR2, any active session that MN1 may have with
potential future connection attempt towards the local network will be a node of the local network connected to MAAR1 will survive, being
supported, even though MN1 is no longer attached to MAAR1. the traffic forwarded via the tunnel between MAAR1 and MAAR2. Also,
any potential future connection attempt towards the local network
will be supported, even 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 Mobility Anchor and
skipping to change at page 16, line 44 skipping to change at page 16, line 44
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR Flag (D) MAAR 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. the Proxy Binding Update is from a MAAR. When an LMA that does
not support the extensions described in this document receives a
message with the D-Flag set, the PBU in that case MUST 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 MAAR MUST ignore and skip any options that it does
not understand. 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 distributed gateway. indicate that the sender supports operating as a Mobility Anchor and
The rest of the Proxy Binding Acknowledgment format remains the same Access Router. The rest of the Proxy Binding Acknowledgment format
as defined in [RFC5213]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|D| Reser | | Status |K|R|P|D| Reser |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR (D) MAAR (D)
The D is set to indicate that the sender of the message supports The D is set to indicate that the sender of the message supports
operating as a distributed gateway. operating as a Mobility Anchor and Access Router. When a MAG that
does not support the extensions described in this document
receives a message with the D-Flag set, the PBA in that case MUST
NOT be processed by the MAG 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 MAAR MUST ignore and skip any options that it does
not understand. not understand.
4.3. Anchored Prefix Option 4.3. Anchored Prefix Option
A new Anchored Prefix option is defined for use with the Proxy A new Anchored Prefix option is defined for use with the Proxy
Binding Update and Proxy Binding Acknowledgment messages exchanged Binding Update and Proxy Binding Acknowledgment messages exchanged
between distributed gateways. This option is used for exchanging the between MAARs and CMDs. Therefore, this option can only appear if
mobile node's prefix anchored at the anchoring MAAR. There can be the D bit is set in a PBU/PBA. This option is used for exchanging
multiple Anchored Prefix options present in the message. the mobile node's prefix anchored at the anchoring MAAR. There can
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. TBD1.
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 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
skipping to change at page 18, line 40 skipping to change at page 19, line 4
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 of the IPv6
prefix contained in the option. prefix contained in the option.
Anchored Prefix Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored A sixteen-byte field containing the mobile node's IPv6 Anchored
Prefix. Prefix.
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. This option is used for exchanging a prefix of a local MAARs. Therefore, this option can only appear if the D bit is set in
a PBU/PBA. This option is used for exchanging a prefix of a local
network that is only reachable via the anchoring MAAR. There can be network that is only reachable via the anchoring MAAR. There can be
multiple Local Prefix options present in the message. multiple Local Prefix options present in the message.
The Local Prefix Option has an alignment requirement of 8n+4. Its The Local Prefix Option has an alignment requirement of 8n+4. Its
format is as follows: format is as follows:
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 |
skipping to change at page 19, line 24 skipping to change at page 19, line 35
+ + + +
| | | |
+ Local Prefix + + Local Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. TBD2.
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 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
skipping to change at page 20, line 29 skipping to change at page 20, line 41
+ + + +
| | | |
+ Home Network Prefix + + Home Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. TBD3.
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 33.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
skipping to change at page 21, line 28 skipping to change at page 21, line 37
+ + + +
| | | |
+ S-MAAR's address + + S-MAAR's address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. TBD4.
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 16. set to 16.
Serving MAAR's address Serving MAAR's address
A sixteen-byte field containing the S-MAAR's IPv6 global address. A sixteen-byte field containing the S-MAAR's IPv6 global address.
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 Update and Proxy Binding Acknowledgment messages
exchanged between MAARs. This option is used for exchanging the exchanged between MAARs. This option is used for exchanging the
link-local address of the DLIF to be configured on the serving MAAR link-local address of the DLIF to be configured on the serving MAAR
so it resembles the DLIF configured on the anchoring MAAR. so it resembles the DLIF configured on the 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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
To be assigned by IANA. TBD5.
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-byte 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 Update and Proxy Binding Acknowledgment messages
exchanged between MAARs. This option is used for exchanging the exchanged between MAARs. This option is used for exchanging the
link-layer address of the DLIF to be configured on the serving MAAR link-layer address of the DLIF to be configured on the serving MAAR
so it resembles the DLIF configured on the anchoring MAAR. so it resembles the DLIF configured on the 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
To be assigned by IANA. TBD6.
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. octets, excluding the type and length fields.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
skipping to change at page 24, line 16 skipping to change at page 24, line 23
MAAR. MAAR.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex
Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and
Satoru Matsushima for their comments and discussion on the documents 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 for his deep review
of this document and his very valuable comments and suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
skipping to change at page 25, line 18 skipping to change at page 25, line 25
bernardos-dmm-pmip-09 (work in progress), September 2017. bernardos-dmm-pmip-09 (work in progress), September 2017.
[I-D.ietf-dmm-deployment-models] [I-D.ietf-dmm-deployment-models]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-04 (work in progress), May 2018. models-04 (work in progress), May 2018.
[I-D.ietf-dmm-ondemand-mobility] [I-D.ietf-dmm-ondemand-mobility]
Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S.
Jeon, "On Demand Mobility Management", draft-ietf-dmm- Jeon, "On Demand Mobility Management", draft-ietf-dmm-
ondemand-mobility-14 (work in progress), March 2018. ondemand-mobility-15 (work in progress), July 2018.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<https://www.rfc-editor.org/info/rfc7333>. <https://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015, DOI 10.17487/RFC7429, January 2015,
skipping to change at page 32, line 15 skipping to change at page 32, line 15
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 8803 Phone: +34 91624 8803
Email: aoliva@it.uc3m.es Email: aoliva@it.uc3m.es
URI: http://www.it.uc3m.es/aoliva/ URI: http://www.it.uc3m.es/aoliva/
Fabio Giust Fabio Giust
NEC Laboratories Europe Athonet S.r.l.
NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg D-69115
Germany
Phone: +49 6221 4342216 Email: fabio.giust.2011@ieee.org
Email: fabio.giust@neclab.eu
Juan Carlos Zuniga Juan Carlos Zuniga
SIGFOX SIGFOX
425 rue Jean Rostand 425 rue Jean Rostand
Labege 31670 Labege 31670
France France
Email: j.c.zuniga@ieee.org Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/ URI: http://www.sigfox.com/
 End of changes. 60 change blocks. 
193 lines changed or deleted 196 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/