Subject: [dmm] DMM problem statement and scenario draft

From: liu dapeng <[email-masked]>
Date: Tue, 19 Oct 2010 16:12:30 +0800

Hello all,

After several weeks and many contributor's hard working, we finished
DMM problem statement and scenario draft:

http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00
http://tools.ietf.org/html/draft-yokota-dmm-scenario-00

Besides, we have the following introduction and initial work plan of DMM:

-----------------------------------------------------------------------------------------------------
Work plan proposal -- Distributed and Dynamic Mobility Management
==================================================

In the past decade a fair number of mobility protocols have been
standardized. Although the protocols differ in terms of functions and
associated message format, we can identify a few key common features:
•presence of a centralized mobility anchor providing global
reachability and an always-on experience
•extensions to optimize handover performance while users roam across
wireless cells
•extensions to enable the use of heterogeneous wireless interfaces for
multi-mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device
to be reachable when it is not connected to its home domain. The
anchor, among other tasks, ensures forwarding of packets destined to
or sent from the mobile device. As such, most of the deployed
architectures today have a small number of centralized anchors
managing the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, the base protocols have been
extended to efficiently handle packet forwarding between the previous
and new points of attachment. These extensions are necessary when
applications impose stringent requirements in terms of delay. Notions
of localization and distribution of local agents have been introduced
to reduce signalling overhead. Unfortunately today we witness
difficulties in getting such protocols deployed, often leading to
sub-optimal choices. Moreover, all the availability of multi-mode
devices and the possibility to use several network interfaces
simultaneously have motivated the development of more new protocol
extensions.

Mobile users are, more than ever, consuming Internet content, and
impose new requirements on mobile core networks for data traffic
delivery. When this traffic demand exceeds available capacity, service
providers need to implement new strategies such as selective traffic
offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access
networks (e.g. WLAN). Moreover, the localization of content providers
closer to the Mobile/Fixed Internet Service Providers network requires
taking into account local Content Delivery Networks (CDNs) while
providing mobility services.

As long as demand exceeds capactity, both offloading and CDN
techniques could benefit from the development of more flat mobile
architectures (i.e., fewer levels of routing hierarchy introduced into
the data path by the mobility management system). This view is
reinforced by the shift in users’ traffic behaviour, aimed at
increasing direct communications among peers in the same geographical
area. The development of truly flat mobile architectures would result
in anchoring the traffic closer to point of attachment of the user and
overcoming the suboptimal routing issues of a centralized mobility
scheme.

While deploying [1] today’s mobile networks, service providers face
new challenges. More often than not, mobile devices remain attached to
the same point of attachment, in which case specific IP mobility
management support is not required for applications that launch and
complete while connected to the same point of attachment. However, the
mobility support has been designed to be always on and to maintain the
context for each mobile subscriber as long as they are connected to
the network. This can result in a waste of resources and
ever-increasing costs for the service provider. Infrequent mobility
and intelligence of many applications suggest that mobility can be
provided dynamically, thus simplifying the context maintained in the
different nodes of the mobile network.

The proposed charter will address two complementary aspects of
mobility management procedures: the distribution of mobility anchors
to achieve a more flat design and the dynamic activation/deactivation
of mobility protocol support as an enabler to distributed mobility
management. The former has the goal of positioning mobility anchors
(HA, LMA) closer to the user; ideally, these mobility anchors could be
collocated with the first hop router. The latter, facilitated by the
distribution of mobility anchors, aims at identifying when mobility
must be activated and identifying sessions that do not impose mobility
management -- thus reducing the amount of state information to be
maintained in the various mobility anchors of the mobile network. The
key idea is that dynamic mobility management relaxes some constraints
while also repositioning mobility anchors; it avoids the establishment
of non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:
•Define the problem statement and associated requirements for
distributed mobility management. This work aims at defining the
problem space and identifies the key functional requirements.
•Produce a gap analysis mapping the above requirements against
existing solutions.
•Give best practices for the deployment of existing mobility protocols
in a distributed mobility management and describe limitations of each
such approach.
•Describe extensions, if needed, to current mobility protocols for
their application in distributed mobility architectures

