One document matched: draft-liu-dmm-deployment-scenario-02.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-liu-dmm-deployment-scenario-02">
<front>
<title abbrev="cloud mobile">Distributed mobility management
deployment scenario and architecture</title>
<author initials="D.L." surname="Liu" fullname="Dapeng Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>No.32 Xuanwumen West Street</street>
<city>Beijing 100053</city>
<country>China</country>
</postal>
<email>liudapeng@chinamobile.com</email>
</address>
</author>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3</street>
<city>Plano, TX 75024</city>
<country>USA</country>
</postal>
<email>h.a.chan@ieee.org</email>
</address>
</author>
<author initials="H." surname="Deng" fullname="Hui Deng">
<organization>China Mobile</organization>
<address>
<postal>
<street>No.32 Xuanwumen West Street</street>
<city>Beijing 100053</city>
<country>China</country>
</postal>
<email>denghui@chinamobile.com</email>
</address>
</author>
<date year="2014"/>
<area></area><workgroup></workgroup>
<abstract>
<t>
This document discusses the deployment scenario
of distributed mobility management.
The purpose of this document is to trigger the discussion in the group
to understand the DMM deployment scenario and consideration
from the operator's perspective.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Distributed mobility management
aims at solving the centralized mobility anchor problems
of the traditional mobility management protocol.
The benefit of DMM solution
is that the data plane traffic
does not need to traverse the centralized anchoring point.
This document discusses the potential deployment scenario of DMM.
The purpose of this document is to help the group to reach consensus
regarding the deployment model of DMM
and then develop the DMM solution based on the deployment model.
</t>
</section>
<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 title="Terminology">
<t>All the general mobility-related terms and their acronyms used in this document are to be interpreted
as defined in the Mobile IPv6 base specification
<xref target="RFC6275"/>,
in the Proxy mobile IPv6 specification
<xref target="RFC5213"/>,
and in Mobility Related Terminology
<xref target="RFC3753"/>.
These terms include the following:
mobile node (MN), correspondent node (CN),
and home agent (HA) as per
<xref target="RFC6275"/>;
local mobility anchor (LMA)
and mobile access gateway (MAG) as per
<xref target="RFC5213"/>,
and context as per
<xref target="RFC3753"/>.
</t>
<t>
In addition, this draft introduces the following terms.
</t>
<t>
<list style='hanging'>
<t hangText='Location information (LI) function'>
<vspace blankLines="1" />
is the logical function that manages
and keeps track of the internetwork location information of a mobile node
which may change its IP address as it moves.
The information may associate with each session identifier,
the IP routing address of the MN,
or of a node that can forward packets destined to the MN.
<vspace blankLines="1" />
</t>
<t hangText='Forwarding management (FM)'>
<vspace blankLines="1" />
is the logical function
that intercepts packets to/from the IP address/prefix
delegated to 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.
With data plane and control plane separation,
the forwarding management may be separated into
a data-plane forwarding management (FM-DP) function
and a control-plane forwarding management (FM-CP) function.
</t>
</list>
</t>
</section>
</section>
<section title="Deployment Scenario and Model of DMM">
<t>
As discussed in the DMM requirement document, the centralized
mobility management has several drawbacks. The main problem of the
centralized mobility management protocols is that all the traffic
need to anchor to a centralized anchor point. This approach does not
cause any problem in current mobile network deployment but in the
scenario that will be discussed later in this document, centralized
mobility management protocols will have many drawbacks and it is
believed that DMM is more suitable in that scenario.
</t>
<t>
The main deployment scenario discussed in this document is divided
into two types. The first one is the network function virtualization
scenario. In this scenario, the mobile core network's control plane
function is centralized in the mobile cloud. Apparently, deploying
the data plane function also in the same centralized mobile cloud is
not optimized from the traffic forwarding's perspective. Another
deployment scenario is the SIPTO/LIPA scenario which is discussed in
3GPP. In this scenario, DMM can provide optimized traffic offloading
solution.
</t>
</section>
<section title="Network Function Virtualization">
<t>
This section discusses network function virtualization scenario,
the associated control - data plane separation
and the possible mobility management functions to support this scenario.
</t>
<section title="Network Function Virtualization Scenario">
<t>
The network function virtualization scenario is shown in Figure 1.
</t>
<!--
012345678901234567890123456789012345678901234567890123456789012345678901
-->
<figure>
<artwork><![CDATA[
Mobile Cloud
...........
(' ')
( )))
((( +-----------+ )))
(( |Mobile Core| )))
((( +-----------+ )))
('..............')
|
| IP Transit Network
(.........)
( )) MN-Internet communication
( ^ ))
^ > > >( ^ ))> > > > > > > > >
^ (( ^ ) v
^ (.........^.) v
^ +-------| | ^| v
^ | | ^+--------------+ v
^ | | < < | v MN-MN communication
^ | | ^ | v
+--------------+ +--------------+ +--------------+
|Access Network| |Access Network| |Access Network|
+--------------+ +--------------+ +--------------+
^ ^ v
^ ^ v
+---------+ +---------+ +---------+
| MN | | MN | | MN |
+---------+ +---------+ +---------+
]]></artwork>
</figure>
<t>Figure 1: Network function virtualization deployment architecture</t>
<t>
In this architecture, the mobile core network is located in the cloud
/data center, which can be the operator's private cloud. The access
network is connected through an IP transit network. The mobile core
network can run in a virtualized platform in the cloud/datacenter.
</t>
</section>
<section title="Control and data plane separation">
<t>
The cloud based mobile core network architecture implies separation
of the control and data planes. The control plane is located in the
cloud and the data plane should be distributed. Otherwise, all the
data traffic will go through the cloud which is obviously not
optimized for the mobile node to mobile node communication.
</t>
<t>
For the mobile node to Internet communication, the Internet access
point is normally located in the metro IP transit network. In this
case, the mobile node to Internet traffic should also go through the
Internet access point instead of the mobile core in the cloud.
</t>
<t>
However, in some deployment scenario, the operator may choose to put
the mobile core cloud in the convergence layer of IP metro network.
In this case, the Internet access point may co-located with the
mobile core cloud. In this case, the mobile node to Internet traffic
may go through the mobile core cloud.
</t>
</section>
<section title="Mobility management architecture">
<t>
Since the control plane and data plane are separated and the data
plane is distributed, traditional mobility management cannot meet
this requirement.
</t>
<t>
Distributed mobility management or SDN based mobility management may
be used in this architecture to meet the traffic forwarding requirement
(e.g. MN to MN and MN to Internet traffic should not go through from
the mobile core cloud.).
</t>
<t>
The traditional mobility management functions
is not separating the data plane from the control plane.
Basic mobility management functions include
location information (LI) function
and Forwarding management (FM).
The former is a control plane function.
The latter can be separated into
data plane forwarding management (FM-DP)
and control plane forwarding management (FM-CP).
</t>
<t>
The data plane function is FM-DP,
while the control plane functions include FM-CP and LI.
Then the control plane functions in the cloud-based mobile core
includes LI and FM-CP.
They are of cause other functions in the control plane
such as policy function.
The distributed data plane may have multiple instances of
FM-DP
in the network.
</t>
<!--
012345678901234567890123456789012345678901234567890123456789012345678901
-->
<figure>
<artwork><![CDATA[
core network controller
+---------+
|LI, FM-CP|
+---------+
+-------+ +-------+ +-------+
| FM-DP | | FM-DP | | FM-DP |
+-------+ +-------+ +-------+
]]></artwork>
</figure>
<t>Figure 2: Mobility management functions
with data plane - control plane separation under one controller</t>
<t>
When the control of the access network is separate
from that of the core,
there will be separate controllers as shown in Figure 3.
</t>
<!--
012345678901234567890123456789012345678901234567890123456789012345678901
-->
<figure>
<artwork><![CDATA[
Access network controller Core network controller
+---------+ +---------+
|LI, FM-CP| |LI, FM-CP|
+---------+ +---------+
+-------+ +-------+ +-------+ +-------+
| FM-DP | | FM-DP | | FM-DP | | FM-DP |
+-------+ +-------+ +-------+ +-------+
]]></artwork>
</figure>
<t>Figure 2: Mobility management functions
with data plane - control plane separation
with separate control in core and in access networks.</t>
</section>
</section>
<section title="SIPTO deployment scenario">
<t>
Another deployment scenario is the SIPTO scenario which is discussed
in 3GPP. DMM is believed to be able to provide dynamic anchoring.
It allows the mobile node to have several anchoring points and to
change the anchoring point according to the application requirement.
In SIPTO scenario, the gateway function is located very
near to the access network and to the user. If using current
centralized mobility management, the traffic will need to tunnel back
to the previous anchor point even when the mobile node has changed
the point of attachment to a new one.
</t>
</section>
<section title="Conclusion">
<t>
This document discusses the deployment scenario of DMM. Two types of
deployment scenario is discussed in this document. Further types of
deployment scenario can be added to this document according to the
progress of the group's discussion.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
N/A.
</t>
</section>
<section title="IANA Considerations">
<t>
N/A.
</t>
</section>
<section title="Contributors">
</section>
<section title="Acknowledgements">
<t>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.3753" ?>
<reference anchor="IEEE-802.11.2012">
<front>
<title>
</title>
<author fullname="" surname="" initials="">
<organization/>
</author>
<date year="2012" day="29" month="March"/>
</front>
<format target="" type=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:36:27 |