One document matched: draft-chan-dmm-framework-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-chan-dmm-framework-03">
<front>
<title abbrev="DMM Framework">Distributed Mobility Management Framework</title>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3</street>
<city>Plano, TX 75024</city>
<country>USA</country>
</postal>
<email>h.a.chan@ieee.org</email>
</address>
</author>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne 35512</city>
<country>France</country>
</postal>
<email>pierrick.seite@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis">
<organization>EICT GmbH</organization>
<address>
<postal>
<street></street>
<city></city>
<country></country>
</postal>
<email>k.pentikousis@eict.de</email>
</address>
</author>
<author initials="A" surname="Dutta" fullname="Ashutosh Dutta">
<organization>ATT</organization>
<address>
<postal>
<street>200 Laurel Ave S</street>
<city>Middletown, NJ 07748</city>
<country>USA</country>
</postal>
<email>ashutosh.dutta@ieee.org</email>
</address>
</author>
<date year="2013"></date>
<area></area>
<workgroup>DMM</workgroup>
<abstract>
<t>This document introduces a framework for mobility management protocols in terms of their key, abstract logical functions. We explain how the framework is capable of presenting a unified view, reducing the clutter that prevents a casual reader from understanding the commonalities between different approaches in mobility management. A first order application of this framework is to enable us to examine previously standardized mobility management protocols, such as MIPv6 and PMIPv6 (as well as several of their extensions), and describe their core functionality in terms of different configurations of the logical functions defined by the framework.</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>While there is ongoing research on new protocols for distributed mobility management (DMM), it has also been proposed, e.g., in <xref target="Paper-Distributed.Mobility.PMIP"/> and in other publications, that a DMM architecture can be designed using primarily existing mobility management protocols with some extensions. This is reflected in the requirement included in <xref target="I-D.ietf-dmm-requirements"/>: distributed mobility management is to first use existing protocols and their extensions before considering new protocol designs. Although this a key requirement as we move forward, it does not point to which extensions are needed let alone how to devise them.</t>
<t>Mobile IPv6 <xref target="RFC6275"/>, for instance, which is a logically centralized mobility management approach addressing primarily hierarchical mobile networks, has numerous variants and extensions including, PMIPv6 <xref target="RFC5213"/>, Hierarchical MIPv6 (HMIPv6) <xref target="RFC5380"/>, Fast MIPv6 (FMIPv6) <xref target="RFC5568"/> <xref target="RFC4988"/>, Proxy-based FMIPv6 (PFMIPv6) <xref target="RFC5949"/>, just to name a few. These variants or extensions of MIPv6 have been developed over the years owing to the different needs that have been arising ever since the first MIP specification came into life. This document argues that we can gain much more insight into the design space of DMM protocols by abstracting the functionality of existing mobility management protocols in terms of logical functions. Different variants of existing mobility management protocols can then be expressed as different design variations of how these logical functions are put together. The result is a rich framework that can express sophisticated functionalities in a more straightforward manner. What is more, this document shows how to reconfigure these logical functions towards various distributed mobility management designs.</t>
<t>The rest of this document is organized as follows. After setting the stage with conventions and terminology in the following section, <xref target="sec-mmlf"/> introduces the framework abstractions, based on common functionality we observe in the current crop of mobility management protocols. This includes three logical functions, namely, home address allocation, routing management and location management. Such functional decomposition will enable us to clearly separate data and control plane functionality, and gives us the flexibility in an implementation to position said logical functions at their most appropriate places in the system design. Next, <xref target="sec-func-mp"/> shows that these logical functions can indeed perform the same functions as major existing mobility protocols. These functions therefore become the foundation for a unified framework upon which different designs of distributed mobility management may be built upon. Finally, <xref target="sec-scenarios"/> presents scenarios where the functional aspects of the framework are illustrated.</t>
</section>
<!-- Conventions and definitions -->
<section title="Conventions and Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />. </t>
<t>All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275] and in the Proxy Mobile IPv6 specification [RFC5213]. This includes terms such as mobile node (MN), correspondent node (CN), home agent (HA), home address (HoA), care-of-address (CoA), local mobility anchor (LMA), and mobile access gateway (MAG). </t>
<t>In addition, this document uses the following term: </t>
<t>
<list style='hanging'>
<t hangText='Home network of an application session (or of an HoA)'> is the network that has allocated the IP address (HoA)
used for the session identifier by the application running in an MN.
An MN may be running multiple application sessions,
and each of these sessions can have a different home network.</t>
</list>
</t>
</section>
<!-- Mobility Management Logical Functions -->
<section anchor="sec-mmlf" title="Mobility Management Logical Functions">
<t>Functional entity (FE) decomposition is an often-used engineering approach that enables us to look at the similarities and differences of complex systems while keeping track of their important operational aspects. Earlier work, for instance, in the European research project Ambient Networks investigated how to create an advanced and forward-looking architecture aiming primarily for mobile and wireless networks <xref target="Book-AN"/>. A key goal was to design mechanisms that can be deployed in a variety of settings (ad-hoc or operator-controlled) and scale from small home networks with little human supervision to sensor networks deployed over large geographical areas with limited resources, to large professionally-managed infrastructure networks. The project put forward the concept of the Ambient Control Space (ACS) which relies on only three interfaces; interested readers can find more details in <xref target="Book-AN"/>.</t>
<t>Within the ACS, novel mobility management mechanisms were developed based on the concept of self-containing Functional Entities (FEs) which featured well-defined interfaces and interactions with each other. This systematic decomposition enabled the development of several mobility management mechanisms which put emphasis on different aspects. Examples of these approaches include the Generic Link Layer <xref target="Paper-GLL"/>, Multi-radio Resource Management <xref target="Paper-MRRM"/>, and <xref target="Paper-NODEID"/>, which has some similarities with HIP. Later work in this area capitalized on the established FEs within the ACS to define new mechanisms, that were not originally envisioned, such as <xref target="Paper-ANHASA"/>.</t>
<t>Following this tradition, this document applies a similar approach to logically decomposing mobility management functions. This way we can establish a common framework that will enable us to reason about DMM functionality with well-defined and well-understood FEs or logical functions. As a first step, the DMM Framework presented in this document demonstrates that the existing mobility management functions of MIPv6, PMIPv6, and HMIPv6 can be abstracted into the following logical functions: </t>
<t>
<list style="numbers">
<t> Session identification (SID): An MN may use an SID to enable session continuity for an application during handover. Alternatively, a separate IP address different from the routing IP address, such as that used previously in the home network where the application was initiated, may be used as the SID. Then, this function is tied to the IP prefix function at the home network. In addition, an MN with multiple ongoing applications may use multiple prefixes. This function is able to associate each prefix with the applications actively using the prefix and release the prefix when no application needs to use it anymore.
<vspace blankLines="1" />
</t>
<t>Location management (LM):
The LM function keeps track of the internetwork location of an MN which may change its IP address as it moves. The information may associate with each SID, the IP routing address of the MN, or of a node that can forward packets destined to the MN.
<vspace blankLines="1" />
In a client-server model of the system, location query and update messages may be exchanged between the client (LMc) and the server (LMs).
Optionally, one (or more) proxy may exist between the LMs and the LMc, i.e., LMs-proxy-LMc. Then, to the LMs, the proxy behaves like the LMc; to the LMc, the proxy behaves like the LMs.
<vspace blankLines="1" />
</t>
<t>Routing Management (RM) function: In principle, it is possible to update the routing tables according to the LM information. Yet it is sometimes not practical or not scalable to update the routing tables dynamically to reflect the fast changes of locations especially when a very large number of MNs are in the Internet. The RM function is then an additional routing function beyond those provided by the routing tables, such as forwarding packets using a tunnel, rewriting a packet header to route using another IP address. It is often sufficient to have this additional function in only a limited number of special routers. Then, the RM function in these routers will need to intercept the packets to/from the MN and forward the packets, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to the destination.
<vspace blankLines="1" />
</t>
</list>
</t>
<t>In addition, the Access Router (AR) logical function provides first-hop network access and includes functionality below the network layer, e.g. radio communication facilities. An AR may provide home address allocation as well as act as RM.
</t>
</section>
<!-- Existing mobility protocols -->
<section anchor="sec-func-mp" title="Mobility Protocol Functional Decomposition">
<t> This section shows that existing mobility management protocols can be expressed as different configurations of the logical functions introduced in <xref target="sec-mmlf"/> above. Using these generic logical functions, we will build up the existing mobility protocols one step at a time in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA. Functions are added and modified as needed in each step.</t>
<!-- MIPv6 -->
<section title="Decomposing Mobile IPv6">
<t> Fig. 1 illustrates the Mobile IPv6 <xref target="RFC6275"/> functional decomposition using the logical functions introduced in <xref target="sec-mmlf"/>. The combination of the RM, LM and HoA allocation logical functions in Network1 effectively defines the home agent or the mobility anchor. In the depicted network scenario, the mobile node designated as MN11 was originally attached to Network1 and was allocated an IP prefix for its home address (HoA11). At a later stage, MN11 moves to Network3, where it is allocated a new prefix to configure the IP address IP32. LM1 maintains the binding HoA11:IP32 so that packets from its correspondent node CN21 in Network2 destined to HoA11 can be intercepted by RM1, which will then tunnel them to IP32. MN11 must perform mobility signaling using the LU function.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
SID11,IP32
+-----+
| LM1 |
+-----+
location=IP32
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| RM1 |
+-----+
.
. +----+ +----+ +----+
. | | |MN11| | |
. |MN31| |+RM | |CN21|
. | | |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 IP32,
=IP11 SID11
]]></artwork>
<postamble>Figure 1. Functional decomposition of Mobile IPv6</postamble>
</figure>
</section>
<!-- MIPv6 and PMIPv6 -->
<section title="From MIPv6 to PMIPv6">
<t>The functional decomposition of Proxy Mobile IPv6 <xref target="RFC5213"/> according to the proposed framework is shown in Fig. 2. In PMIPv6, the combination of LM, RM, and HoA allocation effectively defines the Local Mobility Anchor (LMA). The combination of AR and LU together with additional signaling with MN comprises the Mobile Access Gateway (MAG). In the figure, MN11 is attached to the access router AR31 which has the IP address IP31 in Network3. LM1 maintains the binding HoA11:IP31. The access router AR31 also behaves like a home link to MN11 so that MN11 can use its original IP address HoA11. </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
SID11,IP31
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| RM1 |
+-----+
.
. +----+ +----+
. |AR31| | |
. |+RM | |CN21|
. |+LMc| | |
. +----+ +----+
SID11 IP31
=IP11 |
|
+----+
|MN11|
+----+
SID11
=IP11
]]></artwork>
<postamble>Figure 2. Functional decomposition of PMIPv6</postamble>
</figure>
<t> MIPv6 and PMIPv6 both employ the same concept of separating the session identifier (HoA) from the routing address (CoA). Fig. 3 contrasts (a) MIPv6 with (b) PMIPv6 by illustrating the destination IP address in the network-layer header as a packet traverses the network from the CN to the MN. Note that MIPv6 and PMIPv6 bundle three mobility management logical functions, namely, LM1, IP1 prefix allocation and RM1 into the home agent (HA) and Local Mobility Anchor (LMA), respectively.</t>
<t>Fig. 3 shows that, as far as data-plane traffic is concerned, routing from CN to MN+LU in MIPv6 is similar to the route from CN to AR+LU in PMIPv6. The difference is in that in the former case, the MN with the LU function is substituted by the combination of the AR with the LU function and the MN. While additional signaling is needed to enable the combination of AR+LU and MN to behave like MN+LU in MIPv6, such signaling can be confined between the AR+LU and the MN only. It can therefore be seen under this unified formulation, that a host-based mobility management protocol can be translated using this substitution into a network-based mobility management protocol and vice versa. </t>
<figure>
<artwork><![CDATA[
(a) MIPv6:
+---+ +---+---+ +---+
|SID| --> |SID|SID| |SID|
| | | |---| |---|
| | | |IP | ==> |IP |
+---+ +---+---+ +---+
CN RM MN+RM+LMc
(b) PMIPv6:
+---+ +---+---+ +---+---+ +---+
|SID| --> |SID|SID| |SID|SID| --> |SID|
| | | |---| |---| | | |
| | | |IP | ==> |IP | | | |
+---+ +---+---+ +---+---+ +---+
CN RM AR+RM+LMc MN
]]></artwork>
<postamble>Figure 3. Network layer in the protocol stack of packets
sent from the CN and tunneled
(a) to the MN+RM+LMc in MIPv6; and
(b) to the AR+RM+LMc in PMIPv6
showing the destination IP address as the packet traverses from the CN to the MN.</postamble>
</figure>
</section>
<!-- HMIPv6 -->
<section title="Hierarchical Mobile IPv6">
<t> The functional decomposition of Hierarchical Mobile IPv6 <xref target="RFC5380"/> is shown in Fig. 4. Besides the logical functions LM1, RM1, and HoA1 prefix allocation in Network1, as we have seen above for MIPv6 and PMIPv6, there is an RM function (RM3) in the visited network (Network3). RM3 acts also as a proxy between LM1 and MN11 in the hierarchical LM function LM1--RM3--MN11. That is, LM1 maintains the LM binding HoA11:RM3 while RM3 tracks the LM binding HoA11:IP32. The combined function of RM and the LM proxy function is the Mobility Anchor Point (MAP).</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+ +-----+
| RM1 | | RM3 |
| | |+ LM |
| | |proxy|
+-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
]]></artwork>
<postamble>Figure 4. Functional decomposition of Hierarchical Mobile IPv6</postamble>
</figure>
<t>Note that as depicted in Fig. 4, if MN11 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network-based.</t>
</section>
<!-- Distributing mobility anchors -->
<section title="Distributing Mobility Anchors">
<t>As we have seen so far, the framework is sufficiently expressive to enable us to decompose the major MIPv6 variants. It is possible to replicate the mobility anchoring function for any of MIPv6, PMIPv6, or HMIPv6, in multiple networks as shown in Fig. 5 which illustrates such an example with three networks. </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| RM1 | | RM3 | | RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. |+RM | |+RM | | |
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
]]></artwork>
<postamble>Figure 5. Distributing mobility anchors using the DMM Framework logical functions</postamble>
</figure>
</section>
<!-- HAHA -->
<section title="Migrating Home Agents">
<t>When all logical functions of the Framework are bundled into a single entity e.g., a home agent in MIPv6 or a local mobility anchor in PMIPv6, in a single network, the result is triangular routing when the MN and the CN are in networks close to each other but are far from the anchor point. A method to solve the triangle routing problem is to duplicate the anchor points in many networks in different geographic locations as advocated in <xref target="Paper-Migrating.Home.Agents"/>. A functional decomposition of Migrating Home Agents is shown in Fig. 6: the RM function is available in each of the three networks Network1, Network2, and Network3. The LM function in each network (LM0) contains the LM information for all three networks. Each RM in each network advertises the HoA IP prefixes of all these networks using anycast. Traffic from CN21 in Network2 destined to HoA11 will therefore be intercepted by the RM nearest to the CN, i.e. RM2 in the example of Fig. 6. Using the LM information in LM0, RM2 will use the binding HoA11:IP32 to tunnel the packets to MN11.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM0 |------| LM0 |------| LM0 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| RM1 | | RM3 | | RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
]]></artwork>
<postamble>Figure 6. Functional decomposition of Migrating Home Agents</postamble>
</figure>
<t> Similarly, traffic originating from MN11 will be served by its nearest RM (RM3). Triangular routing is therefore avoided. Yet the synchronization of all home agents becomes a challenge as discussed in <xref target="Paper-SMGI"/>. In addition, the amount of signaling traffic necessary for synchronizing the home agents may become excessive when both the number of mobile nodes and the number of home agents increase. </t>
<t> As before, if MN11 in Fig. 6 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network-based. </t>
</section>
</section>
<!-- DMM Functional Scenarios -->
<section anchor="sec-scenarios" title="DMM Functional Decomposition Scenarios">
<t>This section covers the functional description of DMM. Basically, the scenarios present a way to distribute the logical mobility functions.</t>
<!-- Flat Network Scenario -->
<section title="Flat Network Scenario">
<t>In a flat network, the logical functions may all be located at the AR as shown in Figs. 7 and 8, respectively. For example, <xref target="I-D.seite-dmm-dma"/> and <xref target="I-D.bernardos-dmm-distributed-anchoring"/> are PMIPv6-based implementations of this scenario. These two figures depict the network- and client-based distributed mobility management scenarios, respectively. AR is expected to support the HoA allocation function. Then, depending on the mobility situation of the MN, the AR can run different functions: </t>
<t>
<list style="numbers">
<t>AR can act as a standard IP router;
<vspace blankLines="1" />
</t>
<t>AR can provide the RM function (i.e. act as mobility anchor);
<vspace blankLines="1" />
</t>
<t>AR can provide the LU function;
<vspace blankLines="1" />
</t>
<t>AR can provide both RM and LU functions.</t>
</list>
</t>
<!-- Network-based Mobility Management -->
<section title="Network-based Mobility Management">
<t>The functional decomposition of network-based mobility management is depicted in Fig. 7. In case (1), MN1 attaches to AR1. AR advertises the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1 initiates a communication with CN11. </t>
<t>In case (2), MN1 performs a handover from AR1 to AR3 while maintaining ongoing IP communication with CN11. AR1 becomes the mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM functions on behalf of MN1. AR3 performs LU up to the LM in AR1: AR3 indicates to AR1 the new location of the MN1. AR3 allocates a new IP prefix (HoA3) for new IP communications. That is, HoA3 is used for all new IP communications, e.g., if MN1 initiates IP communication with CN21. AR3 shall act as a legacy IP router for MN1-CN21 communication. </t>
<t>In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP communication with CN11 and CN21. AR1 is the mobility anchor for the MN1-CN11 IP communication. AR3 becomes the mobility anchor for the MN1-CN21 IP communication. Both AR1 and AR3 run RM and LM functions for MN1, respectively, anchoring HoA1 and HoA3. AR2 performs location updates up to the LMs in AR1 and AR3 for respectively relocate HoA1 and HoA3. </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+
|CN11| +-----+ |CN11| +-----+ +-----+ |CN21|
| |------| | | |------| RM1 |------| |------- | |
+----+ | | +----+ | LM1 |------|LU31 | +----+
| AR1 | | AR1 | |AR3 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | | |
+----+ +----+
HoA11 HoA11,
HoA31
(1) (2)
Network2
Network1 HoA2 al
+----+ HoA1 alc +-----+
|CN11| +-----+ | |
| |------| RM1 |-----------------|LU21 |-------+
+----+ | LM1 |-----------------|AR2 | |
| AR1 | | | |
| | Network3 +-----+ |
+-----+ HoA3 al | | +----+
+-----+ | | |MN1 |
+----+ |RM3 |------ | | |
|CN21| |LM3 |-------- +----+
| |------| | HoA11,
+----+ |AR3 | HoA31
+-----+ (3)
]]></artwork>
<postamble>Figure 7. Network-based DMM architecture for a flat network</postamble>
</figure>
</section>
<!-- Client-based Mobility Management -->
<section title="Client-based Mobility Management">
<t>The functional decomposition of client-based mobility management is depicted in Fig. 8. In case (1), MN1 attaches to AR1. AR advertises the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1 initiates a communication with CN11.</t>
<t>In case (2), MN1 performs a handover from AR1 to AR3 while maintaining ongoing IP communication with CN11. AR1 becomes the mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM functions for MN1. The MN performs LU directly up to the LM in AR1 or via AR3; in this case AR3 acts as a proxy locator (pLU) (e.g. as a FA in MIPv4). AR3 allocates a new IP prefix (HoA3) for new IP communications. HoA3 is supposed to be used for new IP communications, e.g., if MN1 initiates IP communication with CN21. AR3 shall act as a legacy IP router for MN1-CN21 communication. </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc +----+
|CN11| +-----+ |CN | +-----+ +-----+ |CN21|
| |------| | | |------| RM1 |------| |------- | |
+----+ | | +----+ | LM1 |------|pLU31| +----+
| AR1 | | AR1 | |AR31 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | |LU31|
+----+ +----+
HoA11 HoA11,
IP31
(1) (2) ]]></artwork>
<postamble>Figure 8. Client-based DMM architecture for a flat network</postamble>
</figure>
</section>
</section>
<!-- Fully Distributed Scenario with Separation of Control and Data Planes -->
<section title="DMM with Control and Data Plane Separation">
<t> This section considers a scenario which involves multiple RMs and a distributed LM database. The different use case scenarios of distributed mobility management are described in <xref target="I-D.yokota-dmm-scenario"/> as well as in <xref target="Paper-Distributed.Mobility.Review"/>. The functional decomposition described in this document can be used to understand better the data and control plane separation.</t>
<t>Fig. 9 shows an example DMM topology with the same three networks we have been using in Fig. 5. As in Fig. 5, each network in Fig. 9 has its own IP prefix allocation function. In the data plane, the routing management function is distributed to multiple locations at the RMs so that routing can be optimized. In the control plane, the RMs may exchange information with each other.</t>
<t>In addition to these features, the LM function in Fig. 9 is a distributed database, possibly implemented with multiple virtual or physical servers, handling the mapping of HoA to CoA. To perform routing management, the RMs need the location information which is maintained at LM1, LM2, and LM3. The RMs are, therefore, the clients of the LM servers and may also send location updates to the LM as the MNs perform the handover. The location information may either be pulled from the LM servers by the RM, or pushed to the RM by the LM servers. In addition, the RM may also cache a limited amount of location information.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| RM1 |------| RM3 |------| RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
]]></artwork>
<postamble>Figure 9. DMM with Control and Data Plane Separation</postamble>
</figure>
<t> Fig. 9 illustrates three RMs (RM1, RM2, and RM3) in three networks. In this scenario we take that MN11 has moved from Network1 supported by RM1 and LM1 to Network3 supported by RM3 and LM3. MN11 may use the homa address (HoA11) allocated to it when it was directly connected to the former network for those application sessions that were started when the mobile node was attached there and do require session continuity after the handover to the latter network. When MN11 is connected to Network1, no location management is needed; LM1 will not keep an entry for HoA11. After MN11 handovers to Network3, the LM1 server maintains a mapping of HoA11 to RM3. That is, LM1 points to Network3 and it is this network that will keep track of how to reach MN11. Such a hierarchical mapping can prevent frequent signaling updates to LM1, as MN11 performs intra-network handover(s) within the Network3 domain. In other words, the concept of hierarchical mobile IP <xref target="RFC5380"/> is applied here for location management only but not for data plane routing.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document presents no IANA considerations.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.5380" ?>
<?rfc include="reference.RFC.5949" ?>
<?rfc include="reference.RFC.5568" ?>
<?rfc include="reference.RFC.4988" ?>
<reference anchor="I-D.yokota-dmm-scenario">
<front>
<title>Use case scenarios for Distributed Mobility Management</title>
<author initials="H" surname="Yokota" fullname="Hidetoshi Yokota">
<organization />
</author>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization />
</author>
<author initials="E" surname="Demaria" fullname="Elena Demaria">
<organization />
</author>
<author initials="Z" surname="Cao" fullname="Zhen Cao">
<organization />
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-yokota-dmm-scenario-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-yokota-dmm-scenario-00.txt" />
</reference>
<!--
<reference anchor="I-D.chan-netext-distributed-lma">
<front>
<title>Distributed Local Mobility Anchors</title>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
</author>
<author initials="F" surname="Xia" fullname="Frank Xia">
<organization>Huawei Technologies</organization>
</author>
<author initials="J" surname="Xiang" fullname="Justin Xiang">
<organization>Huawei Technologies</organization>
</author>
<author initials="H" surname="Ahmed" fullname="Hanan Ahmed">
<organization>Huawei Technologies</organization>
</author>
<date month="March" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-chan-netext-distributed-lma-03" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-chan-netext-distributed-lma-03.txt" />
</reference>
-->
<reference anchor="I-D.ietf-dmm-requirements">
<front>
<title>Requirements for Distributed Mobility Management</title>
<author fullname="H Anthony Chan" surname="Chan (Ed.) et al." initials="H"></author>
<date year="2012" day="22" month="December"/>
</front>
<seriesInfo value="draft-ietf-dmm-requirements-06" name="Internet-Draft"/>
</reference>
<reference anchor="I-D.seite-dmm-dma">
<front>
<title>Distributed Mobility Anchoring</title>
<author fullname="Pierrick Seite" surname="Seite" initials="P"></author>
<author fullname="Philippe Bertin" surname="Bertin" initials="P"></author>
<author fullname="Jong-Hyouk Lee" surname="Lee" initials="JH"></author>
<date year="2013" day="9" month="January"/>
</front>
<seriesInfo value="draft-seite-dmm-dma-06" name="Internet-Draft"/>
</reference>
<!--
<reference anchor="I-D.liu-dmm-pmip-based-approach">
<front>
<title>PMIP Based DMM Approaches</title>
<author fullname="Dapeng Liu" surname="Liu" initials="D">
<organization/> </author>
<author fullname="Jun Song" surname="Song" initials="J">
<organization/> </author>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<date year="2012" day="12" month="March"/>
</front>
<seriesInfo value="draft-liu-dmm-pmip-based-approach-02" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-liu-dmm-pmip-based-approach-02.txt" type="TXT"/>
</reference>
-->
<reference anchor="I-D.bernardos-dmm-distributed-anchoring">
<front>
<title>PMIPv6-based distributed anchoring</title>
<author fullname="Carlos Bernardos" surname="Bernardos" initials="CJ">
<organization/> </author>
<author fullname="Juan Zuniga" surname="Zuniga" initials="JC">
<organization/> </author>
<date year="2012" day="20" month="September"/>
</front>
<seriesInfo value="draft-bernardos-dmm-distributed-anchoring-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distributed-distributed-anchoring-01.txt" type="TXT"/>
</reference>
<reference anchor="Paper-Migrating.Home.Agents">
<front>
<title>Migrating Home Agents Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa">
<organization />
</author>
<author initials="G" surname="Valadon">
<organization />
</author>
<author initials="J" surname="Murai">
<organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="" value="Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies" />
</reference>
<reference anchor="Paper-Distributed.Mobility.Review">
<front>
<title>Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues</title>
<author initials="H" surname="Chan">
<organization />
</author>
<author initials="H" surname="Yokota">
<organization />
</author>
<author initials="J" surname="Xie">
<organization />
</author>
<author initials="P" surname="Seite">
<organization />
</author>
<author initials="D" surname="Liu">
<organization />
</author>
<date month="February" year="2011" />
</front>
</reference>
<reference anchor="Paper-Distributed.Mobility.PMIP">
<front>
<title>Proxy Mobile IP with Distributed Mobility Anchors</title>
<author initials="H" surname="Chan">
<organization />
</author>
<date month="December" year="2010" />
</front>
<seriesInfo name="" value="Proceedings of GlobeCom Workshop on Seamless Wireless Mobility" />
</reference>
<reference anchor="Paper-SMGI">
<front>
<title>Support Mobility in the Global Internet</title>
<author initials="L" surname="Zhang">
<organization />
</author>
<author initials="R" surname="Wakikawa">
<organization />
</author>
<author initials="Z" surname="Zhu">
<organization />
</author>
<date month="September" year="2009" />
</front>
<seriesInfo name="" value="Proceedings of ACM Workshop on MICNET, MobiCom 2009, Beijing, China" />
</reference>
<reference anchor="Book-AN">
<front>
<title>Ambient networks: co-operative mobile networking for the wireless world.</title>
<author initials="N" surname="Niebert">
<organization />
</author>
<author initials="A" surname="Schieder">
<organization />
</author>
<author initials="J" surname="Zander">
<organization />
</author>
<author initials="R" surname="Hancock (Eds.)">
<organization />
</author>
<date year="2007" />
</front>
<seriesInfo name="" value="Wiley" />
</reference>
<reference anchor="Paper-GLL">
<front>
<title>Generic link layer functionality for multi-radio access networks</title>
<author initials="G." surname="Koudouridis"></author>
<author initials="R." surname="Aguero"></author>
<author initials="E." surname="Alexandri"></author>
<author initials="J." surname="Choque"></author>
<author initials="K." surname="Dimou"></author>
<author initials="H. R." surname="Karimi"></author>
<author initials="H." surname="Lederer"></author>
<author initials="J." surname="Sachs"></author>
<author initials="R." surname="Sigle"></author>
<date year="2005" />
</front>
<seriesInfo name="" value="Proc. IST Mobile and Wireless Communication Summit 2005." />
</reference>
<reference anchor="Paper-MRRM">
<front>
<title>Multi-radio resource management for ambient networks</title>
<author initials="F." surname="Berggren"></author>
<author initials="A." surname="Bria"></author>
<author initials="L." surname="Badia"></author>
<author initials="I." surname="Karla"></author>
<author initials="R." surname="Litjens"></author>
<author initials="P." surname="Magnusson"></author>
<author initials="F." surname="Meago"></author>
<author initials="H." surname="Tang"></author>
<author initials="R." surname="Veronesi"></author>
<date year="2005" />
</front>
<seriesInfo name="" value="Personal, Indoor and Mobile Radio Communications (PIMRC) 2005. IEEE 16th International Symposium on. Vol. 2, pp. 942-946" />
</reference>
<reference anchor="Paper-NODEID">
<front>
<title>Ambient networks: Bridging heterogeneous network domains</title>
<author initials="B" surname="Ahlgren">
<organization />
</author>
<author initials="L" surname="Eggert">
<organization />
</author>
<author initials="B" surname="Ohlman">
<organization />
</author>
<author initials="A" surname="Schieder">
<organization />
</author>
<date year="2005" />
</front>
<seriesInfo name="" value="Personal, Indoor and Mobile Radio Communications (PIMRC) 2005. IEEE 16th International Symposium on. Vol. 2, pp. 937-941" />
</reference>
<reference anchor="Paper-ANHASA">
<front>
<title>The Ambient Networks heterogeneous access selection architecture</title>
<author initials="K." surname="Pentikousis"></author>
<author initials="R." surname="Aguero"></author>
<author initials="J." surname="Gebert"></author>
<author initials="J. A." surname="Galache"></author>
<author initials="O." surname="Blume"></author>
<author initials="P." surname="Paakkonen"></author>
<date month="October" year="2007" />
</front>
<seriesInfo name="" value="Mobility, Multiaccess, and Network Management (M2NM) 2007. First Ambient Networks Workshop on. Sydney, Australia, October 2007, pp. 49-54" />
</reference>
</references>
<!-- Appendix A -->
<section title="Comparing against DMM requirements">
<t>
This section examines
how the framework meets the DMM requirements.
</t>
<!-- Appendix A.1 -->
<section title="First DMM requirement:
distributed processing">
<t>
The framework has defined a set of mm functions
which can be implemented in a distributed fashion.
As further evidence,
the document explains how the mm functions can be used
to implement in a distributed manner
the major mm protocols
(MIPv6, PMIPv6, HMIP, DMA, MHA).
</t>
</section>
<!-- Appendix A.2 -->
<section title="Second DMM requirement:
Transparency to upper layers when needed">
<t>
In the framework,
transparency depends on how the RM functions is implemented.
This draft has already shown that
using the framework one can express,
for example, PMIP and DMA,
which are transparent to the upper layers.
</t>
</section>
<!-- Appendix A.3 -->
<section title="Third DMM requirement:
IPv6 deployment">
<t>
The framework is not tied to a particular IP version,
and therefore supports IPv6 deployment.
</t>
</section>
<!-- Appendix A.4 -->
<section title="Fourth DMM requirement:
Existing mobility protocols">
<t>
This draft has already described
how to express the functionality of several mm protocols
(MIPv6, PMIPv6, HMIP, DMA, MHA).
More cases can be added as feedback is received.
</t>
</section>
<!-- Appendix A.5 -->
<section title="Fifth DMM requirement:
co-existence">
<t>
The framework enables the expression of existing protocols
in functions
that can be extended to provide
distributed mobility support,
and can be made backwards compatible
with existing implementations.
</t>
</section>
<!-- Appendix A.6 -->
<section title="Sixth DMM requirement:
Security considerations">
<t>
Security risks are associated with the particular DMM solution.
The framework is flexible and does not restrict DMM solutions
in a way that the DMM solution can increase security risks.
</t>
</section>
<!-- Appendix A.7 -->
<section title="Seventh DMM requirement:
multicast">
<t>
It appears possible to extend the framework
by decomposing
multimob solutions with the framework.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:46:37 |