[1] G. Kirby, "Locating the User", Communication International, 1995
----------------------------------------------------------------------------------------------------

Please feel free to comment. Thanks.

Best Regards,
Dapeng Liu

---

From: "Seok Joo Koh" <[email-masked]>
Date: Thu, 28 Oct 2010 08:53:10 +0900

Thanks for sincere efforts.

It seems that the initial drafts and the proposed WG charter will be a good triggering point toward 
DMM.
The stepwise approach for design of DMM are also reasonable.

Some comments are:
1) The design of DMM needs to be done in the viewpoint of (generic) Functiona Architecture,
rather than based on specific protocols (MIP, PMIP), since  DMM may be used in the future
emerging networks (not identified yet) as well as in the current MIP/PMIP networks.

2) At present, the main target network to DMM may be the LTE/SAE or 4G mobile networks.
In the drafts, it is very helpful to describe the associated requirements and applicability 
statements.

Hope to have useful discussion and decision in the upcoming IETF meeting.

Regards,

*************************
Seok Joo Koh
[email-masked]
http://protocol.knu.ac.kr/

----- Original Message ----- 
From: "liu dapeng" <[email-masked]>
To: "dmm" <[email-masked]>
Cc: "charles.perkins" <[email-masked]>; "caozhen" <[email-masked]>; "MELIA 
TELEMACO" <[email-masked]>; "Wassim Haddad" <[email-masked]>; 
"denghui02" <[email-masked]>
Sent: Tuesday, October 19, 2010 5:12 PM
Subject: [dmm] DMM problem statement and scenario draft

Hello all,

Best Regards,
Dapeng Liu
_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: [email-masked]
Date: Thu, 28 Oct 2010 14:15:10 +0800

Hi, All
 
We have read the posted DMM draft and scenario drat, it is interesting. 
We'd like to support this work since we have the same vision on the next 
generation of mobility management . We also write a PS draft, here are 
some text from that document, we hope it could be helpful:
 
Analysis of existing mobility solutions

MIPv6 and PMIPv6 are typical mobility management solutions, presenting 
host based and network based solutions respectively.

MIPv6
There are some problems in MIPv6, even though it has the solution 
supporting routing optimization.

1) MIPv6 can not be supported by legacy terminals
It is difficult for the operators to control the terminals' upgrading. So 
the MIPv6-based solution is hard to be promoted and deployed.

2) Routing optimization needs supporting by the communication peers
MIPv6 is independent of the fixed terminals, and is not mandated for the 
3GPP mobile UE. These terminals occupy more than 90 percent in all 
terminals. So the routing optimization solutions can not be applied in the 
most scenarios.

3) Terminal load maybe burst during the handover when P2MP application is 
active.
During a P2MP application, e.g. conference call, or download application 
using P2P,  the terminal is always in heavy load. When handover occurs, 
the route optimization procedure leads to a burst load, and cause service 
interruption or signaling processing block.

PMIPv6
In the case of PMIPv6, the UE is unaware of the handover, and the 
deployment is simple. However, routing optimization solution is not 
specified, thus the traffic tromboning is a major problem.
Either for the centralized anchor point or for the flatten anchor point, 
the traffic tromboning problem always exists.
In the case of centralized anchor point, the level of the anchor gateway 
is higher, and the gateway becomes the bottleneck in performance. 
Furthermore, the situation is even worse if some value-added services are 
applied in the anchor gateway, e.g. content-based accounting.
In the case of flatten anchor point, the level of the anchor gateway is 
lower. Handover occurs frequently, and traffic tromboning is serious. As a 
result, the link resource wasting and the traffic delay would be greatly 
increased.
GTP based solution has the same problem of PMIP.

