One document matched: draft-ietf-dmm-best-practices-gap-analysis-00.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-ietf-dmm-best-practices-gap-analysis-00">
<front>
<title abbrev="DMM-best-practices-gap-analysis">
Distributed Mobility Management: Current practices and gap analysis
</title>
<author initials="D" role="editor" surname="Liu" fullname="Dapeng Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave, Xuanwu District,
Beijing 100053, China</street>
<street>Email: liudapeng@chinamobile.com</street>
</postal>
</address>
</author>
<author initials="JC." role="editor" surname="Zuniga" fullname="Juan Carlos Zuniga">
<organization>InterDigital Communications, LLC</organization>
<address>
<postal>
<street>1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4</street>
<street>Email: JuanCarlos.Zuniga@InterDigital.com</street>
</postal>
</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, Cesson-Sevigne 35512, France</street>
<street>Email: pierrick.seite@orange.com</street>
</postal>
</address>
</author>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3, Plano, TX 75024, USA</street>
<street>Email: h.a.chan@ieee.org</street>
</postal>
</address>
</author>
<author initials="CJ." surname="Bernardos" fullname="CJ. Bernardos">
<organization>Universidad Carlos III de Madrid</organization>
<address>
<postal>
<street>Av. Universidad, 30 Leganes, Madrid 28911 Spain</street>
<street>Email: cjbc@it.uc3m.es</street>
</postal>
</address>
</author>
<date month="February" year="2013"></date>
<area>Internet</area>
<workgroup>DMM</workgroup>
<abstract>
<t>
This document discusses how to best deploy
the current IP mobility protocols
in distributed mobility management (DMM) scenarios
and analyzes the gaps of such best current practices
against the DMM requirements.
These best current practices are achieved
by redistributing the existing MIPv6 and PMIPv6 functions
in the DMM scenarios.
The analyses is also applied to the real world deployment of IP mobility
in WiFi network and in cellular network.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
The distributed mobility management (DMM) WG has studied the problems
of centralized deployment of mobility management protocols
and the requirements of DMM
[ID-dmm-requirements].
In order to guide the deployment
and before defining any new DMM protocol,
the DMM WG is chartered to investigate first
whether it is feasible to deploy current IP mobility protocols
in DMM scenario in a way that can meet the requirements of DMM.
This document discusses
how to best deploy existing mobility protocols in DMM scenarios
to solve the problems of centralized deployment.
It then analyzes the gaps of such best practices
against the DMM requirements.
</t>
<t>
The rest of this document is organized as follows:
</t>
<t>
Section 3 analyzes the current IP mobility protocols
by examining their existing functions
and how these functions can be reconfigured
to achieve the best practices in DMM scenarios.
Section 4 presents the current practices of WiFi network and 3GPP network.
With WiFi, a DMM scenario is the flattened WiFi network.
After presenting the fundaments what one can do to achieve distribution,
the existing mobility management functions are reconfigured in the flattened networks
for both network- and host-based mobility protocols
using these fundaments as guiding priciples.
The current practices in 3GPP are also described,
and the DMM scenarios are LIPA and SIPTO.
Section 5 presents the gap analyses on the best practice
achieved by reconfiguring currently existing functions
in the DMM scenario
which applies to both those in the WiFi and the 3GPP networks.
</t>
</section>
<!-- 2 Conventions and definitions -->
<section title="Conventions and Terminology">
<!-- 2.1 Conventions -->
<section title="Conventions used in this document">
<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>
</section>
<!-- 2.2 Definitions -->
<section title="Terminology">
<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].
These terms include mobile node (MN), correspondent node (CN), home agent (HA),
local mobility anchor (LMA), and mobile access gateway (MAG).
</t>
<t>
In addition, this document uses the following terms:
</t>
<t>
<list style='hanging'>
<t hangText='Mobility routing (MR)'>
is the logical function
that intercepts packets to/from the HoA of a mobile node
and forwards them,
based on internetwork location information,
either directly towards their destination
or to some other network element
that knows how to forward the packets to their ultimate destination.
<vspace blankLines="1" />
</t>
<t hangText='Home address allocation'>
is the logical function
that allocates the home network prefix
or home address to a mobile node.
<vspace blankLines="1" />
</t>
<t hangText='Location management (LM)'>
is the logical function that manages and keeps track of
the internetwork location information of a mobile node,
which includes the mapping of the MN HoA
to the MN routing address
or another network element
that knows where to forward packets destined for the MN.
<vspace blankLines="1" />
</t>
<t hangText='Home network of an application session (or an HoA IP address)'>
is the network that has allocated the IP address
used as the session identifier (HoA)
by the application being run in an MN.
The MN may be attached to more than one home networks.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
</section>
<!-- 3 Mobility Management Logical Functions -->
<section title="Current IP mobility protocol analysis">
<!-- 3.1 Protocols and existing functions -->
<section title="IP mobility protocols and their mobility management functions">
<t>
The host-based Mobile IPv6
<xref target="RFC6275"/>
and its network-based extension,
PMIPv6
<xref target="RFC5213"/>,
are both a logically centralized mobility management approach
addressing primarily hierarchical mobile networks.
Although they are a centralized approach,
they have important mobility management functions
resulting from years of extensive work
to develop and to extend these functions.
It is therefore fruitful to take these existing functions
and reconfigure them in a DMM scenario
in order to understand how to best deploy the
existing mobility protocols
in a distributed mobility management environment.
</t>
<t>
The existing mobility management functions
of MIPv6, PMIPv6, and HMIPv6
are the following:
</t>
<t>
<list style="numbers">
<t>
Anchoring: allocation of home network prefix or HoA
to an MN that registers with the network;
<vspace blankLines="1" />
</t>
<t>
Mobility Routing (MR) function:
packets interception and forwarding to/from the HoA of the MN,
based on the internetwork location information,
either to the destination
or to some other network element
that knows how to forward the packets to their destination;
<vspace blankLines="1" />
</t>
<t>
Internetwork Location Management (LM) function:
managing and keeping track of the internetwork location of an MN,
which includes a mapping of the HoA
to the mobility anchoring point that the MN is anchored to;
<vspace blankLines="1" />
</t>
<t>
Location Update (LU):
provisioning of MN location information to the LM function;
<vspace blankLines="1" />
</t>
</list>
</t>
<t>
Figure 1 shows Mobile IPv6
<xref target="RFC6275"/>
and Proxy Mobile IPv6
<xref target="RFC5213"/>
with their existing mobility management functions.
In Network1, the combination of the functions
MR, LM and HoA allocation in network1
is the home agent in MIPv6
and is the local mobility anchor in PMIPv6.
In Network3, the AR32+LU combination together with additional signaling with MN comprises the Mobile Access Gateway (MAG) in PMIPv6.
The mobile nodes MN11 and MN12 were originally attached to Network1
and were allocated the IP prefixes
for their respective home addresses HoA11 and HoA12.
</t>
<t>
Using MIPv6, MN11 has moved to Network3,
from which it is allocated a new prefix to configure the IP address IP31.
LM1 maintains the binding HoA11:IP31
so that packets from CN21 in Network2
destined to HoA11 will be intercepted by MR1,
which will then tunnel them to IP31.
MN11 must perform mobility signaling
using the LU function.
</t>
<t>
Using PMIPv6, MN12 has moved to Network3
and attached to the access router AR32
which has the IP address IP32 in Network3.
LM1 maintains the binding HoA12:IP32.
The access router AR32 also behaves like a home link to MN12
so that MN12 can use its original IP address HoA12.
</t>
<!--
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA11<-->IP31
HoA12<-->IP32
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| MR1 |
+-----+
. .
. .
. . +----+ +----+ +----+
. . |MN11| |AR32| |CN21|
. . |+LU | |+LU | | |
. . +----+ +----+ +----+
. . IP31, IP32,
. HoA11 =====> HoA11 |
. MIPv6 |
. +----+
. |MN12|
. +----+
HoA12 =====> HoA12
PMIPv6
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 1. MIPv6, PMIPv6 and their functions.
</t>
<!-- 3.1 end-->
</section>
<!-- 3.2 Reconfiguring existing functions in DMM scenario -->
<section title="Reconfiguring existing functions in DMM scenario">
<t>
In order to best deploy current protocols in DMM scenario,
the existing mobility functions of MIPv6, PMIPv6, and HMIPv6
configured into a DMM scenario as follows.
</t>
<!--
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA11<-->IP31 | |
HoA12<-->IP32 | |
HoA1 alc IP3 alc IP2 alc
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR3 | | MR2 |
+-----+ +-----+ +-----+
. . / \
. . / \
. . / \
. . +----+ +----+ +----+
. . |MN11| |AR32| |CN21|
. . |+LU | |+LU | | |
. . +----+ +----+ +----+
. . IP31, IP32,
. HoA11 =====> HoA11 |
. MIPv6 |
. +----+
. |MN12|
. +----+
HoA12 =====> HoA12
PMIPv6
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 2. Reconfiguring existing functions in DMM scenario.
</t>
<t>
Achieving the best practices
by reconfiguring the existing functions in this manner
will be applied to the DMM scenario of a flattened WiFi network
in Section 4.2.
</t>
<!-- 3.1 end-->
</section>
<!-- 3 end-->
</section>
<!-- 4 DMM Functional Scenarios -->
<section title="Current practices of IP mobility protocols">
<t>
This section covers the practices
for distribution of IP mobility management.
Basically, the scenario presents a way
to distribute the logical mobility functions.
Gap analysis will be made on these scenarios.
</t>
<!-- 4.1 Fundamentals of distribution -->
<section title="Fundamentals of distribution">
<t>
There are many possibilities
to implement a distributed mobility management system
and this document could not be exhaustive.
However,
this document is supposed to focus
on current mobility architectures
and to reuse existing mobility protocol
as much as possible;
it thus allows fixing the main technical guidelines
and assumptions for current practices.
Then,
gap analysis will analyze
these basic solution guidelines
with respect to the requirements
from [ID.ietf.dmm.requirements]
and pave the way for optimizations.
Technical guidelines for DMM current practices
are as follows:
</t>
<t>
The technical assumptions or guidelines are:
<list style="numbers">
<t>
When mobility support is required,
the system will select the mobility anchor
closest to the MN.
</t>
<t>
This document focuses on mobility management
realized by preservation of the IP address
across the different points of attachment
during the mobility.
IP flows of applications
which do not need constant IP address
are not handled by DMM.
It is typically the role of a connection manager
to distinguish application capabilities
and trigger the mobility support accordingly.
Further considerations on application management
are out of the scope of this document.
</t>
<t>
IP address preservation is ensured
thanks to traffic redirection.
</t>
<t>
Mobility traffic redirection
is limited within the access network,
e.g., traffic redirection taking place
between access routers.
In this document,
traffic redirection relies on
Network based mobility management protocols
like PMIP [RFC 5213] or GTP [TS 23.402].
Mobility management and traffic redirection
come into play
only when the MN moves from the point of attachment
where the IP flow has been initiated;
in case of mobility,
this point of attachment becomes the anchoring point.
It implies that the MN could be managed
by more the one anchor when more than one IP flow,
initiated within different points of attachment,
are running.
</t>
<t>
An access router will advertise anchored prefixes
and a local prefix,
i.e., a prefix topologically valid at the access router.
When being initiated,
an IP communication must prefer
the local prefix to the anchored prefix.
Prefix management is realized
with IPv6 prefix deprecation.
</t>
</list>
</t>
<!-- 4.1 end-->
</section>
<!-- 4.2 Flattening the WiFi Network -->
<section title="Flattening the WiFi Network">
<t>
The most common Wi-Fi architectures are depicted on figure 3.
In some cases,
these architectures can rely on Proxy Mobile IPv6,
where the access aggregation gateway
plays the role of LMA
and the MAG is supported
either by the Residential Gateway (RG),
the WLAN Controller (WLC) or an Access Router (AR)
[ID. gundavelli-v6ops-community-wifi-svcs].
</t>
<!--
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
+--------+ _----_
+---+ | | _( )_
|AAA|. . . . . . . | Access |----------( Internet )
+---+ | Aggreg | (_ _)
| Gateway| '----'
+--------+
| | | PMIP
| | +-----|-------+
| | |
PMIP | - PMIP +-----+
+--------|------+ | | AR |
| | +-----+
+-----+ +-----+ *---------*
| RG | | WLC | ( LAN )
+-----+ +-----+ *---------*
. / \ / \
/ \ +----+ +----+ +----+ +----+
MN MN |WiFi| |WiFi| |WiFi| |WiFi|
| AP | | AP | | AP | | AP |
+----+ +----+ +----+ +----+
. .
/ \ / \
MN MN MN MN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 3. WiFi network architectures.
</t>
<t>
Because of network densification and distribution of content,
it may be necessary
to distribute the access aggregation gateway functions
closer to the MN;
see [ID.ietf-dmm-requirements] for motivation of network flattening.
In an extreme distribution case,
the access aggregation gateway functions,
including the mobility management functions,
may all be located at the AR
as shown in Figures 4 and 5, respectively.
These two figures depict the network- and client-based
distributed mobility management scenarios.
The 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>
the AR can act as a legacy IP router;
<vspace blankLines="1" />
</t>
<t>
the AR can provide the MR function
(i.e. act as mobility anchor);
<vspace blankLines="1" />
</t>
<t>
the AR can provide the LU functions;
<vspace blankLines="1" />
</t>
<t>
the AR can provide both MR and LU functions.
<vspace blankLines="1" />
</t>
</list>
</t>
<t>
For example,
[I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed-anchoring] are PMIPv6 based implementation of this scenario.
</t>
<!-- 4.1.1 Network-based Mobility Management -->
<section title="Network-based Mobility Management">
<t>
Basic practices for distribution
of network-based mobility management
is depicted in Figure 4.
</t>
<t>
Initially, MN1 attaches to AR1, (1).
According to vanilla IPv6 operations,
AR1 advertises a prefix (HoA1) to MN1
and then, AR1, acts as a legacy IP router.
Then, MN1 initiates a communication
with CN11 using an IP address formed from the prefix HoA1.
So, AR1 runs usual IP routing?
and mobility management does not come into play.
</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 MR and LM functions for MN1.
AR3 performs LU up to the LM in AR1:
AR3 indicates to AR1 the new location of the MN1.
AR3 advertises both HoA1 and a new IP prefix (HoA3)
which is supposed to be used for new IP communication,
e.g., if MN1 initiates IP communication with CN21.
Prefix HoA1 is deprecated
as it is expected to be used only for communications
anchored to AR1.
AR3 shall act as a legacy IP router for MN1-CN21 communication,
i.e., mobility management does not come.
</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 MR 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.
AR2 advertises a new prefix (HoA2),
expected to be used for new IP communications,
and deprecates HoA1 and HoA3 used by the anchored IP sessions.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+
|CN11| +-----+ |CN11| +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|LU31 | +----+
| AR1 | | AR1 | |AR3 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | | |
+----+ +----+
HoA11 HoA11,
HoA31
(1) (2)
Network2
Network1 HoA2 al
+----+ HoA1 alc +-----+
|CN11| +-----+ | |
| |------| MR1 |-----------------|LU21 |-------+
+----+ | LM1 |-----------------|AR2 | |
| AR1 | | | |
| | Network3 +-----+ |
+-----+ HoA3 al | | +----+
+-----+ | | |MN1 |
+----+ |MR3 |------ | | |
|CN21| |LM3 |-------- +----+
| |------| | HoA11,
+----+ |AR3 | HoA31
+-----+ (3)
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. Network-based DMM architecture for a flat network.
</t>
<!-- 4.2 end-->
</section>
<!-- 4.1.2 Client-based Mobility Management -->
<section title="Client-based Mobility Management">
<t>
Basic practices for distribution of client-based mobility management
is depicted in Figure 5.
Here, client-based mobility management
does not necessary implies Mobile IP because,
according to distribution fundamentals (section 4.1),
current practices rely on principles
inherited from PMIP and traffic redirection
takes place only between access routers.
However, with client based mobility,
the MN is authorized to send information
on its ongoing mobility session;
for example in order to facilitate localization update operations
[I-D.seite-dmm-dma].
</t>
<t>
In case (1), MN1 attaches to AR1.
AR advertises the prefix HoA1 to MN1 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
with ongoing IP communication with CN11.
AR1 becomes the mobility anchor for the MN1-CN11 IP communication:
AR1 runs MR 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>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc +----+
|CN11| +-----+ |CN | +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|pLU31| +----+
| AR1 | | AR1 | |AR31 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | |LU31|
+----+ +----+
HoA11 HoA11,
IP31
(1) (2) ]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 5. Client-based DMM architecture for a flat network.
</t>
<!-- 4.1.2 end-->
</section>
<!-- 4.1 end-->
</section>
<!-- 4.4 3GPP network-->
<section title="IP mobility protocol deployment in 3GPP network">
<t>
The 3rd Generation Partnership Project (3GPP)
is the standard development organization
that specifies the 3rd generation mobile network
and LTE (Long Term Evolution).
By November 2, 2012, there are 113 commercial LTE networks in 51 countries
already deployed, and
there are 360 operators in 105 countries investing in LTE.
GSA forecasts 166 commercial LTE networks in 70 countries by end of 2012.
</t>
<t>
The 3GPP SAE network architecture is visualized in the Figure 6:
</t>
<!--
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
+----+
.....................................| |
. |HSS |
. ............................| |
. . +----+
. . +----+
. . ........................| |
. . . |PCRF|.........
. . . .......| | .
. . . . +----+ .
+---------+ +-------+ +----------+ ^ ^ ^ ^ ^
|3GPP | |Serving| | PDN GW |..............(IP Network)
|access |....|GW |....| | v v v v v
+---------+ +-------+ +----------+
. | | . .
. | | . .
. | | . .
. | | . .
+---------+.............S2a... | | . .
|Trusted | / | . .
|non-3GPP | ------------S2c--- | . .
..|access |/ | . .
. +---------+ | . .
. / | . .
+--+ / | . .
| |--S2c-- | . .
|UE| | . .
| |--S2c-- / . .
+--+ \ -------S2c----- . .
. \ / . .
. +---------+ +----+ . . +----+
..| |\ /| |...S2b......... .......| |
|Untrusted| -- |ePDG| |AAA |
|non-3GPP | | |........................| |
|non-3GPP | +----+ +----+
|access | .
| |.....................................
+---------+
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 6. 3GPP SAE architecture.
</t>
<t>
In SAE architecture, there are two types of non-3GPP access network:
trusted and untrusted.
Trusted non-3GPP access means
that the non-3GPP access network has a trust relationship
with the 3GPP operator.
Untrusted means the operator considers the non-3GPP network as untrusted,
the non-3GPP network may either be or not be deployed by the same operator.
The mobility support within the 3GPP network
mostly relies on s5/s8 interface
which is based on GTP or PMIP.
For the scenario which provide non-3GPP network and 3GPP network mobility,
there are mainly three solutions that is using IP mobility protocol:
</t>
<t>
In 3GPP SAE architecture, there are three interfaces that use IP mobility protocol:
<list style="numbers">
<t>
S2a Interface:
S2a is the interface
between trusted non-3GPP access network and the EPC.
This interface could be based on GTP or PMIP.
When using PMIP, the PDN gateway in the EPC will function as LMA.
The mobile station will anchor at this LMA/PDN-Gateway entity.
The mobile station will maintain the session continuity
when handover between the non-3GPP access network and 3GPP network.
</t>
<t>
S2b Interface:
S2b is the interface
between the trusted-non-3GPP access network and the PDN gateway.
This interface is based on PMIP.
The PDN-gateway functions as PMIP LMA.
The mobile station will anchor at this LMA/PDN-Gateway entity.
The ePDG in the EPC network will function as PMIP MAG.
The mobile station will maintain the session continuity
when handover between the non-3GPP access network and 3GPP network.
</t>
<t>
S2c Interface:
S2c is the interface between the mobile station and the EPC network.
It can be used in both trusted and un-trusted 3GPP access network.
S2c interface uses DSMIPv6 protocol which is specified by IETF.
The PDN gateway functions as DSMIPv6 Home agent in this scenario.
When using non-trusted-non-3GPP access network,
the mobile station will first establish IPSec tunnel toward the ePDG,
and runs DSMIPv6 inside this IPSec tunnel.
The mobile station will maintain the session continuity
when handover between the non-3GPP access network and 3GPP network.
</t>
</list>
</t>
<!-- 4.4.1 3GPP LIPA/SIPTO -->
<section title="3GPP LIPA/SIPTO">
<t>
Another scenario that uses IP mobility protocol in 3GPP currently
is the LIPA/SIPTO scenario.
LIPA stands for Local IP Access.
The following figure shows the LIPA scenario.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
+---------+ IP traffic to mobile operator's CN
|Mobile |....................................(Operator's CN)
|Station |..................
+---------+ . Local IP traffic
.
+-----------+
|Residential|
|enterprise |
|IP network |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 7. LIPA scenario.
</t>
<t>
The main feature of LIPA is that
the mobile station can access a local IP network through H(e)NB.
H(e)NB is a small, low-power cellular base station,
typically designed for use in a home or enterprise.
The mobile station can access the local network's service,
for example, connect to a user home's TV,
computers, picture libraries etc.
The LIPA architecture is illustrated in Figure 8.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
+---------------+-------+ +----------+ +-------------+
|Residential | |H(e)NB | | Backhaul | |Mobile |
|Enterprise |..|-------|..| |..|Operator |..(IP Network)
|Network | |L-GW | | | |Core network |
+---------------+-------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 8. LIPA architecture.
</t>
<t>
There is a local gateway function in the H(e)NB.
The local gateway (L-GW) function acts as a GGSN (UMTS) or P-GW (LTE).
The mobile station uses a special APN
to establish the PDP context or the default bearer towards the L-GW.
</t>
<t>
One thing that needs to be noted
is that in 3GPP Release 10,
there is no mobility support
when the mobile stations moves between H(e)NBs.
The bearer will be broken when the mobile moves among H(e)NBs.
For example, when several H(e)NBs are deployed in an office,
there is no mobility support
when the mobile station needs to do handover between the H(e)NBs.
The user session would be broken
when a user moves from one H(e)NB coverage to another.
</t>
<t>
The SIPTO (Selected IP Traffic Offload) scenario
is illustrated in the Figure 9.
There is also a local gateway function near the base station.
The traffic can be routed through the local gateway to offload the traffic.
</t>
<t>
In both LIPA and SIPTO architecture, the local gateway functions as the
anchor point for the local traffic.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
SIPTO Traffic
|
.
.
+------+ +------+
|L-PGW | ---- | MME |
+------+ / +------+
| /
+-------+ +------+ +------+/ +------+
| UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic
+-------+ +------+ +------+ +------+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 9. SIPTO architecture.
</t>
<!-- 4.4.1 end-->
</section>
<!-- 4.4 end-->
</section>
<!-- 4.3 Fully Distributed with Separation of Control and Data Planes -->
<section title="Fully distributed scenario with separation of control and data planes">
<t>
For either the WiFi network and cellular network such as 3GPP,
the DMM scenario can be a fully distributed scenario
separation of control and data planes.
The reconfiguration of mobility management functions in these scenario
may consist of multiple MRs and a distributed LM database.
Figure 10 shows such an example DMM architecture
with the same three networks as in Figure 3.
As is in Figure 3,
each network in Figure 10 has its own IP prefix allocation function.
In the data plane,
the mobility routing function
is distributed to multiple locations
at the MRs so that routing can be optimized.
In the control plane,
the MRs may exchange signaling with each other.
In addition to these features in Figure 3,
the LM function in Figure 10 is a distributed database,
with multiple servers,
of the mapping of HoA to CoA.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 |------| MR3 |------| MR2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. |+LU | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 10. A distributed architecture for mobility management.
</t>
<t>
To perform mobility routing,
the MRs need the location information
which is maintained at the LMs.
The MRs 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 MR,
or pushed to the MR by the LM servers.
In addition,
the MR may also cache a limited amount of location information.
</t>
<t>
This figure shows three MRs (MR1, MR2, and MR3)
in three networks.
MN11 has moved from the first network
supported by MR1 and LM1
to the third network supported by MR3 and LM3.
It may use an HoA (HoA11) allocated to it
when it was in the first network
for those application sessions
that had already started when MN11 was attached there
and that require session continuity
after the handover to the third network.
When MN11 was in the first network,
no location management is needed
so that LM1 will not keep an entry of HoA11.
After MN11 has performed its handover to the third network,
the database server LM1 maintains a mapping of HoA11 to MR3.
That is,
LM1 points to the third network
and it is the third network
that will keep track of how to reach MN11.
Such a hierarchical mapping
can prevent frequent update signaling to LM1
as MN11 performs intra-network handover
within the third network.
In other words,
the concept of hierarchical mobile IP [RFC5380]
is applied here
but only in location management
and not in routing in the data plane.
</t>
<!-- 4.3 end-->
</section>
<!-- 4 end-->
</section>
<!-- 5 gap analysis -->
<section title="Gap analysis">
<section title=
"Gap analysis with reconfiguration MIPv6 and PMIPv6 functions in DMM scenario such as the flattened WiFi network">
<!-- 5.1.1 gap analysis with REQ4: existing protocols -->
<section title="Considering existing protocols first">
<t>
The fourth DMM requirement is on existing mobility protocols
[ID-dmm-requirements:
</t>
<t>
REQ4: A DMM solution SHOULD
first consider reusing and extending
IETF-standardized protocols
before specifying new protocols.
</t>
<t>
The best current practice is using
the existing mobility management functions of the current protocols.
</t>
</section>
<!-- 5.1.2 gap analysis with REQ5-1: compatibility -->
<section title="Compatibility">
<t>
The first part of the fifth DMM requirement is on compatibility:
</t>
<t>
REQ5: (first part) The DMM solution MUST
be able to co-exist
with existing network deployments and end hosts.
For example,
depending on the environment in which DMM is deployed,
DMM solutions
may need to be compatible
with other deployed mobility protocols
or may need to interoperate
with a network or mobile hosts/routers
that do not support DMM protocols.
</t>
<t>
Different deployments using the same abstract functions
are basically reconfiguration of these same functions
if their functions use common message formats
between these functions.
A design principle of the IPv6 message format
accommodates the use of common message formats
as it allows to define extension headers,
e.g., use of mobility header and options.
It is shown in Section 4 that MIPv6, PMIPv6,
HMIPv6, Distributing mobility anchors
can be constructed from the abstract functions
by adding more features and additional messages
one on top of the other in the above order.
The later protocol will therefore support
the one from which the later is constructed
by adding more messages.
</t>
</section>
<!-- 5.1.3 gap analysis with REQ3: IPv6 deployment -->
<section title="IPv6 deployment">
<t>
The third DMM requirement on IPv6 deployment is the following.
</t>
<t>
REQ3: DMM solutions SHOULD target IPv6
as the primary deployment environment
and SHOULD NOT be tailored specifically to support IPv4,
in particular in situations
where private IPv4 addresses and/or NATs are used.
</t>
<t>
This is not an issue when using the mobility management functions
of MIPv6 and PMIPv6 which are originally designed for IPv6.
</t>
</section>
<!-- 5.1.4 gap analysis with REQ6: Security considerations -->
<section title="Security considerations">
<t>
The second part of the fourth requirement
as well as the sixth DMM requirement
[ID-dmm-requirements] are as follows:
</t>
<t>
REQ5 (second part):
Furthermore,
a DMM solution SHOULD work across different networks,
possibly operated as separate administrative domains,
when allowed by the trust relationship
between them.
</t>
<t>
REQ6: DMM protocol solutions
MUST consider security aspects,
including confidentiality and integrity.
Examples of aspects to be considered are
authentication and authorization mechanisms
that allow a legitimate mobile host/router
to use the mobility support provided by the DMM solution;
signaling message protection
in terms of authentication,
encryption, etc.;
data integrity and confidentiality;
opt-in or opt-out data confidentiality
to signaling messages
depending on network environments
or user requirements.
</t>
<t>
It is preferred that these security requirements
are considered as an integral part of the DMM design.
</t>
</section>
<!-- 5.1.5 gap analysis with REQ1-1: distributed deployment -->
<section title="Distributed deployment">
<t>
The first DMM requirement has 2 parts.
The first part is on distributed deployment
whereas the second part is on avoiding longer routes.
</t>
<t>REQ1: (part 1)IP mobility, network access and routing solutions
provided by DMM
MUST enable distributed deployment
for mobility management of IP sessions
(part 2)
so that traffic
does not need to traverse centrally deployed
mobility anchors and thus
can be routed
in an optimal manner.
</t>
<t>
With the first part, multiple MRs can exist in MIPv6
by simply having an HA for each home network.
Yet it is complicated for the MN to move its HA from one network to another.
Therefore this requirement is not fully met in the best current practice.
</t>
<t>
With the second part,
one can examine dynamic mobility and route optimization
to be discussed later.
</t>
</section>
<!-- 5.1.6 gap analysis on REQ2: Transparency to Upper Layers when needed -->
<section title="Transparency to Upper Layers when needed">
<t>
To see how to avoid traversing centralized deployed mobility anchors,
let us look at the second requirement on non-optimal routes
[ID-dmm-requirements].
</t>
<t>
REQ2: DMM solutions MUST provide
transparent mobility support above the IP layer
when needed.
Such transparency is needed,
for example, when,
upon change of point of attachment to the Internet,
an application flow cannot cope with a change
in the IP address.
Otherwise, support for
maintaining a stable home IP address or prefix
during handovers may be declined.
</t>
<t>
In order to avoid traversing long routes
after the MN has moved to a new network,
the new network could simply be used
as the home network for new sessions.
</t>
<t>
Yet the capability to use different IP addresses for different IP sessions
are not in the existing mobility management functions.
This requirement is then not met in the best practice.
</t>
</section>
<!-- 5.1.7 gap analysis: route optimization -->
<section title="Route optimization">
<t>
The second part of first requirement is on route optimization.
</t>
<t>
REQ1: (part 1)IP mobility, network access and routing solutions
provided by DMM
MUST enable distributed deployment
for mobility management of IP sessions
(part 2)
so that traffic
does not need to traverse centrally deployed
mobility anchors and thus
can be routed
in an optimal manner.
</t>
<t>
Although there are existing route optimization extensions,
they generally compromise with location privacy
so that this requirement is not met.
</t>
</section>
</section>
<section title="Gap analysis summary with reconfiguration MIPv6 and PMIPv6">
<t>
The gap analyses for different protocols are summarized in this section.
</t>
<t>
Table 1. Summary of Gap Analysis
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Upper-
layer
Existing Distri- trans-
proto- IPv6 Security buted parency Route
cols Compati- deploy- consi- deploy- when Optimi-
first bility ment derations ment needed zation
MIPv6 Y Y Y Y N N N
PMIPv6 Y Y Y Y N N N
(supports (MN-AR)
above)
HMIPv6 Y Y Y Y N N N
(supports (MN-AR)
above)
Optimize Y Y Y Y N N locat-
route (supports ion pr
above) ivacy
Reconfigure Y Y Y Y Y N N
mobility (supports
functions above)
in DMM
scenario
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Gap analysis from the 3GPP LIPA/SIPTO scenario">
<t>
From the real deployment perspective,
it need to be noted that in 3GPP LIPA/SIPTO scenario,
there is no mobility support when handover between local gateways.
There is no current IP mobility protocol
can be used to solve this problem currently.
DMM may provide a solution for this scenario.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>None</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.4068" ?>
<?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.seite-dmm-dma">
<front>
<title>Distributed Mobility Anchoring</title>
<author fullname="Pierrick Seite" surname="Seite" initials="P">
<organization/> </author>
<author fullname="Philippe Bertin" surname="Bertin" initials="P">
<organization/> </author>
<date year="2012" day="16" month="July"/>
</front>
<seriesInfo value="draft-seite-dmm-dma-05" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-seite-dmm-dma-05.txt" type="TXT"/>
</reference>
<reference anchor="I-D.liebsch-mext-dmm-nat-phl">
<front>
<title>Per-Host Locators for Distributed Mobility Management</title>
<author initials="M" surname="Liebsch" fullname="M. Liebsch">
<organization>NEC</organization>
</author>
<date month="October" day="22" year="2012" />
</front>
<seriesInfo name="Internet-Draft" value="draft-liebsch-mext-dmm-nat-phl-02" />
<format type="TXT" target="http://www.ietf.org/internet-draft-liebsch-mext-dmm-nat-phl-02.txt" />
</reference>
<reference anchor="I-D.ma-dmm-armip">
<front>
<title>An AR-level solution support for Distributed Mobility Management</title>
<author fullname="Zhengming Ma" surname="Ma" initials="Z">
<organization/> </author>
<author fullname="Xun Zhang" surname="Zhang" initials="X">
<organization/> </author>
<date year="2012" day="22" month="February"/>
</front>
<seriesInfo value="draft-ma-dmm-armip-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-ma-dmm-armip-00.txt" type="TXT"/>
</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.luo-dmm-pmip-based-dmm-approach">
<front>
<title>PMIP Based DMM Approaches</title>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<author fullname="Juan Liu" surname="Liu" initials="J">
<organization/> </author>
<date year="2012" day="8" month="March"/>
</front>
<seriesInfo value="draft-luo-dmm-pmip-based-dmm-approach-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-luo-dmm-pmip-based-dmm-approach-01.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="I-D.bernardos-dmm-pmip">
<front>
<title>A PMIPv6-based solution for Distributed Mobility Management</title>
<author fullname="Carlos Bernardos" surname="Bernardos" initials="C">
<organization/> </author>
<author fullname="Antonio de la Oliva" surname="Oliva" initials="A">
<organization/> </author>
<author fullname="Fabio Giust" surname="Giust" initials="F">
<organization/> </author>
<author fullname="Telemaco Melia" surname="Melia" initials="T">
<organization/> </author>
<author fullname="Rui Costa" surname="Costa" initials="R">
<organization/> </author>
<date year="2012" day="12" month="March"/>
</front>
<seriesInfo value="draft-bernardos-dmm-pmip-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-bernardos-dmm-pmip-01.txt" type="TXT"/>
</reference>
<reference anchor="I-D.sarikaya-dmm-dmipv6">
<front>
<title>Distributed Mobile IPv6</title>
<author fullname="Behcet Sarikaya" surname="Sarikaya" initials="B">
<organization/> </author>
<date year="2012" day="1" month="February"/>
</front>
<seriesInfo value="draft-sarikaya-dmm-dmipv6-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-dmipv6-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.liu-dmm-dynamic-anchor-discussion">
<front>
<title>DMM Dynamic Anchor Discussion</title>
<author fullname="Dapeng Liu" surname="Liu" initials="D">
<organization/> </author>
<author fullname="Hui Deng" surname="Deng" initials="H">
<organization/> </author>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<date year="2012" day="4" month="March"/>
</front>
<seriesInfo value="draft-liu-dmm-dynamic-anchor-discussion-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-liu-dmm-dynamic-anchor-discussion-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.patil-dmm-issues-and-approaches2dmm">
<front>
<title>Approaches to Distributed mobility management using Mobile IPv6 and its extensions</title>
<author fullname="Basavaraj Patil" surname="Patil" initials="B">
<organization/> </author>
<author fullname="Carl Williams" surname="Williams" initials="C">
<organization/> </author>
<author fullname="Jouni Korhonen" surname="Korhonen" initials="J">
<organization/> </author>
<date year="2012" day="5" month="March"/>
</front>
<seriesInfo value="draft-patil-dmm-issues-and-approaches2dmm-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-patil-dmm-issues-and-approaches2dmm-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.xue-dmm-routing-optimization">
<front>
<title>Routing optimization in DMM</title>
<author fullname="Kaiping Xue" surname="Xue" initials="K">
<organization/> </author>
<author fullname="Lin Li" surname="Li" initials="L">
<organization/> </author>
<author fullname="Peilin Hong" surname="Hong" initials="P">
<organization/> </author>
<author fullname="Pete McCann" surname="McCann" initials="P">
<organization/> </author>
<date year="2012" day="30" month="June"/>
</front>
<seriesInfo value="draft-xue-dmm-routing-optimization-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-xue-dmm-routing-optimization-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.jikim-dmm-pmip">
<front>
<title>Use of Proxy Mobile IPv6 for Distributed Mobility Management</title> <author fullname="Ji Kim" surname="Kim" initials="J">
<organization/> </author>
<author fullname="Seok Koh" surname="Koh" initials="S">
<organization/> </author>
<author fullname="Hee Jung" surname="Jung" initials="H">
<organization/> </author>
<author fullname="Youn-Hee Han" surname="Han" initials="Y">
<organization/> </author>
<date year="2012" day="4" month="March"/>
</front>
<seriesInfo value="draft-jikim-dmm-pmip-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-jikim-dmm-pmip-00.txt" type="TXT"/>
</reference>
<reference anchor="Paper-Distributed.Dynamic.Mobility">
<front>
<title>A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date year="2008" />
</front>
<seriesInfo name="" value="Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS)" />
</reference>
<reference anchor="Paper-Net.based.DMM">
<front>
<title>A network-based localized mobility solution
for Distributed Mobility Management</title>
<author fullname="Fabio Giust" surname="Giust" initials="F">
<organization>IMDEA Networks and UC3M</organization>
</author>
<author fullname="Antonio De La Oliva" surname="de la Oliva" initials="A">
<organization>UC3M</organization>
</author>
<author fullname="Carlos J Bernardos" surname="Bernardos" initials="CJ">
<organization>UC3M</organization>
</author>
<author fullname="Rui Pedro Ferreira Da Costa" surname="Da Costa" initials="RPF">
<organization>Alcatel-Lucent Bell Labs</organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="" value="Proceedings of 14th International Symposium on Wireless Personal Multimedia Communications (WPMC)" />
</reference>
<reference anchor="Paper-Distributed.Centralized.Mobility">
<front>
<title>Distributed or Centralized Mobility?</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name="" value="Proceedings of Global Communications Conference (GlobeCom)" />
</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-Distributed.Mobility.Management">
<front>
<title>Distributed Mobility Management with Mobile IP</title>
<author initials="H" surname="Chan">
<organization />
</author>
<date month="June" year="2012" />
</front>
<seriesInfo name="" value="Proceedings of IEEE ICC 2012 Workshop on Telecommunications: from Research to Standards" />
</reference>
<reference anchor="MHA" target="">
<front>
<title>Migrating Home Agents Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa" fullname="">
<organization />
</author>
<author initials="G" surname="Valadon" fullname="">
<organization />
</author>
<author initials="J" surname="Murai" fullname="">
<organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="" value="Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies,
Lisboa, Portugal" />
</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="Paper-Host.based.DMM">
<front>
<title>Host-based Distributed Mobility Management Support Protocol for IPv6 Mobile Networks</title>
<author initials="JH" surname="Lee">
<organization />
</author>
<author initials="JM" surname="Bonnin">
<organization />
</author>
<author initials="X" surname="Lagrange">
<organization />
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="" value="Proceedings of IEEE WiMob, Barcelona, Spain" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:27:39 |