rfc8885xml2.original.xml   rfc8885.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc8174 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc5213 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY rfc6275 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY rfc4877 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml">
<!ENTITY rfc3972 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY rfc7333 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7333.xml">
<!ENTITY rfc7429 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7429.xml">
<!ENTITY rfc4191 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY rfc4861 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY rfc8563 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8563.xml">
<!ENTITY I-D.bernardos-dmm-distributed-anchoring SYSTEM "http://xml.resource
.org/public/rfc/bibxml3/reference.I-D.bernardos-dmm-distributed-anchoring.xml">
<!ENTITY I-D.bernardos-dmm-pmip SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.bernardos-dmm-pmip.xml">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
<?rfc tocompact="yes"?> ="IETF" category="exp" consensus="true" docName="draft-ietf-dmm-pmipv6-dlif-06"
<?rfc tocdepth="4"?> number="8885" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth=
<?rfc tocindent="yes"?> "4" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-ietf-dmm-pmipv6-dlif-06">
<front>
<title abbrev="PMIPv6 DMM and DLIF">Proxy Mobile IPv6 extensions for Distrib
uted Mobility Management</title>
<!-- AUTHORS --> <front>
<title abbrev="PMIPv6 DMM and DLIF">Proxy Mobile IPv6 Extensions for Distrib
uted Mobility Management</title>
<seriesInfo name="RFC" value="8885"/>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos"> <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M">Universidad Carlos III de <organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization> Madrid</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes</city>
<region>Madrid</region>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </author>
<author fullname="Antonio de la Oliva" initials="A." surname="de la Oliva"> <author fullname="Antonio de la Oliva" initials="A." surname="de la Oliva">
<organization abbrev="UC3M">Universidad Carlos III de <organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization> Madrid</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes</city>
<region>Madrid</region>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 8803</phone> <phone>+34 91624 8803</phone>
<email>aoliva@it.uc3m.es</email> <email>aoliva@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/aoliva/</uri> <uri>http://www.it.uc3m.es/aoliva/</uri>
</address> </address>
</author> </author>
<author fullname="Fabio Giust" initials="F." surname="Giust"> <author fullname="Fabio Giust" initials="F." surname="Giust">
<organization abbrev="Athonet">Athonet S.r.l.</organization> <organization abbrev="Athonet">Athonet S.r.l.</organization>
<address> <address>
<email>fabio.giust.2011@ieee.org</email> <postal>
<street>via Ca' del Luogo 6/8</street>
<city>Bolzano Vicentino (VI)</city>
<code>36050</code>
<country>Italy</country>
</postal>
<email>fabio.giust.research@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
<author fullname="Juan Carlos Zuniga"
initials="JC."
surname="Zuniga">
<organization abbrev="SIGFOX"> <organization abbrev="SIGFOX">
SIGFOX SIGFOX
</organization> </organization>
<address> <address>
<postal> <postal>
<street>425 rue Jean Rostand</street> <street>425 rue Jean Rostand</street>
<city>Labege</city> <city>Labege</city>
<code> 31670</code> <code> 31670</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>j.c.zuniga@ieee.org</email> <email>j.c.zuniga@ieee.org</email>
<uri>http://www.sigfox.com/</uri> <uri>http://www.sigfox.com/</uri>
</address> </address>
</author> </author>
<author fullname="Alain Mourad" initials="A." surname="Mourad">
<author fullname="Alain Mourad"
initials="A."
surname="Mourad">
<organization abbrev="InterDigital"> <organization abbrev="InterDigital">
InterDigital Europe InterDigital Europe
</organization> </organization>
<address> <address>
<email>Alain.Mourad@InterDigital.com</email> <email>Alain.Mourad@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri> <uri>http://www.InterDigital.com/</uri>
</address> </address>
</author> </author>
<date month="October" year="2020"/>
<date month="March" year="2020" />
<area>Internet</area> <area>Internet</area>
<workgroup>DMM Working Group</workgroup> <workgroup>DMM Working Group</workgroup>
<abstract> <keyword>PMIPv6</keyword>
<keyword>anchor</keyword>
<keyword>session continuity</keyword>
<keyword>address reachability</keyword>
<keyword>HNP</keyword>
<keyword>CMD</keyword>
<keyword>MAAR</keyword>
<abstract>
<t> <t>
Distributed Mobility Management solutions allow for setting up networks so that Distributed Mobility Management solutions allow networks to be set up
traffic is distributed in an optimal way and does not rely on centrally in such a way that
deployed anchors to provide IP mobility support. traffic is distributed optimally and centrally
deployed anchors are not relied upon to provide IP mobility support.
</t> </t>
<t> <t>
There are many different approaches to address Distributed Mobility Management, There are many different approaches to address Distributed Mobility Management
as for example extending network-based mobility protocols (like Proxy Mobile -- for example, extending network-based mobility protocols (like Proxy Mobile
IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This IPv6) or client-based mobility protocols (like Mobile IPv6), among others. This
document follows the former approach and proposes a solution based on Proxy document follows the former approach and proposes a solution based on Proxy
Mobile IPv6 in which mobility sessions are anchored at the last IP hop router Mobile IPv6, in which mobility sessions are anchored at the last IP hop router
(called mobility anchor and access router). The mobility anchor and access (called the mobility anchor and access router). The mobility anchor and access
router is an enhanced access router which is also able to operate as a local router is an enhanced access router that is also able to operate as a local
mobility anchor or mobility access gateway, on a per prefix basis. The document mobility anchor or mobility access gateway on a per-prefix basis. The document
focuses on the required extensions to effectively support simultaneously focuses on the required extensions to effectively support the simultaneous
anchoring several flows at different distributed gateways. anchoring several flows at different distributed gateways.
</t> </t>
</abstract> </abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="sec:introduction" title="Introduction"> <section anchor="sec_introduction" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact
of currently standardized mobility management solutions which are centralized of currently standardized mobility management solutions, which are centralized
(at least to a considerable extent) <xref target="RFC7333"></xref>. (at least to a considerable extent) <xref target="RFC7333" format="default"/>.
</t> </t>
<t> <t>
Current IP mobility solutions, standardized with the names of Mobile IPv6 <xref The two most relevant examples of current IP mobility solutions are Mobile
target="RFC6275"></xref>, or Proxy Mobile IPv6 (PMIPv6) <xref IPv6 <xref target="RFC6275" format="default"/> and Proxy Mobile IPv6 (PMIPv6)
target="RFC5213"></xref>, just to cite the two most relevant examples, offer <xref target="RFC5213" format="default"/>. These solutions offer
mobility support at the cost of handling operations at a cardinal point, the mobility support at the cost of handling operations at a cardinal point (i.e.,
mobility anchor (i.e., the home agent for Mobile IPv6, and the local mobility the
anchor for Proxy Mobile IPv6), and burdening it with data forwarding and control mobility anchor) and burdening it with data forwarding and control
mechanisms for a great amount of users. As stated in <xref mechanisms for a large number of users. The mobility anchor is the home agent
target="RFC7333"></xref>, centralized mobility solutions are prone to several for Mobile IPv6 and the local mobility anchor for PMIPv6. As stated in <xref ta
rget="RFC7333" format="default"/>, centralized mobility solutions are prone to s
everal
problems and limitations: longer (sub-optimal) routing paths, scalability problems and limitations: longer (sub-optimal) routing paths, scalability
problems, signaling overhead (and most likely a longer associated handover problems, signaling overhead (and most likely a longer associated handover
latency), more complex network deployment, higher vulnerability due to the latency), more complex network deployment, higher vulnerability due to the
existence of a potential single point of failure, and lack of granularity of the existence of a potential single point of failure, and lack of granularity of the
mobility management service (i.e., mobility is offered on a per-node basis, not mobility management service (i.e., mobility is offered on a per-node basis
being possible to define finer granularity policies, as for example because it is not possible to define finer granularity policies, for example,
per-application). on a per-application basis).
</t> </t>
<t> <t>
The purpose of Distributed Mobility Management is to overcome the limitations of The purpose of DMM is to overcome the limitations of
the traditional centralized mobility management <xref target="RFC7333" /> <xref the traditional centralized mobility management <xref target="RFC7333" format="d
target="RFC7429" />; the main concept behind DMM solutions is indeed bringing efault"/> <xref target="RFC7429" format="default"/>; the main concept behind DMM
the mobility anchor closer to the Mobile Node (MN). Following this idea, the solutions is indeed bringing
central anchor is moved to the edge of the network, being deployed in the the mobility anchor closer to the mobile node (MN). Following this idea, the
default gateway of the mobile node. That is, the first elements that provide IP central anchor is moved to the edge of the network and is deployed in the
default gateway of the MN. That is, the first elements that provide IP
connectivity to a set of MNs are also the mobility managers for those MNs. In connectivity to a set of MNs are also the mobility managers for those MNs. In
this document, we call these entities Mobility Anchors and Access Routers this document, we call these entities Mobility Anchors and Access Routers
(MAARs). (MAARs).
</t> </t>
<t> <t>
This document focuses on network-based DMM, hence the starting point is making This document focuses on network-based DMM; hence, the starting point is making
PMIPv6 work in a distributed manner <xref target="RFC7429"></xref>. Mobility is PMIPv6 work in a distributed manner <xref target="RFC7429" format="default"/>. M
handled by the network without the MNs involvement, but, differently from obility is
PMIPv6, when the MN moves from one access network to another, it may also change handled by the network without the MN's involvement. But differently from
anchor router, hence requiring signaling between the anchors to retrieve the PMIPv6, when the MN moves from one access network to another, the router
MN's previous location(s). Also, a key-aspect of network-based DMM, is that a anchoring the MN's address may change, hence requiring signaling between the anc
prefix pool belongs exclusively to each MAAR, in the sense that those prefixes hors to retrieve the
are assigned by the MAAR to the MNs attached to it, and they are routable at MN's previous location(s). Also, a key aspect of network-based DMM is that a
that MAAR. Prefixes are assigned to MNs attached a MAAR at that time, but remain prefix pool belongs exclusively to each MAAR in the sense that those prefixes
are assigned by the MAAR to the MNs attached to it and are routable at
that MAAR. Prefixes are assigned to MNs attached to a MAAR at that time, but rem
ain
with those MNs as mobility occurs, remaining always routable at that MAAR as with those MNs as mobility occurs, remaining always routable at that MAAR as
well as towards the MN itself. well as towards the MN itself.
</t> </t>
<t> <t>
We consider partially distributed schemes, where only the data plane is We consider partially distributed schemes, where only the data plane is
distributed among access routers similar to MAGs, whereas the control plane is distributed among access routers similar to mobile access gateways (MAGs), where
kept centralized towards a cardinal node used as information store, but relieved as the control plane is
from any route management and MN's data forwarding task. kept centralized towards a cardinal node (used as an information store), which
is discharged from any route management and MN's data forwarding tasks.
</t> </t>
<section anchor="terms">
</section> <name>Requirements Language</name>
<t>
<section anchor="sec:terminology" title="Terminology"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="sec_terminology" numbered="true" toc="default">
<name>Terminology</name>
<t> <t>
The following terms used in this document are defined in the Proxy Mobile IPv6 The following terms used in this document are defined in the PMIPv6
specification <xref target="RFC5213" />: specification <xref target="RFC5213" format="default"/>:
<list style="empty">
<t>Local Mobility Anchor (LMA)</t>
<t>Mobile Access Gateway (MAG)</t>
<t>Mobile Node (MN)</t>
<t>Binding Cache Entry (BCE)</t>
<t>Proxy Care-of Address (P-CoA)</t>
<t>Proxy Binding Update (PBU)</t>
<t>Proxy Binding Acknowledgement (PBA)</t>
</list>
</t> </t>
<ul empty="true" spacing="normal"><li>
<dl>
<dt>BCE:</dt><dd>Binding Cache Entry</dd>
<dt>LMA:</dt><dd>Local Mobility Anchor</dd>
<dt>MAG:</dt><dd>Mobile Access Gateway</dd>
<dt>MN:</dt><dd>Mobile Node</dd>
<dt>P-CoA:</dt><dd>Proxy Care-of Address</dd>
<dt>PBA:</dt><dd>Proxy Binding Acknowledgement</dd>
<dt>PBU:</dt><dd>Proxy Binding Update</dd>
</dl>
</li>
</ul>
<t>
The following terms used in this document are defined in the Mobile IPv6
(MIPv6) specification <xref target="RFC6275" format="default"/>:
</t>
<ul empty="true" spacing="normal"><li>
<dl>
<dt>CN:</dt><dd>Correspondent Node</dd>
</dl></li></ul>
<t> <t>
The following terms are used in this document: The following terms are used in this document:
<list style="hanging"> </t>
<t hangText="Home Control-Plane Anchor (Home-CPA or H-CPA):"> <dl newline="true" spacing="normal">
The Home-CPA function hosts the mobile node (MN)'s mobility <dt>Home Control-Plane Anchor (Home-CPA or H-CPA):</dt>
session. There can be more than one mobility session for a mobile <dd>
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 The Home-CPA function hosts the MN's mobility
session. There can be more than one mobility session for an MN, and those sessi
ons may be anchored on the same or different
Home-CPAs. The Home-CPA will interface with the Home-DPA for
managing the forwarding state. managing the forwarding state.
<vspace blankLines="1"/> </dd>
</t> <dt>Home Data Plane Anchor (Home-DPA or H-DPA):</dt>
<t hangText="Home Data Plane Anchor (Home-DPA or H-DPA):"> <dd>
The Home-DPA is the topological anchor for the MN's IP address/ The Home-DPA is the topological anchor for the MN's IP addresses
prefix(es). The Home-DPA is chosen by the Home-CPA on a session- and/or prefixes.
basis. The Home-DPA is in the forwarding path for all the mobile The Home-DPA is chosen by the Home-CPA on a session basis. The Home-DPA is in t
node's IP traffic. he forwarding path for all the MN's IP traffic.
<vspace blankLines="1"/> </dd>
</t> <dt>Access Control Plane Node (Access-CPN or A-CPN):</dt>
<dd>
<t hangText="Access Control Plane Node (Access-CPN or A-CPN):"> The Access-CPN is responsible for interfacing with the MN's Home-CPA and the Acc
The Access-CPN is responsible for interfacing with the mobile ess-DPN. The Access-CPN has a
node's Home-CPA and with the Access-DPN. The Access-CPN has a
protocol interface to the Home-CPA. protocol interface to the Home-CPA.
<vspace blankLines="1"/>
</t>
<t hangText="Access Data Plane Node (Access-DPN or A-DPN):"> </dd>
<dt>Access Data Plane Node (Access-DPN or A-DPN):</dt>
<dd>
The Access-DPN function is hosted on the first-hop router where The Access-DPN function is hosted on the first-hop router where
the mobile node is attached. This function is not hosted on a the MN is attached. This function is not hosted on a
layer-2 bridging device such as a eNode(B) or Access Point. Layer 2 (L2) bridging device such as an eNode(B) or Access Point.
<vspace blankLines="1"/> </dd>
</t> </dl>
</list>
</t>
<t> <t>
The following terms are defined and used in this document: The following terms are defined and used in this document:
<list style="hanging"> </t>
<dl newline="true" spacing="normal">
<t hangText="MAAR (Mobility Anchor and Access Router)."> <dt>MAAR (Mobility Anchor and Access Router):</dt>
First hop router where the mobile nodes attach to. It also plays the role of <dd>
First-hop router where the MNs attach. It also plays the role of
mobility manager for the IPv6 prefixes it anchors, running the functionalities mobility manager for the IPv6 prefixes it anchors, running the functionalities
of PMIP's MAG and LMA. Depending on the prefix, it plays the role of Access-DPN, of PMIP's MAG and LMA. Depending on the prefix, it plays the role of Access-DPN,
Home-DPA and Access-CPN. Home-DPA, and Access-CPN.
</t> </dd>
<dt>CMD (Central Mobility Database):</dt>
<t hangText="CMD (Central Mobility Database)."> <dd>
The node that stores the BCEs allocated for the MNs in the mobility domain. It p lays The node that stores the BCEs allocated for the MNs in the mobility domain. It p lays
the role of Home-CPA. the role of Home-CPA.
</t> </dd>
<dt>P-MAAR (Previous MAAR):</dt>
<t hangText="P-MAAR (Previous MAAR)."> <dd>
When a MN moves to a new point of attachment a new MAAR might be allocated as When an MN moves to a new point of attachment, a new MAAR might be allocated as
its anchor point for future IPv6 prefixes. The MAAR that served the MN prior to its anchor point for future IPv6 prefixes. The MAAR that served the MN prior to
new attachment becomes the P-MAAR. It is still the anchor point for the IPv6 new attachment 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 Home-DPA for 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 P-MAARs serving a MN when the flows using these prefixes. There might be several P-MAARs serving an MN in
MN is frequently switching points of attachment while maintaining long-lasting cases when the MN is frequently switching points of attachment while
flows. maintaining long-lasting flows.
</t> </dd>
<dt>S-MAAR (Serving MAAR):</dt>
<t hangText="S-MAAR (Serving MAAR)."> <dd>
The MAAR which the MN is currently attached to. Depending on the prefix, it The MAAR to which the MN is currently attached. Depending on the prefix, it
plays the role of Access-DPN, Home-DPA and Access-CPN. plays the role of Access-DPN, Home-DPA, and Access-CPN.
</t> </dd>
<dt>Anchoring MAAR:</dt>
<t hangText="Anchoring MAAR."> <dd>
A MAAR anchoring an IPv6 prefix used by an MN. A MAAR anchoring an IPv6 prefix used by an MN.
</t> </dd>
<dt>DLIF (Distributed Logical Interface):</dt>
<t hangText="DLIF (Distributed Logical Interface)."> <dd>
It is a logical interface at the IP stack of the MAAR. For each active prefix It is a logical interface at the IP stack of the MAAR. For each active prefix
used by the MN, the S-MAAR has a DLIF configured (associated to each used by the MN, the S-MAAR has a DLIF configured (associated with each
MAAR still anchoring flows). In this way, an S-MAAR exposes itself towards each MAAR still anchoring flows). In this way, an S-MAAR exposes itself towards each
MN as multiple routers, one as itself and one per P-MAAR. MN as multiple routers, one as itself and one per P-MAAR.
</t> </dd>
</dl>
</list>
</t>
</section> </section>
<section anchor="sec:pmipv6_based" title="PMIPv6 DMM extensions"> <section anchor="sec_pmipv6_based" numbered="true" toc="default">
<name>PMIPv6 DMM Extensions</name>
<t> <t>
The solution consists of de-coupling the entities that participate in the data The solution consists of decoupling the entities that participate in the data
and the control planes: the data plane becomes distributed and managed by the and the control planes: the data plane becomes distributed and managed by the
MAARs near the edge of the network, while the control plane, besides those on MAARs near the edge of the network, while the control plane, besides those on
the MAARs, relies on a central entity called Central Mobility Database (CMD). In the MAARs, relies on a central entity called the Central Mobility Database (CMD) . In
the proposed architecture, the hierarchy present in PMIPv6 between LMA and MAG the proposed architecture, the hierarchy present in PMIPv6 between LMA and MAG
is preserved, but with the following substantial variations: is preserved but with the following substantial variations:
<list style="symbols">
<t> </t>
The LMA is relieved from the data forwarding role, only the Binding Cache and <ul spacing="normal">
its management operations are maintained. Hence the LMA is renamed into CMD, <li>
The LMA is discharged from the data forwarding role; only the Binding Cache and
its management operations are maintained. Hence, the LMA is renamed as "CMD",
which is therefore a Home-CPA. Also, the CMD is able to send and parse both PBU which is therefore a Home-CPA. Also, the CMD is able to send and parse both PBU
and PBA messages. and PBA messages.
</t> </li>
<li>
<t>
The MAG is enriched with the LMA functionalities, hence the name Mobility Anchor The MAG is enriched with the LMA functionalities, hence the name Mobility Anchor
and Access Router (MAAR). It maintains a local Binding Cache for the MNs that and Access Router (MAAR). It maintains a local Binding Cache for the MNs that
are attached to it and it is able to send and parse PBU and PBA messages. are attached to it, and it is able to send and parse PBU and PBA messages.
</t> </li>
<li>
<t> The Binding Cache will be extended to include information regarding P-MAARs
The binding cache will be extended to include information regarding P-MAARs where the MN was anchored and still retains active data sessions.
where the mobile node was anchored and still retains active data sessions. </li>
</t> <li>
Each MAAR has a unique set of global prefixes (which are configurable) that can
<t> be allocated by the MAAR to the MNs but must be exclusive to that MAAR, i.e., no
Each MAAR has a unique set of global prefixes (which are configurable), that can
be allocated by the MAAR to the MNs, but must be exclusive to that MAAR, i.e. no
other MAAR can allocate the same prefixes. other MAAR can allocate the same prefixes.
</t> </li>
</ul>
</list>
</t>
<t> <t>
The MAARs leverage the CMD to access and update information related to the MNs, The MAARs leverage the CMD to access and update information related to the MNs,
stored as mobility sessions; hence, a centralized node maintains a global view which is stored as mobility sessions; hence, a centralized node maintains a glob
of the network status. The CMD is queried whenever a MN is detected to al view
join/leave the mobility domain. It might be a fresh attachment, a detachment or of the network status. The CMD is queried whenever an MN is detected joining/lea
ving the mobility domain. It might be a fresh attachment, a detachment, or
a handover, but as MAARs are not aware of past information related to a mobility a handover, but as MAARs are not aware of past information related to a mobility
session, they contact the CMD to retrieve the data of interest and eventually session, they contact the CMD to retrieve the data of interest and eventually
take the appropriate action. The procedure adopted for the query and the take the appropriate action. The procedure adopted for the query and the
message exchange sequence might vary to optimize the update latency and/or the message exchange sequence might vary to optimize the update latency and/or the
signaling overhead. Here is presented one method for the initial registration, signaling overhead. Here, one method for the initial registration and three diff
and three different approaches for updating the mobility sessions using PBUs and erent approaches for updating the mobility sessions using PBUs and
PBAs. Each approach assigns a different role to the CMD: PBAs are presented. Each approach assigns a different role to the CMD:
<list style="symbols">
<t>The CMD is a PBU/PBA relay;</t>
<t>The CMD is only a MAAR locator;</t>
<t>The CMD is a PBU/PBA proxy.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>The CMD is a PBU/PBA relay;</li>
<li>The CMD is only a MAAR locator;</li>
<li>The CMD is a PBU/PBA proxy.</li>
</ul>
<t> <t>
The solution described in this document allows performing per-prefix anchoring The solution described in this document allows per-prefix anchoring
decisions, to support e.g., some flows to be anchored at a central Home-DPA decisions -- for example, to support the anchoring of some flows at a central Ho
me-DPA
(like a traditional LMA) or to enable an application to switch to the locally (like a traditional LMA) or to enable an application to switch to the locally
anchored prefix to gain route optimization, as indicated in <xref anchored prefix to gain route optimization, as indicated in <xref target="RFC856
target="RFC8563" />. This type of per-prefix treatment would potentially require 3" format="default"/>. This type of per-prefix treatment would potentially requi
re
additional extensions to the MAARs and signaling between the MAARs and the MNs additional extensions to the MAARs and signaling between the MAARs and the MNs
to convey the per-flow anchor preference (central, distributed), which are not to convey the per-flow anchor preference (central, distributed), which are not
covered in this document. covered in this document.
</t> </t>
<t> <t>
Note that a MN may move across different MAARs, which might result in several Note that an MN may move across different MAARs, which might result in several
P-MAARs existing at a given moment of time, each of them anchoring a different P-MAARs existing at a given moment of time, each of them anchoring a different
prefix used by the MN. prefix used by the MN.
</t> </t>
<section anchor="subsec_init" numbered="true" toc="default">
<section anchor="subsec:init" title="Initial registration"> <name>Initial Registration</name>
<t> <t>
Initial registration is performed when an MN attaches to a network for the first Initial registration is performed when an MN attaches to a network for the first
time (rather than attaching to a new network after moving from a previous one). time (rather than attaching to a new network after moving from a previous one).
</t> </t>
<t> <t>
In this description (shown in <xref target="fig:DMM1" />), it is assumed that: In this description (shown in <xref target="fig_DMM1" format="default"/>), it is
assumed that:
<list style="numbers">
<t> </t>
<ol spacing="normal" type="1">
<li>
The MN is attaching to MAAR1. The MN is attaching to MAAR1.
</t> </li>
<li>
<t>
The MN is authorized to attach to the network. The MN is authorized to attach to the network.
</t> </li>
</ol>
</list>
</t>
<t> <t>
Upon MN attachment, the following operations take place: Upon MN attachment, the following operations take place:
<list style="numbers"> </t>
<ol spacing="normal" type="1">
<t> <li>
MAAR1 assigns a global IPv6 prefix from its own prefix pool to the MN (Pref1). MAAR1 assigns a global IPv6 prefix from its own prefix pool to the MN (Pref1).
It also stores this prefix (Pref1) in the locally allocated temporary Binding It also stores this prefix (Pref1) in the locally allocated temporary BCE.
Cache Entry (BCE). </li>
</t> <li>
MAAR1 sends a PBU <xref target="RFC5213" format="default"/> with Pref1 and the M
<t> N's MN-ID to the
MAAR1 sends a PBU <xref target="RFC5213" /> with Pref1 and the MN's MN-ID to the
CMD. CMD.
</t> </li>
<li>
<t> Since this is an initial registration, the CMD stores a BCE containing the
Since this is an initial registration, the CMD stores a BCE containing as MN-ID, Pref1, and MAAR1's address (as a Proxy-CoA) as the primary fields.
primary fields the MN-ID, Pref1 and MAAR1's address as a Proxy-CoA. </li>
</t> <li>
The CMD replies with a PBA with the usual options defined in PMIPv6 <xref target
<t> ="RFC5213" format="default"/>, meaning that the MN's registration is fresh and n
The CMD replies with a PBA with the usual options defined in PMIPv6 <xref o past
target="RFC5213" />, meaning that the MN's registration is fresh and no past
status is available. status is available.
</t> </li>
<li>
<t>
MAAR1 stores the BCE described in (1) and unicasts a Router Advertisement (RA) t o MAAR1 stores the BCE described in (1) and unicasts a Router Advertisement (RA) t o
the MN with Pref1. the MN with Pref1.
</t> </li>
<li>
<t>
The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with stateless The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with stateless
auto-configuration, SLAAC). address autoconfiguration (SLAAC)).
</t> </li>
</ol>
</list>
</t>
<t> <t>
Note that: Note that:
<list style="numbers"> </t>
<ol spacing="normal" type="1">
<t> <li>
Alternative IPv6 auto-configuration mechanisms can also be used, though this Alternative IPv6 autoconfiguration mechanisms can also be used, though this
document describes the SLAAC-based one. document describes the SLAAC-based one.
</t> </li>
<li>
<t> IP1 is routable at MAAR1 in the sense that it is on the path of packets
IP1 is routable at MAAR1, in the sense that it is on the path of packets
addressed to the MN. addressed to the MN.
</t> </li>
<li>
<t> MAAR1 acts as a plain router for packets destined to the MN as no encapsulation
MAAR1 acts as a plain router for packets destined to the MN, as no encapsulation or special handling takes place.
nor special handling takes place. </li>
</t> </ol>
</list>
</t>
<t> <t>
In the diagram shown in <xref target="fig:DMM1" /> (and subsequent diagrams), In the diagram shown in <xref target="fig_DMM1" format="default"/> (and subseque nt diagrams),
the flow of packets is presented using '*'. the flow of packets is presented using '*'.
</t> </t>
<figure anchor="fig:DMM1" title="First attachment to the network"> <figure anchor="fig_DMM1">
<artwork><![CDATA[ <name>First Attachment to the Network</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----+ +---+ +--+ +-----+ +---+ +--+
|MAAR1| |CMD| |CN| |MAAR1| |CMD| |CN|
+-----+ +---+ +*-+ +-----+ +---+ +*-+
| | * | | *
MN | * +---+ MN | * +---+
attach. | ***** _|CMD|_ attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \ detection | flow1 * / +-+-+ \
| | * / | \ | | * / | \
local BCE | * / | \ local BCE | * / | \
allocation | * / | \ allocation | * / | \
skipping to change at line 527 skipping to change at line 442
| BCE | * | | | | | | BCE | * | | | | |
| creation |MAAR1+------+MAAR2+-----+MAAR3| | creation |MAAR1+------+MAAR2+-----+MAAR3|
|<-- PBA ---| | * | | | | | |<-- PBA ---| | * | | | | |
local BCE | +---*-+ +-----+ +-----+ local BCE | +---*-+ +-----+ +-----+
finalized | * finalized | *
| | Pref1 * | | Pref1 *
| | +*-+ | | +*-+
| | |MN| | | |MN|
| | +--+ | | +--+
Operations sequence Packets flow Operations sequence Packet flow
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Note that the registration process does not change regardless of the CMD's modes Note that the registration process does not change regardless of the CMD's modes
(relay, locator or proxy) described next. The procedure is depicted in <xref (relay, locator, or proxy) described in the following sections. The procedure is
target="fig:DMM1" />. depicted in <xref target="fig_DMM1" format="default"/>.
</t> </t>
</section> </section>
<section anchor="subsec_relay" numbered="true" toc="default">
<section anchor="subsec:relay" title="The CMD as PBU/PBA relay"> <name>The CMD as PBU/PBA Relay</name>
<t> <t>
Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following operations Upon MN mobility, if the CMD behaves as a PBU/PBA relay, the following operation
take place: s take place:
<list style="numbers">
<t> </t>
<ol spacing="normal" type="1">
<li>
When the MN moves from its current point of attachment and attaches to MAAR2 When the MN moves from its current point of attachment and attaches to MAAR2
(now the S-MAAR), MAAR2 reserves an IPv6 prefix (Pref2), it stores a temporary (now the S-MAAR), MAAR2 reserves an IPv6 prefix (Pref2), stores a temporary
BCE, and it sends a PBU to the CMD for registration. BCE, and sends a PBU to the CMD for registration.
</t> </li>
<li>
<t>
Upon PBU reception and BC lookup, the CMD retrieves an already existing entry Upon PBU reception and BC lookup, the CMD retrieves an already existing entry
for the MN, binding the MN-ID to its former location; thus, the CMD forwards the for the MN and binds the MN-ID to its former location; thus, the CMD forwards th
PBU to the MAAR indicated as Proxy CoA (MAAR1), including a new mobility option e
to communicate the S-MAAR's global address to MAAR1, defined as Serving MAAR PBU to the MAAR indicated as Proxy-CoA (MAAR1) and includes a new mobility optio
Option in <xref target="subsec:smaaropt" />. The CMD updates the P-CoA field in n
to communicate the S-MAAR's global address to MAAR1 (defined as the Serving MAAR
option in <xref target="subsec_smaaropt" format="default"/>). The CMD updates th
e P-CoA field in
the BCE related to the MN with the S-MAAR's address. the BCE related to the MN with the S-MAAR's address.
</t> </li>
<li>
<t>
Upon PBU reception, MAAR1 can install a tunnel on its side towards MAAR2 and the Upon PBU reception, MAAR1 can install a tunnel on its side towards MAAR2 and the
related routes for Pref1. Then MAAR1 replies to the CMD with a PBA (including related routes for Pref1. Then MAAR1 replies to the CMD with a PBA (including
the option mentioned before) to ensure that the new location has successfully the option mentioned before) to ensure that the new location has successfully
changed, containing the prefix anchored at MAAR1 in the Home Network Prefix changed. The PBA contains the prefix anchored at MAAR1 in the Home Network Prefi x
option. option.
</t> </li>
<li>
<t> The CMD, after receiving the PBA, updates the BCE and populates an instance
The CMD, after receiving the PBA, updates the BCE populating an instance
of the P-MAAR list. The P-MAAR list is an additional field on the BCE that of the P-MAAR list. The P-MAAR list is an additional field on the BCE that
contains an element for each P-MAAR involved in the MN's mobility session. The contains an element for each P-MAAR involved in the MN's mobility session. The
list element contains the P-MAAR's global address and the prefix it has list element contains the P-MAAR's global address and the prefix it has
delegated. Also, the delegated. Also, the
CMD sends a PBA to the new S-MAAR, containing the previous Proxy-CoA and the CMD sends a PBA to the new S-MAAR, which contains the previous Proxy-CoA and the
prefix anchored to it embedded into a new mobility option called Previous MAAR prefix anchored to it embedded into a new mobility option called the Previous MA
Option (defined in <xref target="subsec:pmaaropt"></xref>), so that, upon PBA AR
arrival, a bi-directional tunnel can be established between the two MAARs and option (defined in <xref target="subsec_pmaaropt" format="default"/>). Then, upo
n PBA
arrival, a bidirectional tunnel can be established between the two MAARs, and
new routes are set appropriately to recover the IP flow(s) carrying Pref1. new routes are set appropriately to recover the IP flow(s) carrying Pref1.
</t> </li>
<li>
<t> Now, packets destined for Pref1 are first received by MAAR1, encapsulated into t
Now packets destined to Pref1 are first received by MAAR1, encapsulated into the he
tunnel and forwarded to MAAR2, which finally delivers them to their destination. tunnel, and forwarded to MAAR2, which finally delivers them to their destination
In uplink, when the MN transmits packets using Pref1 as source address, they are .
sent to MAAR2, as it is MN's new default gateway, then tunneled to MAAR1 which In the uplink, when the MN transmits packets using Pref1 as a source address, th
routes them towards the next hop to destination. Conversely, packets carrying ey are
Pref2 are routed by MAAR2 without any special packet handling both for uplink sent to MAAR2 (as it is the MN's new default gateway) and then tunneled to MAAR1
, which
routes them towards the next hop to the destination. Conversely, packets carryin
g
Pref2 are routed by MAAR2 without any special packet handling both for the uplin
k
and downlink. and downlink.
</t> </li>
</ol>
</list> <figure anchor="fig_DMM2">
<name>Scenario after a Handover, CMD as Relay</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="fig:DMM2"
title="Scenario after a handover, CMD as relay">
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
skipping to change at line 620 skipping to change at line 523
|<-- PBU*---| | | * | | *| | | |<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3| route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | | update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+ |--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * * | BCE | * *
| update | Pref1 * *Pref2 | update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+ | |--- PBA*-->| +*--*+
| | route ---move-->|*MN*| | | route ---move-->|*MN*|
| | update +----+ | | update +----+
Operations sequence Data Packets flow Operations sequence Data Packet flow
PBU/PBA Messages with * contain PBU/PBA messages with * contain
a new mobility option a new mobility option
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
For MN's next movements the process is repeated except the number of P-MAARs For MN's next movements, the process is repeated, but the number of P-MAARs
involved increases (accordingly to the number of prefixes that the MN wishes to involved increases (according to the number of prefixes that the MN wishes to
maintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, it maintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, it
forwards copies of the PBU to all the P-MAARs indicated in the BCE, namely the forwards copies of the PBU to all the P-MAARs indicated in the BCE, namely the
one registered as current P-CoA (i.e., the MAAR prior to handover) plus the ones P-MAAR registered as the current P-CoA (i.e., the MAAR prior to handover) plus t
in the P-MAARs list. They reply with a PBA to the CMD, which aggregates them he ones
into a single one to notify the S-MAAR, that finally can establish the tunnels in the P-MAAR list. Those P-MAARs reply with a PBA to the CMD, which
aggregates all of the PBAs into one PBA to notify the S-MAAR, which finally can
establish the tunnels
with the P-MAARs. with the P-MAARs.
</t> </t>
<t> <t>
It should be noted that this design separates the mobility management at the It should be noted that this design separates the mobility management at the
prefix granularity, and it can be tuned in order to erase old mobility sessions prefix granularity, and it can be tuned in order to erase old mobility sessions
when not required, while the MN is reachable through the latest prefix acquired. when not required, while the MN is reachable through the latest prefix acquired.
Moreover, the latency associated to the mobility update is bound to the PBA sent Moreover, the latency associated with the mobility update is bound to the PBA se nt
by the furthest P-MAAR, in terms of RTT, that takes the longest time to reach by the furthest P-MAAR, in terms of RTT, that takes the longest time to reach
the CMD. The drawback can be mitigated introducing a timeout at the CMD, by the CMD. The drawback can be mitigated by introducing a timeout at the CMD, by
which, after its expiration, all the PBAs so far collected are transmitted, and which, after its expiration, all the PBAs so far collected are transmitted, and
the remaining are sent later upon their arrival. Note that in this case the the remaining are sent later upon their arrival. Note that, in this case, the
S-MAAR might receive multiple PBAs from the CMD in response to a PBU. The CMD S-MAAR might receive multiple PBAs from the CMD in response to a PBU. The CMD
SHOULD follow the retransmissions and rate limiting considerations described in <bcp14>SHOULD</bcp14> follow the retransmissions and rate-limiting consideration
<xref target="sec:retransmissions" />, especially when aggregating and relaying s described in
<xref target="sec_retransmissions" format="default"/>, especially when aggregati
ng and relaying
PBAs. PBAs.
</t> </t>
<t> <t>
When there are multiple previous MAARs, e.g., k MAARs, a single PBU received by When there are multiple P-MAARs, e.g., k MAARs, a single PBU received by
the CMD triggers k outgoing packets from a single incoming packet. This may lead the CMD triggers k outgoing packets from a single incoming packet. This may lead
to packet bursts originated from the CMD, albeit to different targets. Pacing to packet bursts originating from the CMD, albeit to different targets. Pacing
mechanisms MUST be introduced to avoid bursts on the outgoing link. mechanisms <bcp14>MUST</bcp14> be introduced to avoid bursts on the outgoing lin
k.
</t> </t>
</section> </section>
<section anchor="subsec_locator" numbered="true" toc="default">
<section anchor="subsec:locator" title="The CMD as MAAR locator"> <name>The CMD as MAAR Locator</name>
<t> <t>
The handover latency experienced in the approach shown before can be reduced if The handover latency experienced in the approach shown before can be reduced if
the P-MAARs are allowed to signal directly their information to the new S-MAAR. the P-MAARs are allowed to directly signal their information to the new S-MAAR.
This procedure reflects what was described in <xref target="subsec:relay" /> up This procedure reflects what was described in <xref target="subsec_relay" format
to the moment the P-MAAR receives the PBU with the S-MAAR option. At that point ="default"/> up
to the moment the P-MAAR receives the PBU with the Serving MAAR option. At that
point,
a P-MAAR is aware of the new MN's location (because of the S-MAAR's address in a P-MAAR is aware of the new MN's location (because of the S-MAAR's address in
the S-MAAR option), and, besides sending a PBA to the CMD, it also sends a PBA the Serving MAAR option), and, besides sending a PBA to the CMD, it also sends a
to the S-MAAR including the prefix it is anchoring. This latter PBA does not PBA
need to include new options, as the prefix is embedded in the HNP option and the to the S-MAAR, including the prefix it is anchoring. This latter PBA does not
P-MAAR's address is taken from the message's source address. The CMD is relieved need to include new options, as the prefix is embedded in the Home
from forwarding the PBA to the S-MAAR, as the latter receives a copy directly Network Prefix (HNP) option and the
P-MAAR's address is taken from the message's source address. The CMD is
released from forwarding the PBA to the S-MAAR as the latter receives a copy dir
ectly
from the P-MAAR with the necessary information to build the tunnels and set the from the P-MAAR with the necessary information to build the tunnels and set the
appropriate routes. <xref target="fig:DMM3" /> illustrates the new message appropriate routes. <xref target="fig_DMM3" format="default"/> illustrates the n
sequence, while the data forwarding is unaltered. ew message
sequence. The data forwarding is unaltered.
</t> </t>
<figure anchor="fig_DMM3">
<figure anchor="fig:DMM3" <name>Scenario after a Handover, CMD as Locator</name>
title="Scenario after a handover, CMD as locator"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
skipping to change at line 703 skipping to change at line 603
|<-- PBU*---| | | * | | *| | | |<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3| route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | | update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+ |--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * * |--- PBA*-->| route * *
| BCE update Pref1 * *Pref2 | BCE update Pref1 * *Pref2
| update | +*--*+ | update | +*--*+
| | | ---move-->|*MN*| | | | ---move-->|*MN*|
| | | +----+ | | | +----+
Operations sequence Data Packets flow Operations sequence Data Packet flow
PBU/PBA Messages with * contain PBU/PBA messages with * contain
a new mobility option a new mobility option
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="subsec_proxy" numbered="true" toc="default">
<section anchor="subsec:proxy" title="The CMD as MAAR proxy"> <name>The CMD as PBU/PBA Proxy</name>
<t> <t>
A further enhancement of previous solutions can be achieved when the CMD sends A further enhancement of previous solutions can be achieved when the CMD sends
the PBA to the new S-MAAR before notifying the P-MAARs of the location change. the PBA to the new S-MAAR before notifying the P-MAARs of the location change.
Indeed, when the CMD receives the PBU for the new registration, it is already in Indeed, when the CMD receives the PBU for the new registration, it is already in
possession of all the information that the new S-MAAR requires to set up the possession of all the information that the new S-MAAR requires to set up the
tunnels and the routes. Thus the PBA is sent to the S-MAAR immediately after a tunnels and the routes. Thus, the PBA is sent to the S-MAAR immediately after a
PBU is received, including also in this case the P-MAAR option. In parallel, a PBU is received, including the Previous MAAR option in this case. In parallel, a
PBU is sent by the CMD to the P-MAARs containing the S-MAAR option, to notify PBU is sent by the CMD to the P-MAARs containing the Serving MAAR option to noti
them about the new MN's location, so they receive the information to establish fy
them about the new MN's location so that they receive the information to establi
sh
the tunnels and routes on their side. When P-MAARs complete the update, they the tunnels and routes on their side. When P-MAARs complete the update, they
send a PBA to the CMD to indicate that the operation is concluded and the send a PBA to the CMD to indicate that the operation has concluded and the
information is updated in all network nodes. This procedure is obtained from information is updated in all network nodes. This procedure is obtained from
the first one re-arranging the order of the messages, but the parameters the first procedure rearranging the order of the messages, but the parameters
communicated are the same. This scheme is depicted in <xref communicated are the same. This scheme is depicted in <xref target="fig_DMM4" fo
target="fig:DMM4"></xref>, where, again, the data forwarding is kept untouched. rmat="default"/>, where, again, the data forwarding is kept untouched.
</t> </t>
<figure anchor="fig_DMM4">
<figure anchor="fig:DMM4" <name>Scenario after a Handover, CMD as Proxy</name>
title="Scenario after a handover, CMD as proxy"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
| check+ | * / | * \ | check+ | * / | * \
skipping to change at line 753 skipping to change at line 650
|<-- PBU*---x--- PBA*-->| | * | | *| | | |<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3| route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | | update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+ |--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * * | BCE | * *
| update | Pref1 * *Pref2 | update | Pref1 * *Pref2
| | | +*--*+ | | | +*--*+
| | | ---move-->|*MN*| | | | ---move-->|*MN*|
| | | +----+ | | | +----+
Operations sequence Data Packets flow Operations sequence Data Packet flow
PBU/PBA Messages with * contain PBU/PBA messages with * contain
a new mobility option a new mobility option
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="subsec_dereg" numbered="true" toc="default">
<section anchor="subsec:dereg" title="De-registration"> <name>De-registration</name>
<t> <t>
The de-registration mechanism devised for PMIPv6 cannot be used as-is in this 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 independent mobility solution because each MAAR handles an independent mobility
session (i.e., a single or a set of prefixes) for a given MN, whereas the session (i.e., a single prefix or a set of prefixes) for a given MN, whereas the
aggregated session is stored at the CMD. Indeed, if a previous MAAR initiates aggregated session is stored at the CMD. Indeed, if a P-MAAR initiates
a de-registration procedure, because the MN is no longer present on the MAAR's a de-registration procedure because the MN is no longer present on the MAAR's
access link, it removes the routing state for that (those) prefix(es), that access link, it removes the routing state for the prefix(es), that
would be deleted by the CMD as well, hence defeating any prefix continuity would be deleted by the CMD as well, hence defeating any prefix continuity
attempt. The simplest approach to overcome this limitation is to deny a P-MAAR attempt. The simplest approach to overcome this limitation is to deny a P-MAAR
to de-register a prefix, that is, allowing only a serving MAAR to de-register to de-register a prefix, that is, allowing only an S-MAAR to de-register
the whole MN session. This can be achieved by first removing any layer-2 the whole MN session. This can be achieved by first removing any L2
detachment event, so that de-registration is triggered only when the binding detachment event so that de-registration is triggered only when the binding
lifetime expires, hence providing a guard interval for the MN to connect to a lifetime expires, hence providing a guard interval for the MN to connect to a
new MAAR. Then, a change in the MAAR operations is required, and at this stage new MAAR. 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:
<list style="symbols"> </t>
<ul spacing="normal">
<t> <li>
A previous MAAR stops the BCE timer upon receiving a PBU from the CMD containing A P-MAAR stops the BCE timer upon receiving a PBU from the CMD containing
a "Serving MAAR" option. In this way only the Serving MAAR is allowed to a "Serving MAAR" option. In this way, only the S-MAAR is allowed to
de-register the mobility session, arguing that the MN definitely left the de-register the mobility session, arguing that the MN definitely left the
domain. domain.
</t> </li>
<li>
<t> P-MAARs can, upon BCE expiry, send de-registration messages to the CMD,
Previous MAARs can, upon BCE expiry, send de-registration messages to the CMD,
which, instead of acknowledging the message with a 0 lifetime, sends back a PBA which, instead of acknowledging the message with a 0 lifetime, sends back a PBA
with a non-zero lifetime, hence re-newing the session, if the MN is still with a non-zero lifetime, hence renewing the session if the MN is still
connected to the domain. connected to the domain.
</t> </li>
</ul>
</list>
</t>
</section> </section>
<section anchor="sec_retransmissions" numbered="true" toc="default">
<section anchor="sec:retransmissions" title="Retransmissions and Rate Limi <name>Retransmissions and Rate Limiting</name>
ting">
<t> <t>
When sending PBUs, the node sending them (the CMD or S-MAAR) SHOULD make use of The node sending PBUs (the CMD or S-MAAR) <bcp14>SHOULD</bcp14> make use of
the timeout also to deal with missing PBAs (to retransmit PBUs). The the timeout to also deal with missing PBAs (to retransmit PBUs). The
INITIAL_BINDACK_TIMEOUT <xref target="RFC6275" /> SHOULD be used for configuring INITIAL_BINDACK_TIMEOUT <xref target="RFC6275" format="default"/> <bcp14>SHOULD<
the retransmission timer. The retransmissions by the node MUST use an /bcp14> be used for configuring
the retransmission timer. The retransmissions by the node <bcp14>MUST</bcp14> us
e an
exponential backoff process in which the timeout period is doubled upon each exponential backoff process in which the timeout period is doubled upon each
retransmission, until either the node receives a response or the timeout period retransmission until either the node receives a response or the timeout period
reaches the value MAX_BINDACK_TIMEOUT <xref target="RFC6275" />. The node MAY reaches the value MAX_BINDACK_TIMEOUT <xref target="RFC6275" format="default"/>.
continue to send these messages at this slower rate indefinitely. The node MUST The node <bcp14>MAY</bcp14>
NOT send PBU messages to a particular node more than MAX_UPDATE_RATE times continue to send these messages at this slower rate indefinitely. The node <bcp1
within a second <xref target="RFC6275" />. 4>MUST
NOT</bcp14> send PBU messages to a particular node more than MAX_UPDATE_RATE tim
es
within a second <xref target="RFC6275" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_dlif_concept" numbered="true" toc="default">
<section anchor="sec:dlif_concept" title="The Distributed Logical <name>The Distributed Logical Interface (DLIF) Concept</name>
Interface (DLIF) concept">
<t> <t>
One of the main challenges of a network-based DMM solution is how to allow a One of the main challenges of a network-based DMM solution is how to allow a
mobile node to simultaneously send/receive traffic which is anchored at MN to simultaneously send/receive traffic that is anchored at
different MAARs, and how to influence the mobile node's selection process of its different MAARs and how to influence the MN's selection process of its
source IPv6 address for a new flow, without requiring special support from the source IPv6 address for a new flow without requiring special support from the
mobile node's IP stack. This document defines the Distributed Logical Interface MN's IP stack. This document defines the DLIF, which is a software construct in
(DLIF), which is a software construct in the MAAR that allows to easily hide the the MAAR that can easily hide
change of associated anchors from the mobile node. the change of associated anchors from the MN.
</t> </t>
<figure anchor="fig_exposing_multiple_routers">
<figure anchor="fig:exposing_multiple_routers" <name>DLIF: Exposing Multiple Routers (One per P-MAAR)</name>
title="DLIF: exposing multiple routers (one per P-MAAR)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+---------------------------------------------------+ +---------------------------------------------------+
( 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 line 856 skipping to change at line 742
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) +-----+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The basic idea of the DLIF concept is the following: each serving MAAR exposes The basic idea of the DLIF concept is the following: each S-MAAR exposes
itself towards a given MN as multiple routers, one per P-MAAR itself to a given MN as multiple routers, one per P-MAAR
associated to the MN. Let's consider the example shown in <xref associated with the MN. Let's consider the example shown in <xref target="fig_ex
target="fig:exposing_multiple_routers" />, MN1 initially attaches to MAAR1, posing_multiple_routers" format="default"/>: MN1 initially attaches to MAAR1,
configuring an IPv6 address (prefA::MN1) from a prefix locally anchored at MAAR1 configuring an IPv6 address (prefA::MN1) from a prefix locally anchored at MAAR1
(prefA::/64). At this stage, MAAR1 plays both the role of anchoring and serving (prefA::/64). At this stage, MAAR1 plays the role of both anchoring and serving
MAAR, and also behaves as a plain IPv6 access router. MAAR1 creates a distribute MAAR and also behaves as a plain IPv6 access router. MAAR1 creates a DLIF to com
d municate (through a point-to-point link) with MN1, exposing itself
logical interface to communicate (point-to-point link) with MN1, exposing itself as a (logical) router with specific MAC and IPv6
as a (logical) router with a specific MAC and IPv6
addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the DLIF addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the DLIF
mn1mar1. As explained below, these addresses represent the "logical" identity of mn1mar1. As explained below, these addresses represent the "logical" identity of
MAAR1 towards MN1, and will "follow" the mobile node while roaming within the MAAR1 for MN1 and will "follow" the MN while roaming within the
domain (note that the place where all this information is maintained and updated domain (note that the place where all this information is maintained and updated
is out-of-scope of this draft; potential examples are to keep it on the home is out of scope of this document; potential examples are to keep it on the home
subscriber server -- HSS -- or the user's profile). subscriber server -- HSS -- or the user's profile).
</t> </t>
<t> <t>
If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in the If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in the
example of <xref target="fig:exposing_multiple_routers" />), this MAAR will example of <xref target="fig_exposing_multiple_routers" format="default"/>), thi
create a new logical interface (mn1mar2) to expose itself towards MN1, providing s MAAR will
create a new logical interface (mn1mar2) to expose itself to MN1, providing
it with a locally anchored prefix (prefB::/64). In this case, since the MN1 has it with a locally anchored prefix (prefB::/64). In this case, since the MN1 has
another active IPv6 address anchored at a MAAR1, MAAR2 also needs to create an another active IPv6 address anchored at MAAR1, MAAR2 also needs to create an
additional logical interface configured to resemble the one used by MAAR1 to additional logical interface configured to resemble the one used by MAAR1 to
communicate with MN1. In this example, there is only one P-MAAR (in addition to communicate with MN1. In this example, MAAR1 is the only P-MAAR (MAAR2 is the
MAAR2, which is the serving one): MAAR1, so only the logical interface mn1mar1 same as S-MAAR), so only the logical interface mn1mar1
is created, but the same process would be repeated in case there were more is created. However, the same process would be repeated if more
P-MAARs involved. In order to maintain the prefix anchored at MAAR1 reachable, a P-MAARs were involved. In order to keep the prefix anchored at MAAR1 reachable,
a
tunnel between MAAR1 and MAAR2 is established and the routing is modified tunnel between MAAR1 and MAAR2 is established and the routing is modified
accordingly. The PBU/PBA signaling is used to set-up the bi-directional tunnel accordingly. The PBU/PBA signaling is used to set up the bidirectional tunnel
between MAAR1 and MAAR2, and it might also be used to convey to MAAR2 the between MAAR1 and MAAR2, and it might also be used to convey the
information about the prefix(es) anchored at MAAR1 and about the addresses of information about the prefix(es) anchored at MAAR1 and the addresses of
the associated DLIF (i.e., mn1mar1). the associated DLIF (i.e., mn1mar1) to MAAR2.
</t> </t>
<figure anchor="fig_dlif_concept">
<figure anchor="fig:dlif_concept" <name>Distributed Logical Interface Concept</name>
title="Distributed Logical Interface concept"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+------------------------------------------+ +----------------------+ +------------------------------------------+ +----------------------+
| 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 line 918 skipping to change at line 799
|+----------------------------------------+| |+--------------------+| |+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+ +------------------------------------------+ +----------------------+
x x x x x x
x x x x x x
(o) (o) (o) (o) (o) (o)
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 | | MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="fig:dlif_concept" /> shows the logical interface concept in more <xref target="fig_dlif_concept" format="default"/> shows the logical interface c oncept in more
detail. The figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 detail. The figure shows two MAARs and three MNs. MAAR1 is currently serving MN2
and MN3, while MAAR2 is serving MN1. Note that a serving MAAR always plays the and MN3, while MAAR2 is serving MN1. Note that an S-MAAR always plays the
role of anchoring MAAR for the attached (served) MNs. Each MAAR has one single role of anchoring MAAR for the attached (served) MNs. Each MAAR has one single
physical wireless interface as depicted in this example. physical wireless interface as depicted in this example.
</t> </t>
<t> <t>
As introduced before, each MN always "sees" multiple logical routers -- one per As discussed before, each MN always "sees" multiple logical routers -- one per
anchoring MAAR -- independently of its currently serving MAAR. From the point of anchoring MAAR -- independently of its currently S-MAAR. From the point of
view of the MN, these MAARs are portrayed as different routers, although the MN view of the MN, these MAARs are portrayed as different routers, although the MN
is physically attached to one single interface. The way this is achieved is by is physically attached to a single interface. This is achieved by
the serving MAAR configuring different logical interfaces. Focusing on MN1, it the S-MAAR configuring different logical interfaces. MN1 is currently attached t
is currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and, therefore, o MAAR2 (i.e., MAAR2 is its S-MAAR) and, therefore,
it has configured an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 it has configured an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2
has set-up a logical interface (mn1mar2) on top of its wireless physical has set up a logical interface (mn1mar2) on top of its wireless physical
interface (phy if MAAR2) which is used to serve MN1. This interface has a interface (phy if MAAR2), which is used to serve MN1. This interface has a
logical MAC address (LMAC6), different from the hardware MAC address (MAC2) of logical MAC address (LMAC6) that is different from the hardware MAC address (MAC
2) of
the physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises the physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises
its locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 was its locally anchored prefix prefB::/64.
attached to MAAR1, configuring also an address locally anchored at that MAAR,
Before attaching to MAAR2, MN1 was
attached to MAAR1 and configured a locally anchored address at that MAAR,
which is still being used by MN1 in active communications. MN1 keeps "seeing" an which is still being used by MN1 in active communications. MN1 keeps "seeing" an
interface connecting to MAAR1, as if it were directly connected to the two interface connecting to MAAR1 as if it were directly connected to the two
MAARs. This is achieved by the serving MAAR (MAAR2) configuring an additional MAARs. This is achieved by the S-MAAR (MAAR2) configuring an additional
distributed logical interface: mn1mar1, which behaves as the logical interface DLIF, mn1mar1, which behaves as the logical interface
configured by MAAR1 when MN1 was attached to it. This means that both the MAC configured by MAAR1 when MN1 was attached to it. This means that both the MAC
and IPv6 addresses configured on this logical interface remain the same and IPv6 addresses configured on this logical interface remain the same
regardless of the physical MAAR which is serving the MN. The information regardless of the physical MAAR that is serving the MN. The information
required by a serving MAAR to properly configure this logical interfaces can be required by an S-MAAR to properly configure this logical interfaces can be
obtained in different ways: as part of the information conveyed in the PBA, from obtained in different ways: as part of the information conveyed in the PBA, from
an external database (e.g., the HSS) or by other means. As shown in the figure, an external database (e.g., the HSS) or by other means. As shown in the figure,
each MAAR may have several logical interfaces associated to each attached MN, each MAAR may have several logical interfaces associated with each attached MN
having always at least one (since a serving MAAR is also an anchoring MAAR for and always has at least one (since an S-MAAR is also an anchoring MAAR for
the attached MN). the attached MN).
</t> </t>
<t> <t>
In order to enforce the use of the prefix locally anchored at the serving MAAR, In order to enforce the use of the prefix locally anchored at the S-MAAR,
the router advertisements sent over those logical interfaces playing the role of the RAs sent over those logical interfaces playing the role of
anchoring MAARs (different from the serving one) include a zero preferred prefix anchoring MAARs (different from the serving one) include a zero preferred prefix
lifetime (and a non-zero valid prefix lifetime, so the prefix remains valid, lifetime (and a non-zero valid prefix lifetime, so the prefix remains valid
while being deprecated). The goal is to deprecate the prefixes delegated by while being deprecated). The goal is to deprecate the prefixes delegated by
these MAARs (so that they will no longer be serving the MN). Note that on-going these MAARs (so that they will no longer be serving the MN). Note that ongoing
communications may keep on using those addresses, even if they are deprecated, communications may keep on using those addresses even if they are deprecated,
so this only affects the establishment of new sessions. so this only affects the establishment of new sessions.
</t> </t>
<t> <t>
The distributed logical interface concept also enables the following use case: The DLIF concept also enables the following use case:
suppose that access to a local IP network is provided by a given MAAR (e.g., suppose that access to a local IP network is provided by a given MAAR (e.g.,
MAAR1 in the example shown in <xref target="fig:exposing_multiple_routers" />) MAAR1 in the example shown in <xref target="fig_exposing_multiple_routers" forma t="default"/>)
and that the resources available at that network cannot be reached from outside and that the resources available at that network cannot be reached from outside
the local network (e.g., cannot be accessed by an MN attached to MAAR2). This is the local network (e.g., cannot be accessed by an MN attached to MAAR2). This is
similar to the local IP access scenario considered by 3GPP, where a local similar to the local IP access scenario considered by 3GPP, where a local
gateway node is selected for sessions requiring access to services provided gateway node is selected for sessions requiring access to services provided
locally (instead of going through a central gateway). The goal is to allow an MN locally (instead of going through a central gateway). The goal is to allow an MN
to be able to roam while still being able to have connectivity to this local IP to be able to roam while still being able to have connectivity to this local IP
network. The solution adopted to support this case makes use of RFC 4191 <xref network. The solution adopted to support this case makes use of more specific
target="RFC4191" /> more specific routes when the MN moves to a MAAR different routes, as discussed in RFC 4191 <xref target="RFC4191" format="default"/>, when
from the one providing access to the local IP network (MAAR1 in the example). the MN moves to a MAAR different
These routes are advertised through the distributed logical interface from the one providing access to the local IP network (MAAR1 in the
representing the MAAR providing access to the local network (MAAR1 in this example).
These routes are advertised through the DLIF where
the MAAR is providing access to the local network (MAAR1 in this
example). In this way, if MN1 moves from MAAR1 to MAAR2, any active session that example). In this way, if MN1 moves from MAAR1 to MAAR2, any active session that
MN1 may have with a node on the local network connected to MAAR1 will survive MN1 may have with a node on the local network connected to MAAR1 will survive
via the tunnel between MAAR1 and MAAR2. Also, any potential future connection 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 attempt to the local network will be supported even though MN1 is no
longer attached to MAAR1. longer attached to MAAR1, so long as a source address configured from MAAR1 is
selected for new connections (see <xref target="RFC6724"/>, rule 5.5).
</t> </t>
</section> </section>
</section> </section>
<!-- end of section "PMIPv6-based" --> <section anchor="subsec_messages" numbered="true" toc="default">
<name>Message Format</name>
<section anchor="subsec:messages" title="Message Format"> <t>
This section defines extensions to the PMIPv6 <xref target="RFC5213" format="def
ault"/> protocol messages.
</t>
<section anchor="sec_pbu_format" numbered="true" toc="default">
<name>Proxy Binding Update</name>
<t> <t>
This section defines extensions to the Proxy Mobile IPv6 <xref target="RFC5213" A new flag (D) is included in the PBU to indicate that the
/> protocol messages. PBU is coming from a MAAR or a CMD and not from a MAG. The rest of the PBU forma
t remains the same as defined
in <xref target="RFC5213" format="default"/>.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<section anchor="sec:pbu_format" title="Proxy Binding Update">
<t>
A new flag (D) is included in the Proxy Binding Update to indicate that the
Proxy Binding Update is coming from a MAAR or a CMD and not from a mobile access
gateway. The rest of the Proxy Binding Update format remains the same as defined
in <xref target="RFC5213" />.
</t>
<figure>
<artwork><![CDATA[
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| Rsrvd | Lifetime | |A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>
<t> DMM Flag (D)</dt>
DMM Flag (D) <dd>
The D flag is set to indicate to the receiver of the message that the PBU is fro
<list> m a MAAR or a CMD. When an LMA that does not support the
extensions described in this document receives a message with the D flag set,
<t> the PBU in that case <bcp14>MUST NOT</bcp14> be processed by the LMA, and an err
The D Flag is set to indicate to the receiver of the message that the Proxy or <bcp14>MUST</bcp14> be
Binding Update is from a MAAR or a CMD. 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. returned.
</t> </dd>
<dt>Mobility Options</dt>
</list> <dd>
</t>
<t>
Mobility Options
<list>
<t>
Variable-length field of such length that the complete Mobility Header is an Variable-length field of such length that the complete Mobility Header is an
integer multiple of 8 octets long. This field contains zero or more TLV-encoded integer that is a multiple of 8 octets long. This field contains zero or more TL
mobility options. The encoding and format of defined options are described in V-encoded
Section 6.2 of <xref target="RFC6275" />. The receiving node MUST ignore and mobility options. The encoding and format of the defined options are described i
n <xref target="RFC6275" sectionFormat="of" section="6.2"/>. The receiving node
<bcp14>MUST</bcp14> ignore and
skip any options that it does not understand. skip any options that it does not understand.
</t> </dd>
</dl>
</list> </section>
<section anchor="sec_pba_format" numbered="true" toc="default">
</t> <name>Proxy Binding Acknowledgement</name>
<t>
</section> A new flag (D) is included in the PBA to indicate that
the sender supports operating as a MAAR or CMD. The rest of the PBA format remai
<section anchor="sec:pba_format" title="Proxy Binding Acknowledgment"> ns the same as defined in <xref target="RFC5213" format="default"/>.
</t>
<t> <artwork name="" type="" align="left" alt=""><![CDATA[
A new flag (D) is included in the Proxy Binding Acknowledgment to indicate that
the sender supports operating as a MAAR or CMD. The rest of the Proxy Binding
Acknowledgment format remains the same as defined in <xref target="RFC5213" />.
</t>
<figure>
<artwork><![CDATA[
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 .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>
<t> DMM Flag (D)</dt>
DMM Flag (D) <dd>
<list>
<t>
The D flag is set to indicate that the sender of the message supports operating The D flag is set to indicate that the sender of the message supports operating
as a MAAR or a CMD. When a MAG that does not support the extensions described in as a MAAR or CMD. When a MAG that does not support the extensions described in
this document receives a message with the D-Flag set, it MUST ignore the message this document receives a message with the D flag set, it <bcp14>MUST</bcp14> ign
and an error MUST be returned. ore the message,
</t> and an error <bcp14>MUST</bcp14> be returned.
</dd>
</list> <dt>Mobility Options</dt>
<dd>
</t>
<t>
Mobility Options
<list>
<t>
Variable-length field of such length that the complete Mobility Header is an Variable-length field of such length that the complete Mobility Header is an
integer multiple of 8 octets long. This field contains zero or more TLV-encoded integer multiple of 8 octets long. This field contains zero or more TLV-encoded
mobility options. The encoding and format of defined options are described in mobility options. The encoding and format of the defined options are described i
Section 6.2 of <xref target="RFC6275" />. The MAAR MUST ignore and skip any n <xref target="RFC6275" sectionFormat="of" section="6.2"/>. The MAAR <bcp14>MUS
T</bcp14> ignore and skip any
options that it does not understand. options that it does not understand.
</t> </dd>
</dl>
</list> </section>
<section anchor="sec_anchored_prefix_format" numbered="true" toc="default"
</t> >
<name>Anchored Prefix Option</name>
</section> <t>
A new Anchored Prefix option is defined for use with the PBU and PBA messages ex
<section anchor="sec:anchored_prefix_format" changed between MAARs and CMDs.
title="Anchored Prefix Option">
<t>
A new Anchored Prefix option is defined for use with the Proxy Binding Update
and Proxy Binding Acknowledgment messages exchanged between MAARs and CMDs.
Therefore, this option can only appear if the D bit is set in a PBU/PBA. This Therefore, this option can only appear if the D bit is set in a PBU/PBA. This
option is used for exchanging the mobile node's prefix anchored at the anchoring option is used for exchanging the MN's prefix anchored at the anchoring
MAAR. There can be multiple Anchored Prefix options present in the message. MAAR. There can be multiple Anchored Prefix options present in the message.
</t> </t>
<t>
<t> The Anchored Prefix option has an alignment requirement of 8n+4. Its format is
The Anchored Prefix Option has an alignment requirement of 8n+4. Its format is
as follows: as follows:
</t>
<figure> </t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal"><dt>
Type</dt>
<t> <dd>65</dd>
Type
<list>
<t>
IANA-1.
</t>
</list>
</t>
<t>
Length
<list>
<t> <dt>Length</dt>
<dd>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. This field MUST be set to 18. the type and length fields. This field <bcp14>MUST</bcp14> be set to 18.
</t> </dd>
<dt>
</list> Reserved</dt>
<dd>
</t> This field is unused at the time of publication. The value <bcp14>MUST</bcp14> b
e initialized to 0 by the sender
<t> and <bcp14>MUST</bcp14> be ignored by the receiver.
Reserved </dd>
<dt>
<list>
<t>
This field is unused for now. The value MUST be initialized to 0 by the sender
and MUST be ignored by the receiver.
</t>
</list>
</t>
<t>
Prefix Length Prefix Length
</dt>
<list> <dd>
<t>
8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix
contained in the option. contained in the option.
</t> </dd>
<dt>
</list>
</t>
<t>
Anchored Prefix Anchored Prefix
</dt>
<list> <dd>
A 16-octet field containing the MN's IPv6 Anchored Prefix. Only the
<t> first Prefix Length bits are valid for the Anchored Prefix option. The rest of t
A sixteen-octet field containing the mobile node's IPv6 Anchored Prefix. Only th he
e bits <bcp14>MUST</bcp14> be ignored.
first Prefix Length bits are valid for the Anchored Prefix. The rest of the </dd>
bits MUST be ignored. </dl>
</t> </section>
<section anchor="sec_local_prefix_format" numbered="true" toc="default">
</list> <name>Local Prefix Option</name>
<t>
</t> A new Local Prefix option is defined for use with the PBU and PBA messages excha
nged between MAARs or between a MAAR
</section>
<section anchor="sec:local_prefix_format" title="Local Prefix Option">
<t>
A new Local Prefix option is defined for use with the Proxy Binding Update and
Proxy Binding Acknowledgment messages exchanged between MAARs or between a MAAR
and a CMD. Therefore, this option can only appear if the D bit is set in a and a CMD. 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 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 multiple Local Prefix only reachable via the anchoring MAAR. There can be multiple Local Prefix
options present in the message. options present in the message.
</t> </t>
<t>
<t> The Local Prefix option has an alignment requirement of 8n+4. Its format is
The Local Prefix Option has an alignment requirement of 8n+4. Its format is
as follows: as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>
<t>
Type Type
</dt>
<list> <dd>
66
<t> </dd>
IANA-2. <dt>
</t>
</list>
</t>
<t>
Length Length
</dt>
<list> <dd>
<t>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. This field MUST be set to 18. the type and length fields. This field <bcp14>MUST</bcp14> be set to 18.
</t> </dd>
<dt>
</list>
</t>
<t>
Reserved Reserved
</dt>
<list> <dd>
This field is unused at the time of publication. The value <bcp14>MUST</bcp14> b
<t> e initialized to 0 by the sender
This field is unused for now. The value MUST be initialized to 0 by the sender and <bcp14>MUST</bcp14> be ignored by the receiver.
and MUST be ignored by the receiver. </dd>
</t> <dt>
</list>
</t>
<t>
Prefix Length Prefix Length
</dt>
<list> <dd>
<t>
8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix
contained in the option. contained in the option.
</t> </dd>
<dt>
</list>
</t>
<t>
Local Prefix Local Prefix
</dt>
<list> <dd>
A 16-octet field containing the IPv6 Local Prefix. Only the first Prefix
<t> Length bits are valid for the IPv6 Local Prefix. The rest of the bits <bcp14>MUS
A sixteen-octet field containing the IPv6 Local Prefix. Only the first Prefix T</bcp14> be
Length bits are valid for the IPv6 Local Prefix. The rest of the bits MUST be
ignored. ignored.
</t> </dd>
</dl>
</list> </section>
<section anchor="subsec_pmaaropt" numbered="true" toc="default">
</t> <name>Previous MAAR Option</name>
<t>
</section> This new option is defined for use with the PBA messages exchanged by the CMD to
a MAAR. This option is used to notify the
<section anchor="subsec:pmaaropt" title="Previous MAAR Option"> S-MAAR about the P-MAAR's global address and the prefix anchored to it.
There can be multiple Previous MAAR options present in the message.
<t> </t>
This new option is defined for use with the Proxy Binding Acknowledgement <t>
messages exchanged by the CMD to a MAAR. This option is used to notify the The Previous MAAR option has an alignment requirement of 8n+4. Its format is
S-MAAR about the previous MAAR's global address and the prefix anchored to it.
There can be multiple Previous MAAR options present in the message. Its format
is as follows:
</t>
<t>
The Previous MAAR Option has an alignment requirement of 8n+4. Its format is
as follows: as follows:
</t>
<figure> </t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ P-MAAR's address + + Previous MAAR +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Network Prefix + + Home Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>Type
<t>Type </dt>
<dd>
<list> 67
<t> </dd>
IANA-3. <dt>
</t>
</list>
</t>
<t>
Length Length
<list> </dt>
<t> <dd>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. This field MUST be set to 34. the type and length fields. This field <bcp14>MUST</bcp14> be set to 34.
</t> </dd>
</list> <dt>
</t>
<t>
Reserved Reserved
</dt>
<list> <dd>
This field is unused at the time of publication. The value <bcp14>MUST</bcp14> b
<t> e initialized to 0 by the sender
This field is unused for now. The value MUST be initialized to 0 by the sender and <bcp14>MUST</bcp14> be ignored by the receiver.
and MUST be ignored by the receiver. </dd>
</t> <dt>
</list>
</t>
<t>
Prefix Length Prefix Length
<list> </dt>
<t> <dd>
8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix 8-bit unsigned integer indicating the prefix length in bits of the IPv6 prefix
contained in the option. contained in the option.
</t> </dd>
</list> <dt>
</t> Previous MAAR
</dt>
<t> <dd>
Previous MAAR's address A 16-octet field containing the P-MAAR's IPv6 global address.
<list> </dd>
<t> <dt>
A sixteen-octet field containing the P-MAAR's IPv6 global address.
</t>
</list>
</t>
<t>
Home Network Prefix Home Network Prefix
<list> </dt>
<t> <dd>
A sixteen-octet field containing the mobile node's IPv6 Home Network Prefix. Onl A 16-octet field containing the MN's IPv6 Home Network Prefix. Only
y the first Prefix Length bits are valid for the MN's IPv6 Home Network
the first Prefix Length bits are valid for the mobile node's IPv6 Home Network Prefix. The rest of the bits <bcp14>MUST</bcp14> be ignored.
Prefix. The rest of the bits MUST be ignored. </dd>
</t> </dl>
</list> </section>
</t> <section anchor="subsec_smaaropt" numbered="true" toc="default">
</section> <name>Serving MAAR Option</name>
<t>
<section anchor="subsec:smaaropt" title="Serving MAAR Option"> This new option is defined for use with the PBU message
exchanged between the CMD and a P-MAAR. This option is used to notify the
<t> P-MAAR about the current S-MAAR's global address. Its format is as
This new option is defined for use with the Proxy Binding Update message
exchanged between the CMD and a Previous MAAR. This option is used to notify the
P-MAAR about the current Serving MAAR's global address. Its format is as
follows: follows:
</t> </t>
<t>
<t> The Serving MAAR option has an alignment requirement of 8n+6. Its format is as
The Serving MAAR Option has an alignment requirement of 8n+6. Its format is as
follows: follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>Type
<t>Type
<list>
<t>
IANA-4.
</t>
</list>
</t>
<t> </dt>
<dd>
68
</dd>
<dt>
Length Length
<list> </dt>
<t> <dd>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. This field MUST be set to 16. the type and length fields. This field <bcp14>MUST</bcp14> be set to 16.
</t> </dd>
</list> <dt>
</t> Serving MAAR
</dt>
<t> <dd>
Serving MAAR's address A 16-octet field containing the S-MAAR's IPv6 global address.
<list> </dd>
<t> </dl>
A sixteen-octet field containing the S-MAAR's IPv6 global address. </section>
</t> <section anchor="sec_dlif_link_local_format" numbered="true" toc="default"
</list> >
</t> <name>DLIF Link-Local Address Option</name>
<t>
</section> A new DLIF Link-Local Address option is defined for use with the PBA message exc
hanged between MAARs and between a MAAR and a CMD.
<section anchor="sec:dlif_link_local_format"
title="DLIF Link-local Address Option">
<t>
A new DLIF Link-local Address option is defined for use with the Proxy Binding
Acknowledgment message exchanged between MAARs and between a MAAR and a CMD.
This option is used for exchanging the link-local address of the DLIF to be This option is used for exchanging the link-local address of the DLIF to be
configured on the serving MAAR so it resembles the DLIF configured on the configured on the S-MAAR so it resembles the DLIF configured on the
P-MAAR. P-MAAR.
</t> </t>
<t>
<t> The DLIF Link-Local Address option has an alignment requirement of 8n+6. Its
The DLIF Link-local Address option has an alignment requirement of 8n+6. Its
format is as follows: format is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>
<t>
Type Type
</dt>
<list> <dd>
69
<t> </dd>
IANA-5. <dt>
</t>
</list>
</t>
<t>
Length Length
<list> </dt>
<dd>
<t>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. This field MUST be set to 16. the type and length fields. This field <bcp14>MUST</bcp14> be set to 16.
</t> </dd>
<dt>
</list> DLIF Link-Local Address
</t>
<t>
DLIF Link-local Address
<list>
<t>
A sixteen-octet field containing the link-local address of the logical interface
.
</t>
</list>
</t>
</section>
<section anchor="sec:dlif_link_layer_format"
title="DLIF Link-layer Address Option">
<t> </dt>
A new DLIF Link-layer Address option is defined for use with the Proxy Binding <dd>
Acknowledgment message exchanged between MAARs and betwwe a MAAR and a CMD. This A 16-octet field containing the link-local address of the logical interface.
</dd>
</dl>
</section>
<section anchor="sec_dlif_link_layer_format" numbered="true" toc="default"
>
<name>DLIF Link-Layer Address Option</name>
<t>
A new DLIF Link-Layer Address option is defined for use with the PBA message exc
hanged between MAARs and between a MAAR and a CMD. This
option is used for exchanging the link-layer address of the DLIF to be option is used for exchanging the link-layer address of the DLIF to be
configured on the serving MAAR so it resembles the DLIF configured on the configured on the S-MAAR so it resembles the DLIF configured on the
P-MAAR. P-MAAR.
</t> </t>
<t>
<t> The format of the DLIF Link-Layer Address option is shown below. Based on the
The format of the DLIF Link-layer Address option is shown below. Based on the size of the address, the option <bcp14>MUST</bcp14> be aligned appropriately,
size of the address, the option MUST be aligned appropriately, as per mobility as per the mobility
option alignment requirements specified in <xref target="RFC6275" />. option alignment requirements specified in <xref target="RFC6275" format="defaul
</t> t"/>.
</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
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 +
. ... . . ... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>
<t>
Type Type
</dt>
<list> <dd>
70
<t> </dd>
IANA-6. <dt>
</t>
</list>
</t>
<t>
Length Length
<list> </dt>
<dd>
<t>
8-bit unsigned integer indicating the length of the option in octets, excluding 8-bit unsigned integer indicating the length of the option in octets, excluding
the type and length fields. the type and length fields.
</t> </dd>
<dt>
</list>
</t>
<t>
Reserved Reserved
<list> </dt>
<dd>
<t> This field is unused at the time of publication. The value <bcp14>MUST</bcp14> b
This field is unused for now. The value MUST be initialized to 0 by the sender e initialized to 0 by the sender
and MUST be ignored by the receiver. and <bcp14>MUST</bcp14> be ignored by the receiver.
</t> </dd>
<dt>
</list> DLIF Link-Layer Address
</dt>
</t> <dd><t>
<t>
DLIF Link-layer Address
<list>
<t>
A variable length field containing the link-layer address of the logical A variable length field containing the link-layer address of the logical
interface to be configured on the S-MAAR. interface to be configured on the S-MAAR.
</t> </t><t>
<t>
The content and format of this field (including octet and bit ordering) is as The content and format of this field (including octet and bit ordering) is as
specified in Section 4.6 of <xref target="RFC4861" /> for carrying link-layer specified in <xref target="RFC4861" sectionFormat="of" section="4.6"/> for carry
addresses. On certain access links, where the link-layer address is not used or ing link-layer
addresses. On certain access links where the link-layer address is not used or
cannot be determined, this option cannot be used. cannot be determined, this option cannot be used.
</t> </t></dd>
</dl>
</list> </section>
</t>
</section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<!-- end of section "Message format" --> <name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations">
<t> <t>
This document defines six new mobility options, the Anchored Prefix Option, the This document defines six new mobility options: Anchored Prefix, Local Prefix,
Local Prefix Option, the Previous MAAR Option, the Serving MAAR Option, the DLIF Previous MAAR, Serving MAAR, DLIF
Link-local Address Option and the DLIF Link-layer Address Option. The Type value Link-Local Address, and DLIF Link-Layer Address. IANA has assigned Type values
for these options needs to be assigned from the same numbering space as for these options from the same numbering space as
allocated for the other mobility options in the "Mobility Options" registry allocated for the other mobility options in the "Mobility Options" registry
defined in http://www.iana.org/assignments/mobility-parameters. The required defined in <eref target="http://www.iana.org/assignments/mobility-parameters"/>.
IANA actions are marked as IANA-1 to IANA-6.
</t> </t>
<t> <t>
This document reserves a new flag (D) in the "Binding Update Flags" and a new This document reserves a new flag (D) with a value of 0x0010 in the "Binding Upd
flag (D) in the "Binding Acknowledgment Flags" of the "Mobile IPv6 parameters" ate Flags"
registry http://www.iana.org/assignments/mobility-parameters. registry and a new
flag (D) with a value of 0x02 in the "Binding Acknowledgment Flags" of the "Mobi
le IPv6 parameters"
registry (<eref target="http://www.iana.org/assignments/mobility-parameters"/>).
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
The protocol extensions defined in this document share the same security The protocol extensions defined in this document share the same security
concerns of Proxy Mobile IPv6 <xref target="RFC5213" />. It is recommended that concerns of PMIPv6 <xref target="RFC5213" format="default"/>. It is recommended
the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgment, that
exchanged between the MAARs are protected using IPsec using the established the signaling messages, PBU and PBA,
exchanged between the MAARs be protected using IPsec, specifically by using the
established
security association between them. This essentially eliminates the threats security association between them. This essentially eliminates the threats
related to the impersonation of a MAAR. related to the impersonation of a MAAR.
</t> </t>
<t> <t>
When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a single PBU 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 handovers (e.g., with to multiple P-MAARs. In situations with many fast handovers (e.g., with
vehicular networks), there may exist multiple previous (e.g., k) MAARs. In this vehicular networks), multiple previous (e.g., k) MAARs may exist. In this
situation, the CMD creates k outgoing packets from a single incoming packet. situation, the CMD creates k outgoing packets from a single incoming packet.
This bears a certain amplification risk. The CMD MUST use a pacing approach in This bears a certain amplification risk. The CMD <bcp14>MUST</bcp14> use a pacin g approach in
the outgoing queue to cap the output traffic (i.e., the rate of PBUs sent) to the outgoing queue to cap the output traffic (i.e., the rate of PBUs sent) to
limit this amplification risk. limit this amplification risk.
</t> </t>
<t> <t>
When the CMD acts as MAAR locator, mobility signaling (PBAs) is exchanged When the CMD acts as a MAAR locator, mobility signaling (PBAs) is exchanged
between P-MAARs and current S-MAAR. Hence, security associations are REQUIRED to between P-MAARs and the current S-MAAR. Hence, security associations are <bcp14>
REQUIRED</bcp14> to
exist between the involved MAARs (in addition to the ones needed with the CMD). exist between the involved MAARs (in addition to the ones needed with the CMD).
</t> </t>
<t> <t>
Since deregistration is performed by timeout, measures SHOULD be implemented to Since de-registration is performed by timeout, measures <bcp14>SHOULD</bcp14> be
minimize the risks associated to continued resource consumption (DoS attacks), implemented to
e.g., imposing a limit of the number of P-MAARs associated to a given MN. minimize the risks associated with continued resource consumption (DoS attacks),
e.g., imposing a limit on the number of P-MAARs associated with a given MN.
</t> </t>
<t> <t>
The CMD and the participating MAARs MUST be trusted parties, authorized perform The CMD and the participating MAARs <bcp14>MUST</bcp14> be trusted parties autho rized perform
all operations relevant to their role. all operations relevant to their role.
</t> </t>
<t> <t>
There are some privacy considerations to consider. While the involved parties There are some privacy considerations to consider. While the involved parties
trust each other, the signalling involves disclosing information about the trust each other, the signaling involves disclosing information about the
previous locations visited by each MN, as well as the active prefixes they are 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 using at a given point of time. Therefore, mechanisms <bcp14>MUST</bcp14> be in
that MAARs and CMD do not disclose this information to other parties nor use it place to ensure
for other ends that providing the distributed mobility support specified in this that MAARs and CMDs do not disclose this information to other parties or use it
for other ends than providing the distributed mobility support specified in this
document. document.
</t> </t>
</section> </section>
</middle>
<back>
<section anchor="Acknowledgments" title="Acknowledgments"> <displayreference target="I-D.bernardos-dmm-distributed-anchoring" to="DISTRIBUT
ED-ANCHORING"/>
<displayreference target="I-D.bernardos-dmm-pmip" to="DMM-PMIP"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6275.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5213.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4191.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7333.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7429.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8563.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6724.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.bernardos-dmm-distributed-anchoring.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.bernardos-dmm-pmip.xml"/>
</references>
</references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> <t>
The authors would like to thank Dirk von Hugo, John Kaippallimalil, Ines Robles, The authors would like to thank <contact fullname="Dirk von Hugo"/>, <contact fu
Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja K&uuml;hlewind, &Eacute;ric llname="John Kaippallimalil"/>, <contact fullname="Ines Robles"/>,
Vyncke, Adam Roach, Benjamin Kaduk and Roman Danyliw for the comments on this <contact fullname="Joerg Ott"/>, <contact fullname="Carlos Pignataro"/>, <contac
document. The authors would also like to thank Marco Liebsch, Dirk von Hugo, t fullname="Vincent Roca"/>, <contact fullname="Mirja Kühlewind"/>, <contact ful
Alex Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru lname="Éric
Matsushima for their comments and discussion on the documents <xref Vyncke"/>, <contact fullname="Adam Roach"/>, <contact fullname="Benjamin Kaduk"/
target="I-D.bernardos-dmm-distributed-anchoring" /> and <xref >, and <contact fullname="Roman Danyliw"/> for the comments on this
target="I-D.bernardos-dmm-pmip" /> on which the present document is based. document. The authors would also like to thank <contact fullname="Marco Liebsch"
/>, <contact fullname="Dirk von Hugo"/>,
<contact fullname="Alex Petrescu"/>, <contact fullname="Daniel Corujo"/>, <conta
ct fullname="Akbar Rahman"/>, <contact fullname="Danny Moses"/>, <contact fullna
me="Xinpeng Wei"/>, and <contact fullname="Satoru
Matsushima"/> for their comments and discussion on the documents <xref target="I
-D.bernardos-dmm-distributed-anchoring" format="default"/> and <xref target="I-D
.bernardos-dmm-pmip" format="default"/>, on which the present document is based.
</t> </t>
<t> <t>
The authors would also like to thank Lyle Bertz and Danny Moses for their The authors would also like to thank <contact fullname="Lyle Bertz"/> and <conta
in-deep review of this document and their very valuable comments and ct fullname="Danny Moses"/> for their
in-depth review of this document and their very valuable comments and
suggestions. suggestions.
</t> </t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc8174;
&rfc6275;
&rfc5213;
&rfc4191;
&rfc4861;
&rfc7333;
</references>
<references title="Informative References">
&rfc7429;
&rfc8563;
&I-D.bernardos-dmm-distributed-anchoring;
&I-D.bernardos-dmm-pmip;
</references>
<!---->
</back> </back>
</rfc> </rfc>
 End of changes. 269 change blocks. 
1155 lines changed or deleted 901 lines changed or added

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