Best regards!

～·～·～·～·～·～·～·～·～·～·～·～·～
SONG Jun,  Ph.D.

Center R&D, ZTE Corporation
Email: [email-masked]
～·～·～·～·～·～·～·～·～·～·～·～·～

"Seok Joo Koh" <[email-masked]> 
发件人:  [email-masked]
2010-10-28 上午 07:53

收件人
"liu dapeng" <[email-masked]>, "dmm" <[email-masked]>
抄送
caozhen <[email-masked]>, MELIA TELEMACO 
<[email-masked]>, "charles.perkins" 
<[email-masked]>, denghui02 <[email-masked]>, Wassim 
Haddad <[email-masked]>
主题
Re: [dmm] DMM problem statement and scenario draft

It seems that the initial drafts and the proposed WG charter will be a 
good triggering point toward 
DMM.
The stepwise approach for design of DMM are also reasonable.

Some comments are:
1) The design of DMM needs to be done in the viewpoint of (generic) 
Functiona Architecture,
rather than based on specific protocols (MIP, PMIP), since  DMM may be 
used in the future
emerging networks (not identified yet) as well as in the current MIP/PMIP 
networks.

2) At present, the main target network to DMM may be the LTE/SAE or 4G 
mobile networks.
In the drafts, it is very helpful to describe the associated requirements 
and applicability 
statements.

Regards,

----- Original Message ----- 
From: "liu dapeng" <[email-masked]>
To: "dmm" <[email-masked]>
Cc: "charles.perkins" <[email-masked]>; "caozhen" 
<[email-masked]>; "MELIA 
TELEMACO" <[email-masked]>; "Wassim Haddad" 
<[email-masked]>; 
"denghui02" <[email-masked]>
Sent: Tuesday, October 19, 2010 5:12 PM
Subject: [dmm] DMM problem statement and scenario draft

Hello all,

Best Regards,
Dapeng Liu

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Oct 2010 00:26:29 -0700

Hi Jun Song:

Few comments to your analysis of the gaps in MIP protocols.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 27, 2010 11:15 PM
To: Seok Joo Koh
Cc: charles.perkins; caozhen; MELIA TELEMACO; Wassim Haddad; dmm; denghui02; [email-masked]
Subject: [dmm] 答复: Re: DMM problem statement and scenario draft

MIPv6 and PMIPv6 are typical mobility management solutions, presenting host based and network based solutions respectively. 

MIPv6 
There are some problems in MIPv6, even though it has the solution supporting routing optimization. 

1) MIPv6 can not be supported by legacy terminals 
It is difficult for the operators to control the terminals' upgrading. So the MIPv6-based solution is hard to be promoted and deployed. 

Agree to large extent. But, we cannot totally ignore the success of MIPv4, a client-based approach in CDMA networks. An integrated WiFI-LTE chip with DSMIPv6 function can get some attention, but the resistance seem to be multi-fold, a.) Lack of operator interest b.) Current operator fear to keep the non-essential traffic from the EPC when using non-3GPP access networks c.)  client complexity and lack of OS support. Business motivation can change #a, can change #b too if operators try to keep the user traffic just as how social networking sites love to keep the visitors.  Either #a or #b can drive #c. But, it is true, network-based approaches 

2) Routing optimization needs supporting by the communication peers 
MIPv6 is independent of the fixed terminals, and is not mandated for the 3GPP mobile UE. These terminals occupy more than 90 percent in all  terminals. So the routing optimization solutions can not be applied in the most scenarios. 

3GPP terminal can host MIPv6 client function. It is an optional feature. 

Do you want Route optimization ? Do you want location privacy/charging on user data/policy control/lawful interception ? Make your pick. 

IMO, even in anchored based models, you can achieve route optimization to large extent, based on the deployment topology. Secondly, RO is not always undesirable, operators want to be in the control path, want to have the ability to charge for every byte and intercept that traffic. If you are an operator in China, you may have to archive every byte from every UE for the next 100 years J

