draft-ietf-dmm-best-practices-gap-analysis-00.txt   draft-ietf-dmm-best-practices-gap-analysis-01.txt 
DMM D. Liu, Ed. DMM D. Liu, Ed.
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational JC. Zuniga, Ed. Intended status: Informational JC. Zuniga, Ed.
Expires: August 15, 2013 InterDigital Communications, LLC Expires: December 19, 2013 InterDigital
P. Seite P. Seite
France Telecom - Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
Universidad Carlos III de Madrid UC3M
February 11, 2013 June 17, 2013
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-00 draft-ietf-dmm-best-practices-gap-analysis-01
Abstract Abstract
This document discusses how to best deploy the current IP mobility The present document analyses deplyment practices of existing
protocols in distributed mobility management (DMM) scenarios and mobility protocols in a distributed mobility management environment.
analyzes the gaps of such best current practices against the DMM It also identifies some limitations compared to the expected
requirements. These best current practices are achieved by functionality of a fully distributed mobility management system. The
redistributing the existing MIPv6 and PMIPv6 functions in the DMM comparison is made taking into account the identified DMM
scenarios. The analyses is also applied to the real world deployment requirements.
of IP mobility in WiFi network and in cellular network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2013. This Internet-Draft will expire on December 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 4 3. Functions of existing mobility protocols . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Current IP mobility protocol analysis . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP mobility protocols and their mobility management 4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6
functions . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8
3.2. Reconfiguring existing functions in DMM scenario . . . . . 7 4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 11
4. Current practices of IP mobility protocols . . . . . . . . . . 8 4.3. 3GPP network flattening approaches . . . . . . . . . . . . 13
4.1. Fundamentals of distribution . . . . . . . . . . . . . . . 8 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Flattening the WiFi Network . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.2.1. Network-based Mobility Management . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Client-based Mobility Management . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . . 18
4.3. IP mobility protocol deployment in 3GPP network . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. 3GPP LIPA/SIPTO . . . . . . . . . . . . . . . . . . . 15
4.4. Fully distributed scenario with separation of control
and data planes . . . . . . . . . . . . . . . . . . . . . 17
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Gap analysis with reconfiguration MIPv6 and PMIPv6
functions in DMM scenario such as the flattened WiFi
network . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Considering existing protocols first . . . . . . . . . 19
5.1.2. Compatibility . . . . . . . . . . . . . . . . . . . . 19
5.1.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . 20
5.1.4. Security considerations . . . . . . . . . . . . . . . 20
5.1.5. Distributed deployment . . . . . . . . . . . . . . . . 20
5.1.6. Transparency to Upper Layers when needed . . . . . . . 21
5.1.7. Route optimization . . . . . . . . . . . . . . . . . . 21
5.2. Gap analysis summary with reconfiguration MIPv6 and
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Gap analysis from the 3GPP LIPA/SIPTO scenario . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The distributed mobility management (DMM) WG has studied the problems The distributed mobility management (DMM) WG has studied the problems
of centralized deployment of mobility management protocols and the of centralized deployment of mobility management protocols and the
requirements of DMM [ID-dmm-requirements]. In order to guide the related requirements [I-D.ietf-dmm-requirements]. In order to guide
deployment and before defining any new DMM protocol, the DMM WG is the deployment and before defining any new DMM protocol, the DMM WG
chartered to investigate first whether it is feasible to deploy is chartered to investigate first whether it is feasible to deploy
current IP mobility protocols in DMM scenario in a way that can meet current IP mobility protocols in a DMM scenario in a way that can
the requirements of DMM. This document discusses how to best deploy fullfil the requirements of DMM. This document discusses current
existing mobility protocols in DMM scenarios to solve the problems of deployment practices of existing mobility protocols in a distributed
centralized deployment. It then analyzes the gaps of such best mobility management environment and identifies the limitations in
practices against the DMM requirements. these practices with respect to the expected functionality.
The rest of this document is organized as follows:
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.
2. Conventions and Terminology
2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The rest of this document is organized as follows. Section 3
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this analyzes existing IP mobility protocols by examining their functions
document are to be interpreted as described in [RFC2119]. and how these functions can be reconfigured to work in a DMM
environment. Section 4 presents the current practices of IP flat
wireless networks and 3GPP architectures. Both network- and host-
based mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices.
2.2. Terminology 2. Terminology
All general mobility-related terms and their acronyms used in this All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy mobile IPv6 specification specification [RFC6275] and in the Proxy mobile IPv6 specification
[RFC5213]. These terms include mobile node (MN), correspondent node [RFC5213]. These terms include mobile node (MN), correspondent node
(CN), home agent (HA), local mobility anchor (LMA), and mobile access (CN), home agent (HA), local mobility anchor (LMA), and mobile access
gateway (MAG). gateway (MAG).
In addition, this document uses the following terms: In addition, this document uses the following terms:
Mobility routing (MR) is the logical function that intercepts Mobility routing (MR) is the logical function that intercepts
packets to/from the HoA of a mobile node and forwards them, based packets to/from the IP address/prefix delegated to the mobile node
on internetwork location information, either directly towards and forwards them, based on internetwork location information,
their destination or to some other network element that knows how either directly towards their destination or to some other network
to forward the packets to their ultimate destination. element that knows how to forward the packets to their ultimate
destination.
Home address allocation is the logical function that allocates the Home address allocation is the logical function that allocates the
home network prefix or home address to a mobile node. IP address/prefix (e.g., home address or home network prefix) to a
mobile node.
Location management (LM) is the logical function that manages and Location management (LM) is the logical function that manages and
keeps track of the internetwork location information of a mobile keeps track of the internetwork location information of a mobile
node, which includes the mapping of the MN HoA to the MN routing node, which includes the mapping of the IP address/prefix
address or another network element that knows where to forward delegated to the MN to the MN routing address or another network
packets destined for the MN. element that knows where to forward packets destined for the MN.
Home network of an application session (or an HoA IP address) is the Home network of an application session (or an HoA IP address) is the
network that has allocated the IP address used as the session network that has allocated the IP address used as the session
identifier (HoA) by the application being run in an MN. The MN identifier (home address) by the application being run in an MN.
may be attached to more than one home networks. The MN may be attached to more than one home networks.
3. Current IP mobility protocol analysis In the document, several references to a distributed mobility
management environment are made. By this term, we refer to an
scenario in which the IP mobility, access network and routing
solutions allow for setting up IP networks so that traffic is
distributed in an optimal way and does not rely on centrally deployed
anchors to manage IP mobility sessions.
3.1. IP mobility protocols and their mobility management functions 3. Functions of existing mobility protocols
The host-based Mobile IPv6 [RFC6275] and its network-based extension, The host-based Mobile IPv6 [RFC6275] and its network-based extension,
PMIPv6 [RFC5213], are both a logically centralized mobility PMIPv6 [RFC5213], are both logically centralized mobility management
management approach addressing primarily hierarchical mobile approaches addressing primarily hierarchical mobile networks.
networks. Although they are a centralized approach, they have Although they are centralized approaches, they have important
important mobility management functions resulting from years of mobility management functions resulting from years of extensive work
extensive work to develop and to extend these functions. It is to develop and to extend these functions. It is therefore fruitful
therefore fruitful to take these existing functions and reconfigure to take these existing functions and examine them in a DMM scenario
them in a DMM scenario in order to understand how to best deploy the in order to understand how to deploy the existing mobility protocols
existing mobility protocols in a distributed mobility management in a distributed mobility management environment.
environment.
The existing mobility management functions of MIPv6, PMIPv6, and The existing mobility management functions of MIPv6, PMIPv6, and
HMIPv6 are the following: HMIPv6 are the following:
1. Anchoring: allocation of home network prefix or HoA to an MN that 1. Anchoring function (AF): allocation to a mobile node of an IP
registers with the network; addres/prefix (e.g., a HoA or HNP) topologically anchored by the
delegating node (i.e., the anchor node is able to advertise a
connected route into the routing infrastructure for the delegated
IP prefixes).
2. Mobility Routing (MR) function: packets interception and 2. Mobility Routing (MR) function: packets interception and
forwarding to/from the HoA of the MN, based on the internetwork forwarding to/from the IP address/prefix delegated to the MN,
location information, either to the destination or to some other based on the internetwork location information, either to the
network element that knows how to forward the packets to their destination or to some other network element that knows how to
destination; forward the packets to their destination;
3. Internetwork Location Management (LM) function: managing and 3. Internetwork Location Management (LM) function: managing and
keeping track of the internetwork location of an MN, which keeping track of the internetwork location of an MN, which
includes a mapping of the HoA to the mobility anchoring point includes a mapping of the IP delegated address/prefix (e.g., HoA
that the MN is anchored to; or HNP) to the mobility anchoring point where the MN is anchored
to;
4. Location Update (LU): provisioning of MN location information to 4. Location Update (LU): provisioning of MN location information to
the LM function; the LM function;
Figure 1 shows Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213] In Mobile IPv6 [RFC6275], the home agent typically provides the
with their existing mobility management functions. In Network1, the anchoring function (AF), Mobility Routing (MR), and Internetwork
combination of the functions MR, LM and HoA allocation in network1 is Location Management (LM) functions, while the mobile node provides
the home agent in MIPv6 and is the local mobility anchor in PMIPv6. the Location Update (LU) function. Proxy Mobile IPv6 [RFC5213]
In Network3, the AR32+LU combination together with additional relies on the function of the Local Mobility Anchor (LMA) to provide
signaling with MN comprises the Mobile Access Gateway (MAG) in mobile nodes with mobility support, without requiring the involvement
PMIPv6. The mobile nodes MN11 and MN12 were originally attached to of the mobile nodes. The required functionality at the mobile node
Network1 and were allocated the IP prefixes for their respective home is provided in a proxy manner by the Mobile Access Gateway (MAG).
addresses HoA11 and HoA12. With network-based IP mobility protocols, the local mobility anchor
typically provides the anchoring function (AF), Mobility Routing
Using MIPv6, MN11 has moved to Network3, from which it is allocated a (MR), and Internetwork Location Management (LM) functions, while the
new prefix to configure the IP address IP31. LM1 maintains the mobile access gateway provides the Location Update (LU) function.
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.
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.
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
Figure 1. MIPv6, PMIPv6 and their functions.
3.2. Reconfiguring existing functions in DMM scenario
In order to best deploy current protocols in DMM scenario, the 4. DMM practices
existing mobility functions of MIPv6, PMIPv6, and HMIPv6 configured
into a DMM scenario as follows.
Network1 Network3 Network2 This section documents deployment practices of existing mobility
+-----+ +-----+ +-----+ protocols in a distributed mobility management environment. This
| LM1 | | LM3 | | LM2 | description is divided into two main families of network
+-----+ +-----+ +-----+ architectures: i) IP flat wireless networks (e.g., evolved WiFi
HoA11<-->IP31 | | hotspots) and, ii) 3GPP network flattening approaches.
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
Figure 2. Reconfiguring existing functions in DMM scenario. While describing the current DMM practices, references to the generic
mobility management functions described in Section 3 will be
provided, as well as some initial hints on the identified gaps with
respect to the DMM requirement documented in
[I-D.ietf-dmm-requirements].
Achieving the best practices by reconfiguring the existing functions 4.1. Assumptions
in this manner will be applied to the DMM scenario of a flattened
WiFi network in Section 4.2.
4. Current practices of IP mobility protocols There are many different approaches that can be considered to
implement and deploy a distributed anchoring and mobility solution.
Since this document cannot be too exhaustive, the focus is on current
mobile network architectures and standardized IP mobility solutions.
In order to limit the scope of our analysis of current DMM practices,
we consider the following list of technical assumptions:
This section covers the practices for distribution of IP mobility 1. Both host- and network-based solutions should be covered.
management. Basically, the scenario presents a way to distribute the
logical mobility functions. Gap analysis will be made on these
scenarios.
4.1. Fundamentals of distribution 2. Solution should allow selecting and using the most appropriate IP
anchor among a set of distributed ones.
There are many possibilities to implement a distributed mobility 3. Mobility management should be realized by the preservation of the
management system and this document could not be exhaustive. IP address across the different points of attachment during the
However, this document is supposed to focus on current mobility mobility (i.e., provision of IP address continuity). IP flows of
architectures and to reuse existing mobility protocol as much as applications which do not need a constant IP address should not
possible; it thus allows fixing the main technical guidelines and be handled by DMM. It is typically the role of a connection
assumptions for current practices. Then, gap analysis will analyze manager to distinguish application capabilities and trigger the
these basic solution guidelines with respect to the requirements from mobility support accordingly. Further considerations on
[ID.ietf.dmm.requirements] and pave the way for optimizations. application management are out of the scope of this document.
Technical guidelines for DMM current practices are as follows:
The technical assumptions or guidelines are: 4. Mobility management and traffic redirection should only be
1. When mobility support is required, the system will select the triggered due to IP mobility reasons, that is when the MN moves
mobility anchor closest to the MN. from the point of attachment where the IP flow was originally
2. This document focuses on mobility management realized by initiated.
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.
3. IP address preservation is ensured thanks to traffic redirection.
4. 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.
5. 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.
4.2. Flattening the WiFi Network 4.2. IP flat wireless network
The most common Wi-Fi architectures are depicted on figure 3. In This section focuses on common IP wireless network architectures and
some cases, these architectures can rely on Proxy Mobile IPv6, where how they can be flattened from an IP mobility and anchoring point of
the access aggregation gateway plays the role of LMA and the MAG is view using common and standardized protocols. Since WiFi is the most
supported either by the Residential Gateway (RG), the WLAN Controller widely deployed wireless access technology nowadays, we take it as
(WLC) or an Access Router (AR) [ID. gundavelli-v6ops-community-wifi- example in the following. Some representative examples of WiFi
svcs]. deployed architectures are depicted on Figure 1.
+--------+ _----_ +-------------+ _----_
+---+ | | _( )_ +---+ | Access | _( )_
|AAA|. . . . . . . | Access |----------( Internet ) |AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Aggreg | (_ _) +---+ | Gateway | (_ _)
| Gateway| '----' +-------------+ '----'
+--------+ | | |
| | | PMIP | | +-------------+
| | +-----|-------+
| | | | | |
PMIP | - PMIP +-----+ | | +-----+
+--------|------+ | | AR | +---------------+ | | AR |
| | +-----+ | | +--+--+
+-----+ +-----+ *---------* +-----+ +-----+ *----+----*
| RG | | WLC | ( LAN ) | RG | | WLC | ( LAN )
+-----+ +-----+ *---------* +-----+ +-----+ *---------*
. / \ / \ . / \ / \
/ \ +----+ +----+ +----+ +----+ / \ +----+ +----+ +----+ +----+
MN MN |WiFi| |WiFi| |WiFi| |WiFi| MN MN |WiFi| |WiFi| |WiFi| |WiFi|
| AP | | AP | | AP | | AP | | AP | | AP | | AP | | AP |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
. . . .
/ \ / \ / \ / \
MN MN MN MN MN MN MN MN
Figure 3. WiFi network architectures. Figure 1: IP WiFi network architectures
Because of network densification and distribution of content, it may In the figure, three typical deployment options are shown
be necessary to distribute the access aggregation gateway functions [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of
closer to the MN; see [ID.ietf-dmm-requirements] for motivation of the figure, mobile nodes directly connect to a Residential Gateway
network flattening. In an extreme distribution case, the access (RG) which is a network device that is located in the customer
aggregation gateway functions, including the mobility management premises and provides both wireless layer-2 access connectivity
functions, may all be located at the AR as shown in Figures 4 and 5, (i.e., it hosts the 802.11 Access Point function) with layer-3
respectively. These two figures depict the network- and client-based routing functions. In the middle, mobile nodes connect to WiFi
distributed mobility management scenarios. The AR is expected to Access Points (APs) that are managed by a WLAN Controller (WLC),
support the HoA allocation function. Then, depending on the mobility which performs radio resource management on the APs, system-wide
situation of the MN, the AR can run different functions: mobility policy enforcement and centralized forwarding function for
the user traffic. The WLC could also implement layer-3 routing
functions, or attach to an access router (AR). Last, on the right-
hand side of the figure, access points are directly connected to an
access router, which can also be used a generic connectivity model.
1. the AR can act as a legacy IP router; In some network architectures, such as the evolved Wi-Fi hotspot,
operators might make use of IP mobility protocols to provide mobility
support to users, for example to allow connecting the IP WiFi network
to a mobile operator core and support roaming between WLAN and 3GPP
accesses. Two main protocols can be used: Proxy Mobile IPv6
[RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role
(e.g., local mobility anchor or home agent) typically being played by
the Access Aggregation Gateway or even by an entity placed on the
mobile operator's core network.
2. the AR can provide the MR function (i.e. act as mobility anchor); Existing IP mobility protocols can also be deployed in a "flatter"
way, so the anchoring and access aggregation functions are
distributed. We next describe several practices for the deployment
of existing mobility protocols in a distributed mobility management
environment. We limit our analysis in this section to protocol
solutions based on existing IP mobility protocols, either host- or
network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile
IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these
base protocol solutions are also considered. We pay special
attention to the management of the use of care-of-addresses versus
home addresses in an efficient manner for different types of
communications. Finally, and in order to simplify the analysis, we
divide it into two parts: host- and network-based practices.
3. the AR can provide the LU functions; 4.2.1. Host-based IP DMM practices
4. the AR can provide both MR and LU functions. Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile
networks, the NEMO Basic Support protocol (hereafter, simply NEMO)
[RFC3963] are well-known host-based IP mobility protocols. They
heavily rely on the function of the Home Agent (HA), a centralized
anchor, to provide mobile nodes (hosts and routers) with mobility
support. In these approaches, the home agent typically provides the
anchoring function (AF), Mobility Routing (MR), and Internetwork
Location Management (LM) functions, while the mobile node provides
the Location Update (LU) function. We next describe some practices
on how Mobile IPv6/NEMO and several additional protocol extensions
can be deployed in a distributed mobility management environment.
For example, [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed- One approach to distribute the anchors can be to deploy several HAs
anchoring] are PMIPv6 based implementation of this scenario. (as shown in Figure 2), and assign to each MN the one closest to its
topological location [RFC4640], [RFC5026], [RFC6611]. In the example
shown in Figure 2, MN1 is assigned HA1 (and a home address anchored
by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO
specifications do not prevent the simultaneous use of multiple home
agents by a single mobile node. This deployment model could be
exploited by a mobile node to meet assumption #4 and use several
anchors at the same time, each of them anchoring IP flows initiated
at different point of attachment. However there is no mechanism
specified to enable an efficient dynamic discovery of available
anchors and the selection of the most suitable one.
4.2.1. Network-based Mobility Management <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ---->
------- -------
| CN1 | ------- | AR1 |-(o) zzzz (o)
------- | HA1 | ------- |
------- (MN1 anchored at HA1) -------
------- | MN1 |
| AR2 |-(o) -------
-------
-------
| HA2 | -------
------- | AR3 |-(o) zzzz (o)
------- |
------- (MN2 anchored at HA2) -------
| CN2 | ------- | MN2 |
------- | AR4 |-(o) -------
-------
Basic practices for distribution of network-based mobility management CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2
is depicted in Figure 4. | | | | | | | |
|<------------>|<=================+=====>| | | BT mode
| | | | | | | |
| |<----------------------------------------+----->| RO mode
| | | | | | | |
Initially, MN1 attaches to AR1, (1). According to vanilla IPv6 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO
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.
In case (2), MN1 performs a handover from AR1 to AR3 while Since one of the goals of the deployment of mobility protocols in a
maintaining ongoing IP communication with CN11. AR1 becomes the distributed mobility management environment is to avoid the
mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM suboptimal routing caused by centralized anchoring, the Route
functions for MN1. AR3 performs LU up to the LM in AR1: AR3 Optimization (RO) support provided by Mobile IPv6 can also be used to
indicates to AR1 the new location of the MN1. AR3 advertises both achieve a flatter IP data forwarding. By default, Mobile IPv6 and
HoA1 and a new IP prefix (HoA3) which is supposed to be used for new NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data
IP communication, e.g., if MN1 initiates IP communication with CN21. traffic is always encapsulated between the MN and its HA before being
Prefix HoA1 is deprecated as it is expected to be used only for directed to any other destination. The Route Optimization (RO) mode
communications anchored to AR1. AR3 shall act as a legacy IP router allows the MN to update its current location on the CNs, and then use
for MN1-CN21 communication, i.e., mobility management does not come. the direct path between them. Using the example shown in Figure 2,
MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1.
However, the RO mode has several drawbacks:
In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP o The RO mode is only supported by Mobile IPv6. There is no route
communication with CN11 and CN21. AR1 is the mobility anchor for the optimization support standardized for the NEMO protocol, although
MN1-CN11 IP communication. AR3 becomes the mobility anchor for the many different solutions have been proposed.
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.
Network1 Network1 Network3 o The RO mode requires additional signaling, which adds some
+----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+ protocol overhead.
|CN11| +-----+ |CN11| +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|LU31 | +----+
| AR1 | | AR1 | |AR3 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | | |
+----+ +----+
HoA11 HoA11,
HoA31
(1) (2)
Network2 o The signaling required to enable RO involves the home agent, and
Network1 HoA2 al it is repeated periodically because of security reasons [RFC4225].
+----+ HoA1 alc +-----+
|CN11| +-----+ | |
| |------| MR1 |-----------------|LU21 |-------+
+----+ | LM1 |-----------------|AR2 | |
| AR1 | | | |
| | Network3 +-----+ |
+-----+ HoA3 al | | +----+
+-----+ | | |MN1 |
+----+ |MR3 |------ | | |
|CN21| |LM3 |-------- +----+
| |------| | HoA11,
+----+ |AR3 | HoA31
+-----+ (3)
Figure 4. Network-based DMM architecture for a flat network. This basically means that the HA remains as single point of
failure, because the Mobile IPv6 RO mode does not mean HA-less
operation.
4.2.2. Client-based Mobility Management o The RO mode requires additional support on the correspondent node
(CN).
Basic practices for distribution of client-based mobility management Notwithstanding these considerations, the RO mode does offer the
is depicted in Figure 5. Here, client-based mobility management does possibility of substantially reducing traffic through the Home Agent,
not necessary implies Mobile IP because, according to distribution in cases when it can be supported on the relevant correspondent
fundamentals (section 4.1), current practices rely on principles nodes.
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].
In case (1), MN1 attaches to AR1. AR advertises the prefix HoA1 to <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
MN1 then acts as a legacy IP router. MN1 initiates a communication -----
with CN11. /|AR1|-(o) zz (o)
-------- / ----- |
| MAP1 |< -------
-------- \ ----- | MN1 |
------- \|AR2| -------
| CN1 | ----- HoA anchored
------- ----- at HA1
------- /|AR3| RCoA anchored
| HA1 | -------- / ----- at MAP1
------- | MAP2 |< LCoA anchored
-------- \ ----- at AR1
\|AR4|
------- -----
| CN2 | -----
------- /|AR5|
-------- / -----
| MAP3 |<
-------- \ -----
\|AR6|
-----
In case (2), MN1 performs a handover from AR1 to AR3 with ongoing IP CN1 CN2 HA1 MAP1 AR1 MN1
communication with CN11. AR1 becomes the mobility anchor for the | | | | ________|__________ |
MN1-CN11 IP communication: AR1 runs MR and LM functions for MN1. The |<------------------>|<==============>|<________+__________>| HoA
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 | |<-------------------------->|<===================>| RCoA
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.
Network1 Network1 Network3 Figure 3: Hierarchical Mobile IPv6
+----+ HoA1 alc +----+ HoA1 alc +----+
|CN11| +-----+ |CN | +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|pLU31| +----+
| AR1 | | AR1 | |AR31 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | |LU31|
+----+ +----+
HoA11 HoA11,
IP31
(1) (2) Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] is another host-based IP
mobility extension that can be considered as a complement to provide
a less centralized mobility deployment. It allows reducing the
amount of mobility signaling as well as improving the overall
handover performance of Mobile IPv6 by introducing a new hierarchy
level to handle local mobility. The Mobility Anchor Point (MAP)
entity is introduced as a local mobility handling node deployed
closer to the mobile node.
Figure 5. Client-based DMM architecture for a flat network. When HMIPv6 is used, the MN has two different temporal addresses: the
Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA).
The RCoA is anchored at one MAP, that plays the role of local home
agent, while the LCoA is anchored at the access router level. The
mobile node uses the RCoA as the CoA signaled to its home agent.
Therefore, while roaming within a local domain handled by the same
MAP, the mobile node does not need to update its home agent (i.e.,
the mobile node does not change RCoA).
4.3. IP mobility protocol deployment in 3GPP network The use of HMIPv6 allows some route optimization, as a mobile node
may decide to directly use the RCoA as source address for a
communication with a given correspondent node, notably if the MN does
not expect to move outside the local domain during the lifetime of
the communication. This can be seen as a potential DMM mode of
operation. In the example shown in Figure 3, MN1 is using its global
HoA to communicate with CN1, while it is using its RCoA to
communicate with CN2.
Additionally, a local domain might have several MAPs deployed,
enabling hence different kind of HMIPv6 deployments (e.g., flat and
distributed). The HMIPv6 specification supports a flexible selection
of the MAP (e.g., based on the distance between the MN and the MAP,
taking into consideration the expected mobility pattern of the MN,
etc.).
An additional extension that can be used to help deploying a mobility
protocol in a distributed mobility management environment is the the
Home Agent switch specification [RFC5142], which defines a new
mobility header for signaling a mobile node that it should acquire a
new home agent. Even though the purposes of this specification do
not include the case of changing the mobile node's home address, as
that might imply loss of connectivity for ongoing persistent
connections, it could be used to force the change of home agent in
those situations where there are no active persistent data sessions
that cannot cope with a change of home address.
4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6 ([RFC5844] defines some IPv4
extensions). Architecturally, PMIPv6 is similar to MIPv6, as it
relies on the function of the Local Mobility Anchor (LMA) to provide
mobile nodes with mobility support, without requiring the involvement
of the mobile nodes. The required functionality at the mobile node
is provided in a proxy manner by the Mobile Access Gateway (MAG).
With network-based IP mobility protocols, the local mobility anchor
typically provides the anchoring function (AF), Mobility Routing
(MR), and Internetwork Location Management (LM) functions, while the
mobile access gateway provides the Location Update (LU) function. We
next describe some practices on how network-based mobility protocols
and several additional protocol extensions can be deployed in a
distributed mobility management environment.
<- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------>
-------
| CN1 | -------- -------- --------
------- -------- | MAG1 | | MAG2 | | MAG3 |
| LMA1 | ---+---- ---+---- ---+----
------- -------- | | |
| CN2 | (o) (o) (o)
------- -------- x x
| LMA2 | x x
------- -------- (o) (o)
| CN3 | | |
------- ---+--- ---+---
Anchored | MN1 | Anchored | MN2 |
at LMA1 -> ------- at LMA2 -> -------
CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2
| | | | | | | |
|<------------>|<================>|<---->| | |
| | | | | | | |
| |<------------>|<========================>|<----->|
| | | | | | | |
Figure 4: Distributed operation of Proxy Mobile IPv6
As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be
easily decentralized, as in this case there also exists a single
network anchor point. One simple but still suboptimal approach, can
be to deploy several local mobility anchors and use some selection
criteria to assign LMAs to attaching mobile nodes (an example of this
type of assignment is shown in Figure 4). As per the client based
approach, a mobile node may use several anchors at the same time,
each of them anchoring IP flows initiated at different point of
attachment. This assignment can be static or dynamic (as described
later in this document). The main advantage of this simple approach
is that the IP address anchor (i.e., the LMA) could be placed closer
to the mobile node, and therefore resulting paths are close-to-
optimal. On the other hand, as soon as the mobile node moves, the
resulting path would start to deviate from the optimal one.
As for host-based IP mobility, there are some extensions defined to
mitigate the sub-optimal routing issues that might arise due to the
use of a centralized anchor. The Local Routing extensions [RFC6705]
enable optimal routing in Proxy Mobile IPv6 in three cases: i) when
two communicating MNs are attached to the same MAG and LMA, ii) when
two communicating MNs are attached to different MAGs but to the same
LMA, and iii) when two communicating MNs are attached to the same MAG
but have different LMAs. In these three cases, data traffic between
the two mobile nodes does not traverse the LMA(s), thus providing
some form of path optimization since the traffic is locally routed at
the edge. The main disadvantage of this approach is that it only
tackles the MN-to-MN communication scenario, and only under certain
circumstances.
An interesting extension that can also be used to facilitate the
deployment of network-based mobility protocols in a distributes
mobility management environment is the LMA runtime assignment
[RFC6463]. This extension specifies a runtime local mobility anchor
assignment functionality and corresponding mobility options for Proxy
Mobile IPv6. This runtime local mobility anchor assignment takes
place during the Proxy Binding Update / Proxy Binding Acknowledgment
message exchange between a mobile access gateway and a local mobility
anchor. While this mechanism is mainly aimed for load-balancing
purposes, it can also be used to select an optimal LMA from the
routing point of view. A runtime LMA assignment can be used to
change the assigned LMA of an MN, for example in case when the mobile
node does not have any session active, or when running sessions can
survive an IP address change.
4.3. 3GPP network flattening approaches
The 3rd Generation Partnership Project (3GPP) is the standard The 3rd Generation Partnership Project (3GPP) is the standard
development organization that specifies the 3rd generation mobile development organization that specifies the 3rd generation mobile
network and LTE (Long Term Evolution). By November 2, 2012, there network and LTE (Long Term Evolution).
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.
The 3GPP SAE network architecture is visualized in the Figure 6:
+----+ Architecturally, the 3GPP Evolved Packet Core (EPC) network is
.....................................| | similar to an IP wireless network running PMIPv6 or MIPv6, as it
. |HSS | relies on the Packet Data Gateway (PGW) anchoring services to provide
. ............................| | mobile nodes with mobility support (see Figure 5). There are client-
. . +----+ based and network-based mobility solutions in 3GPP, which for
. . +----+ simplicity we will analyze together. We next describe how 3GPP
. . ........................| | mobility protocols and several additional completed or on-going
. . . |PCRF|......... extensions can be deployed to meet some of the DMM requirements
. . . .......| | . [I-D.ietf-dmm-requirements].
. . . . +----+ .
+---------+ +-------+ +----------+ ^ ^ ^ ^ ^
|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 | .
| |.....................................
+---------+
Figure 6. 3GPP SAE architecture. +---------------------------------------------------------+
| PCRF |
+-----------+--------------------------+----------------+-+
| | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
| | | +------+ |N| +-+-+ | | | | | | | x |
| | | +-+ /|MME| | | +---+----+ | | | | t |
| | | +---------+ / +---+ | | | 3GPP | | | | | e |
| +-----+ E-UTRAN |/ | | | AAA | | | | | r |
| | | +---------+\ | | | SERVER | | | | | n |
| | | \ +---+ | | +--------+ | | | | a |
| | | 3GPP AN \|SGW+----- S5---------------+ P | | | l |
| | | +---+ | | | G | | | |
| | +------------------------+ | | W | | | I |
| UE | | | | | | P |
| | +------------------------+ | | +-----+ |
| | |+-------------+ +------+| | | | | | n |
| | || Untrusted +-+ ePDG +-S2b---------------+ | | | e |
| +---+| non-3GPP AN | +------+| | | | | | t |
| | |+-------------+ | | | | | | w |
| | +------------------------+ | | | | | o |
| | | | | | | r |
| | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | |
| | | +-+-+ | | |
| +--------------------------S2c--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
In SAE architecture, there are two types of non-3GPP access network: Figure 5: EPS (non-roaming) architecture overview
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:
In 3GPP SAE architecture, there are three interfaces that use IP GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based
mobility protocol: mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8
1. S2a Interface: S2a is the interface between trusted non-3GPP interfaces). Similar to PMIPv6, it can handle mobility without
access network and the EPC. This interface could be based on GTP requiring the involvement of the mobile nodes. In this case, the
or PMIP. When using PMIP, the PDN gateway in the EPC will mobile node functionality is provided in a proxy manner by the
function as LMA. The mobile station will anchor at this LMA/ Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or
PDN-Gateway entity. The mobile station will maintain the session Trusted Wireless Access Gateway (TWAG).
continuity when handover between the non-3GPP access network and
3GPP network.
2. 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.
3. 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.
4.3.1. 3GPP LIPA/SIPTO 3GPP specifications also include client-based mobility support, based
on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
the S2c interface. In this case, the UE implements the mobile node
functionality, while the home agent role is played by the PGW.
Another scenario that uses IP mobility protocol in 3GPP currently is A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
the LIPA/SIPTO scenario. LIPA stands for Local IP Access. The enabled network [3GPP.23.829] allows offloading some IP services at
following figure shows the LIPA scenario. the local access network, above the Radio Access Network (RAN) or at
the macro, without the need to traverse back to the PGW (see
Figure 6.
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
|Mobile |....................................(Operator's CN) | User |....................................(Operator's CN)
|Station |.................. | Equipm. |..................
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
|Residential| |Residential|
|enterprise | |enterprise |
|IP network | |IP network |
+-----------+ +-----------+
Figure 7. LIPA scenario. Figure 6: LIPA scenario
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.
+---------------+-------+ +----------+ +-------------+
|Residential | |H(e)NB | | Backhaul | |Mobile |
|Enterprise |..|-------|..| |..|Operator |..(IP Network)
|Network | |L-GW | | | |Core network |
+---------------+-------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
Figure 8. LIPA architecture.
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.
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.
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.
In both LIPA and SIPTO architecture, the local gateway functions as SIPTO enables an operator to offload certain types of traffic at a
the anchor point for the local traffic. network node close to the UE's point of attachment to the access
network, by selecting a set of GWs (SGW and PGW) that is
geographically/topologically close to the UE's point of attachment.
SIPTO Traffic SIPTO Traffic
| |
. .
. .
+------+ +------+ +------+ +------+
|L-PGW | ---- | MME | |L-PGW | ---- | MME |
+------+ / +------+ +------+ / +------+
| / | /
+-------+ +------+ +------+/ +------+ +-------+ +------+ +------+/ +------+
| UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic | UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
Figure 9. SIPTO architecture. Figure 7: SIPTO architecture
4.4. Fully distributed scenario with separation of control and data
planes
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.
Network1 Network3 Network2 LIPA, on the other hand, enables an IP capable UE connected via a
+-----+ +-----+ +-----+ Home eNB (HeNB) to access other IP capable entities in the same
| LM1 | | LM3 | | LM2 | residential/enterprise IP network without the user plane traversing
+-----+ +-----+ +-----+ the mobile operator's network core. In order to achieve this, a
HoA1 alc HoA3 alc HoA2 alc Local GW (L-GW) collocated with the HeNB is used. LIPA is
| \ \ / | \ / / | established by the UE requesting a new PDN connection to an access
| \ \ / | \ / / | point name for which LIPA is permitted, and the network selecting the
| \ \/ | \/ / | Local GW associated with the HeNB and enabling a direct user plane
| \ / \ | / \ / | path between the Local GW and the HeNB.
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 |------| MR3 |------| MR2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. |+LU | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
Figure 10. A distributed architecture for mobility management. +---------------+-------+ +----------+ +-------------+ =====
|Residential | |H(e)NB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|-------|..| |..|Operator |..(Network)
|Network | |L-GW | | | |Core network | =======
+---------------+-------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
To perform mobility routing, the MRs need the location information Figure 8: LIPA architecture
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.
This figure shows three MRs (MR1, MR2, and MR3) in three networks. Both SIPTO and LIPA have a very limited mobility support, specially
MN11 has moved from the first network supported by MR1 and LM1 to the in 3GPP specifications up to Rel-10. In Rel-11, there is currently a
third network supported by MR3 and LM3. It may use an HoA (HoA11) work item on LIPA Mobility and SIPTO at the Local Network (LIMONET)
allocated to it when it was in the first network for those [3GPP.23.859] that is studying how to provide SIPTO and LIPA
application sessions that had already started when MN11 was attached mechanisms with some additional, but still limited, mobility support.
there and that require session continuity after the handover to the In a glimpse, LIPA mobility support is limited to handovers between
third network. When MN11 was in the first network, no location HeNBs that are managed by the same L-GW (i.e., mobility within the
management is needed so that LM1 will not keep an entry of HoA11. local domain), while seamless SIPTO mobility is still limited to the
After MN11 has performed its handover to the third network, the case where the SGW/PGW is at or above Radio Access Network (RAN)
database server LM1 maintains a mapping of HoA11 to MR3. That is, level.
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.
5. Gap analysis 5. Gap analysis
5.1. Gap analysis with reconfiguration MIPv6 and PMIPv6 functions in The goal of this section is to identify the limitations in the
DMM scenario such as the flattened WiFi network current practices with respect to providing the expected DMM
functionality.
5.1.1. Considering existing protocols first
The fourth DMM requirement is on existing mobility protocols [ID-dmm-
requirements:
REQ4: A DMM solution SHOULD first consider reusing and extending
IETF-standardized protocols before specifying new protocols.
The best current practice is using the existing mobility management
functions of the current protocols.
5.1.2. Compatibility
The first part of the fifth DMM requirement is on compatibility:
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.
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.
5.1.3. IPv6 deployment
The third DMM requirement on IPv6 deployment is the following.
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.
This is not an issue when using the mobility management functions of
MIPv6 and PMIPv6 which are originally designed for IPv6.
5.1.4. Security considerations
The second part of the fourth requirement as well as the sixth DMM
requirement [ID-dmm-requirements] are as follows:
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.
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.
It is preferred that these security requirements are considered as an
integral part of the DMM design.
5.1.5. Distributed deployment
The first DMM requirement has 2 parts. The first part is on
distributed deployment whereas the second part is on avoiding longer
routes.
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.
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.
With the second part, one can examine dynamic mobility and route
optimization to be discussed later.
5.1.6. Transparency to Upper Layers when needed
To see how to avoid traversing centralized deployed mobility anchors,
let us look at the second requirement on non-optimal routes [ID-dmm-
requirements].
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.
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.
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.
5.1.7. Route optimization
The second part of first requirement is on route optimization.
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.
Although there are existing route optimization extensions, they From the analysis performed in Section 4, we can first identify a
generally compromise with location privacy so that this requirement basic set of functions that a DMM solution needs to provide:
is not met.
5.2. Gap analysis summary with reconfiguration MIPv6 and PMIPv6 o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order
to make this feature "DMM-friendly", some anchors might need to be
placed closer to the mobile node.
The gap analyses for different protocols are summarized in this o Dynamic anchor assignment/re-location: ability to i) optimally
section. assign initial anchor, and ii) dynamically change the initially
assigned anchor and/or assign a new one (this may also require to
transfer mobility context between anchors). This can be achieved
either by changing anchor for all ongoing sessions, or by
assigning new anchors just for new sessions.
Table 1. Summary of Gap Analysis o Multiple IP address management: ability of the mobile node to
simultaneously use multiple IP addresses and select the best one
(from an anchoring point of view) to use on a per-session/
application/service basis. Depending on the mobile node support,
this functionality might require more or less support from the
network side. This is typically the role of a connection manager.
Upper- In order to summarize the previously listed functions, Figure 9 shows
layer an example of a conceptual DMM solution deployment.
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 ( )
+------------------------------------------------+
/ | \
/ * Internet | x Internet \ Internet
/ * / access | x / access \ / access
/ * / (IP a) | x / (IP b) \ /
--+------+----- ----+-----+---- ------+---+----
| distributed | * * *| distributed | | distributed |
| anchor 1 | | anchor i | | anchor n |
---+----------- ---+----------- ---+-----------
| | |
(o) (o) (o)
session X * x session Y
anchored * x anchored
at 1 * x at i
(IP a) (o) (IP b)
|
+--+--+
| MN1 |
+-----+
PMIPv6 Y Y Y Y N N N Figure 9: DMM functions
(supports (MN-AR)
above)
HMIPv6 Y Y Y Y N N N Based on the analysis performed in Section 4, the following list of
(supports (MN-AR) gaps can be identified:
above)
Optimize Y Y Y Y N N locat- o Both the main client- and network-based IP mobility protocols,
route (supports ion pr namely (DS)MIPv6 and PMIPv6 allows to deploy multiple anchors
above) ivacy (i.e., home agents and localized mobility anchors), therefore
providing the multiple anchoring function. However, existing
solutions do only provide an optimal initial anchor assignment, a
gap being the lack of dynamic anchor change/new anchor assignment.
Neither the HA switch nor the LMA runtime assignment allow
changing the anchor during an ongoing session. This actually
comprises several gaps: ability to perform anchor assignment at
any time (not only at the initial MN's attachment), ability of the
current anchor to initiate/trigger the relocation, and ability of
transferring registration context between anchors.
Reconfigure Y Y Y Y Y N N o The dynamic anchor relocation needs to ensure that IP address
mobility (supports continuity is guaranteed for sessions that need it at the
functions above) relocated anchor. This for example implies having the knowledge
in DMM of which sessions are active at the mobile node, which is
scenario something typically known only by the MN (namely, by its
connection manager). Therefore, (part of) this knowledge might
need to be transferred to/shared with the network.
5.3. Gap analysis from the 3GPP LIPA/SIPTO scenario o Dynamic discovery and selection of anchors. There might be more
than one available anchor for a mobile node to use. Currently,
there is no efficient mechanism that allows to dynamically
discover the presence of nodes that can play the role of anchor,
discover their capabilities and allow the selection of the most
suitable one.
From the real deployment perspective, it need to be noted that in o NOTE: This section is in progress. More gaps are still to be
3GPP LIPA/SIPTO scenario, there is no mobility support when handover identified and more text added to these bullets (perhaps even
between local gateways. There is no current IP mobility protocol can assigning one subsection to each one). More discussion/feedback
be used to solve this problem currently. DMM may provide a solution from the group is still needed.
for this scenario.
6. Security Considerations 6. Security Considerations
TBD TBD.
7. IANA Considerations 7. IANA Considerations
None None.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-01
(work in progress), September 2012.
[I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., Giust, F., Melia, T., and R.
Costa, "A PMIPv6-based solution for Distributed Mobility
Management", draft-bernardos-dmm-pmip-01 (work in
progress), March 2012.
[I-D.jikim-dmm-pmip]
Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy
Mobile IPv6 for Distributed Mobility Management",
draft-jikim-dmm-pmip-00 (work in progress), March 2012.
[I-D.liebsch-mext-dmm-nat-phl]
Liebsch, M., "Per-Host Locators for Distributed Mobility
Management", draft-liebsch-mext-dmm-nat-phl-02 (work in
progress), October 2012.
[I-D.liu-dmm-dynamic-anchor-discussion]
Liu, D., Deng, H., and W. Luo, "DMM Dynamic Anchor
Discussion", draft-liu-dmm-dynamic-anchor-discussion-00
(work in progress), March 2012.
[I-D.liu-dmm-pmip-based-approach]
Liu, D., Song, J., and W. Luo, "PMIP Based DMM
Approaches", draft-liu-dmm-pmip-based-approach-02 (work in
progress), March 2012.
[I-D.luo-dmm-pmip-based-dmm-approach]
Luo, W. and J. Liu, "PMIP Based DMM Approaches",
draft-luo-dmm-pmip-based-dmm-approach-01 (work in
progress), March 2012.
[I-D.ma-dmm-armip]
Ma, Z. and X. Zhang, "An AR-level solution support for
Distributed Mobility Management", draft-ma-dmm-armip-00
(work in progress), February 2012.
[I-D.patil-dmm-issues-and-approaches2dmm]
Patil, B., Williams, C., and J. Korhonen, "Approaches to
Distributed mobility management using Mobile IPv6 and its
extensions", draft-patil-dmm-issues-and-approaches2dmm-00
(work in progress), March 2012.
[I-D.sarikaya-dmm-dmipv6]
Sarikaya, B., "Distributed Mobile IPv6",
draft-sarikaya-dmm-dmipv6-00 (work in progress),
February 2012.
[I-D.seite-dmm-dma]
Seite, P. and P. Bertin, "Distributed Mobility Anchoring",
draft-seite-dmm-dma-05 (work in progress), July 2012.
[I-D.xue-dmm-routing-optimization]
Xue, K., Li, L., Hong, P., and P. McCann, "Routing
optimization in DMM",
draft-xue-dmm-routing-optimization-00 (work in progress),
June 2012.
[I-D.yokota-dmm-scenario]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management",
draft-yokota-dmm-scenario-00 (work in progress),
October 2010.
[MHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
Agents Towards Internet-scale Mobility Deployments",
Proceedings of the ACM 2nd CoNEXT Conference on Future
Networking Technologies, Lisboa, Portugal, December 2006.
[Paper-Distributed.Centralized.Mobility] 8. Informative References
Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or
Centralized Mobility?", Proceedings of Global
Communications Conference (GlobeCom), December 2009.
[Paper-Distributed.Dynamic.Mobility] [3GPP.23.829]
Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 3GPP, "Local IP Access and Selected IP Traffic Offload
Dynamic Mobility Management Scheme Designed for Flat IP (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011.
Architectures", Proceedings of 3rd International
Conference on New Technologies, Mobility and Security
(NTMS), 2008.
[Paper-Distributed.Mobility.Management] [3GPP.23.859]
Chan, H., "Distributed Mobility Management with Mobile 3GPP, "Local IP access (LIPA) mobility and Selected IP
IP", Proceedings of IEEE ICC 2012 Workshop on Traffic Offload (SIPTO) at the local network", 3GPP
Telecommunications: from Research to Standards, June 2012. TR 23.859 12.0.1, April 2013.
[Paper-Distributed.Mobility.PMIP] [3GPP.29.060]
Chan, H., "Proxy Mobile IP with Distributed Mobility 3GPP, "General Packet Radio Service (GPRS); GPRS
Anchors", Proceedings of GlobeCom Workshop on Seamless Tunnelling Protocol (GTP) across the Gn and Gp interface",
Wireless Mobility, December 2010. 3GPP TS 29.060 3.19.0, March 2004.
[Paper-Distributed.Mobility.Review] [I-D.gundavelli-v6ops-community-wifi-svcs]
Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, Gundavelli, S., Grayson, M., Seite, P., and Y. Lee,
"Distributed and Dynamic Mobility Management in Mobile "Service Provider Wi-Fi Services Over Residential
Internet: Current Approaches and Issues", February 2011. Architectures",
draft-gundavelli-v6ops-community-wifi-svcs-06 (work in
progress), April 2013.
[Paper-Host.based.DMM] [I-D.ietf-dmm-requirements]
Lee, JH., Bonnin, JM., and X. Lagrange, "Host-based Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
Distributed Mobility Management Support Protocol for IPv6 "Requirements for Distributed Mobility Management",
Mobile Networks", Proceedings of IEEE WiMob, Barcelona, draft-ietf-dmm-requirements-05 (work in progress),
Spain, October 2012. June 2013.
[Paper-Migrating.Home.Agents] [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Thubert, "Network Mobility (NEMO) Basic Support Protocol",
Agents Towards Internet-scale Mobility Deployments", RFC 3963, January 2005.
Proceedings of the ACM 2nd CoNEXT Conference on Future
Networking Technologies, December 2006.
[Paper-Net.based.DMM] [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Giust, F., de la Oliva, A., Bernardos, CJ., and RPF. Da Nordmark, "Mobile IP Version 6 Route Optimization Security
Costa, "A network-based localized mobility solution for Design Background", RFC 4225, December 2005.
Distributed Mobility Management", Proceedings of 14th
International Symposium on Wireless Personal Multimedia
Communications (WPMC), October 2011.
[Paper-SMGI] [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
the Global Internet", Proceedings of ACM Workshop on September 2006.
MICNET, MobiCom 2009, Beijing, China, September 2009.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
July 2005. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
RFC 4988, October 2007. "Mobility Header Home Agent Switch Message", RFC 5142,
January 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, Routers", RFC 5555, June 2009.
September 2010.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6)
Bootstrapping for the Integrated Scenario", RFC 6611,
May 2012.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6",
RFC 6705, September 2012.
Authors' Addresses Authors' Addresses
Dapeng Liu (editor) Dapeng Liu (editor)
China Mobile China Mobile
Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China Unit2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com Email: liudapeng@chinamobile.com
Juan Carlos Zuniga (editor) Juan Carlos Zuniga (editor)
InterDigital Communications, LLC InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 1000 Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4
Canada
Email: JuanCarlos.Zuniga@InterDigital.com Email: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/
Pierrick Seite Pierrick Seite
France Telecom - Orange Orange
4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 4, rue du Clos Courtel, BP 91226
Email: pierrick.seite@orange.com Cesson-Sevigne 35512
France
Email: pierrick.seite@orange.com
H Anthony Chan H Anthony Chan
Huawei Technologies Huawei Technologies
5340 Legacy Dr. Building 3, Plano, TX 75024, USA 5340 Legacy Dr. Building 3
Plano, TX 75024
USA
Email: h.a.chan@ieee.org Email: h.a.chan@ieee.org
CJ. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Leganes, Madrid 28911 Spain Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
 End of changes. 109 change blocks. 
875 lines changed or deleted 668 lines changed or added

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