PMIPv6 
In the case of PMIPv6, the UE is unaware of the handover, and the deployment is simple.

 However, routing optimization solution is not specified, thus the traffic tromboning is a major problem. 

Who wants RO ? If 95% of the traffic from the mobile node is hitting the internet, the traffic will hit the PGW. I wonder, how the optimized path will look like for such traffic. If the reference is more about offload at the SGW or at the RAN, its more about your gateway selection approaches and the internet peering points you have at each network point.

Either for the centralized anchor point or for the flatten anchor point, the traffic tromboning problem always exists. 
In the case of centralized anchor point, the level of the anchor gateway is higher, and the gateway becomes the bottleneck in performance. Furthermore, the situation is even worse if some value-added services are applied in the anchor gateway, e.g. content-based accounting. 
In the case of flatten anchor point, the level of the anchor gateway is lower. Handover occurs frequently, and traffic tromboning is serious. As a result, the link resource wasting and the traffic delay would be greatly increased. 
GTP based solution has the same problem of PMIP. 

We need to qualify the requirements first. Sure, centralized models have pros and cons and so with flat models. There is no perfect answer. This will be an academic exercise if requirements are not presented in the right business context.  There is no one perfect approach, you can either anchor with mapping table, or you can float a specific route. Sure, you can provide that mapping table in multiple ways, decoupled from the anchor or at the anchor. Fundamentally, the solution does not change. There is no magic here, you can change the order of the variables in the expression, but the expression does not change.

Sri

---

From: liu dapeng <[email-masked]>
Date: Fri, 29 Oct 2010 03:53:43 +0800

Hi Seok,

Thanks for the comments,

> emerging networks (not identified yet) as well as in the current MIP/PMIP

Are you suggesting that DMM should not be extensions of current
protocols and need a totally new design?

> Hope to have useful discussion and decision in the upcoming IETF meeting.

You are welcomed to join the discussion.

Best regards,
Dapeng Liu

---

From: [email-masked]
Date: Fri, 29 Oct 2010 14:16:37 +0800

Dear Sri 

Thank for your quick comments! 

In the existing mobile network, the GGSNs usually are deployed at the 
higher level of network. Such deployment model is suitable for the 2/3G 
mobile network with less active subscribers and lower bandwidth. The 
benefits of this deployment model are obvious. First, it’s convenient to 
the operator for charging and managing subscribers. Second, in the IP 
backbone network, IP routes advertised by GGSNs are converged and are not 
impacted by user mobility. Third, the centralized GGSNs facilitate the 
operation and maintenance. Meanwhile, it causes some problems, such as 
data tromboning. When the UE moves to a place far from its original access 
network in which the serving GGSN is located. For service continuity 
reason, the UE needs to hold the same IP address allocated by the serving 
GGSN to access the service. And the data traffic has to transfer through 
the serving GGSN far away, even the UE moves to a place very close to the 
corresponding node. In such case, the traffic is tromboning, which leads 
to more transmission delay and cost, and worse subscriber’s experience. 
Compared to the benefits, this drawback is acceptable when the active 
subscribers are less and the data traffic is light.  Other solution 
applied in WiMAX/3GPP2/3GPP, based on MIPv6 or PMIPv6, is similar to that 
based on GTP, and have similar pros and cons 
However, the increasing wireless access bandwidth and penetration of 
intelligence UE drive the mobile internet services and video services more 
popular. The mobility events occur more frequently. As a result, the 
traffic tromboning becomes more serious. The current mobility management 
solutions have been unsuitable for the evolution of mobile packets network 

The above is our thoughts of the background. I believe that the carriers 
have a deeper understanding. 

Some opinions are in the below. 

Best regards! 
～・～・～・～・～・～・～・～・～・～・～・～・～
SONG Jun,  Ph.D.

Email: [email-masked]
～・～・～・～・～・～・～・～・～・～・～・～・～

"Sri Gundavelli (sgundave)" <[email-masked]> 
2010-10-28 下午 03:26

收件人
<[email-masked]>, "Seok Joo Koh" <[email-masked]>
抄送
"charles.perkins" <[email-masked]>, "caozhen" 
<[email-masked]>, "MELIA TELEMACO" 
<[email-masked]>, "Wassim Haddad" 
<[email-masked]>, "dmm" <[email-masked]>, "denghui02" 
<[email-masked]>, <[email-masked]>
主题
RE: [dmm] 答复: Re:  DMM problem statement and scenario draft

Hi Jun Song:

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Wednesday, October 27, 2010 11:15 PM
To: Seok Joo Koh
Cc: charles.perkins; caozhen; MELIA TELEMACO; Wassim Haddad; dmm; 
denghui02; [email-masked]
Subject: [dmm] 答复: Re: DMM problem statement and scenario draft

MIPv6 

Agree to large extent. But, we cannot totally ignore the success of MIPv4, 
a client-based approach in CDMA networks. An integrated WiFI-LTE chip with 
DSMIPv6 function can get some attention, but the resistance seem to be 
multi-fold, a.) Lack of operator interest b.) Current operator fear to 
keep the non-essential traffic from the EPC when using non-3GPP access 
networks c.)  client complexity and lack of OS support. Business 
motivation can change #a, can change #b too if operators try to keep the 
user traffic just as how social networking sites love to keep the 
visitors.  Either #a or #b can drive #c. But, it is true, network-based 
approaches 

Song:  Thank for your agreements. 

2) Routing optimization needs supporting by the communication peers 
MIPv6 is independent of the fixed terminals, and is not mandated for the 
3GPP mobile UE. These terminals occupy more than 90 percent in all 
terminals. So the routing optimization solutions can not be applied in the 
most scenarios. 
3GPP terminal can host MIPv6 client function. It is an optional feature. 
Do you want Route optimization ? Do you want location privacy/charging on 
user data/policy control/lawful interception ? Make your pick. 
IMO, even in anchored based models, you can achieve route optimization to 
large extent, based on the deployment topology. Secondly, RO is not always 
undesirable, operators want to be in the control path, want to have the 
ability to charge for every byte and intercept that traffic. If you are an 
operator in China, you may have to archive every byte from every UE for 
the next 100 years J
 
Song: Your mentioned requirements are reasonable.  Route optimization is 
also an important issue. Whether could we assume that Route optimization 
is natively conflict with these requirements? Is it possible to study out 
a better solution ? 

PMIPv6 
In the case of PMIPv6, the UE is unaware of the handover, and the 
deployment is simple.
 However, routing optimization solution is not specified, thus the traffic 
tromboning is a major problem. 
Who wants RO ? If 95% of the traffic from the mobile node is hitting the 
internet, the traffic will hit the PGW. I wonder, how the optimized path 
will look like for such traffic. If the reference is more about offload at 
the SGW or at the RAN, its more about your gateway selection approaches 
and the internet peering points you have at each network point.

Song:   The current offload solution sacrifices mobility in some extent. 
It may degrade user's experience and influence the smooth of service.    

We need to qualify the requirements first. Sure, centralized models have 
pros and cons and so with flat models. There is no perfect answer. This 
will be an academic exercise if requirements are not presented in the 
right business context.  There is no one perfect approach, you can either 
anchor with mapping table, or you can float a specific route. Sure, you 
can provide that mapping table in multiple ways, decoupled from the anchor 
or at the anchor. Fundamentally, the solution does not change. There is no 
magic here, you can change the order of the variables in the expression, 
but the expression does not change.

Song:   I think that this is a problem that DMM may resolve.  I hope we 
could find a better solution together in DMM group. As to the requirement, 
the two DMM drafts have a good description. May we discuss them together? 
 
Sri