Network Working Group D. Liu
Internet-Draft China Mobile
Intended status: Informational J. Song
Expires: September 8, 2011 W. Luo
ZTE
March 7, 2011
Distributed Mobility Management Traffic analysis
draft-liu-distributed-mobility-traffic-analysis-00
Abstract
There is a trend in mobile network that gateways are deployed more
and more closer to the network edge. The motivation of this trend
comes from several aspects and the result is that the mobile network
architecture is evolving toward flatten network architecture. In
this scenario, mobility solution needed to be studied to fit for the
flatten network. This document analysis the benefit of distributing
mobility anchor to the network edge from the traffic load pespective.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Liu, et al. Expires September 8, 2011 [Page 1]
Internet-Draft DMM Traffic Analysis March 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Centralized and distributed network architecture analysis . . 3
3.1. Traffic load model . . . . . . . . . . . . . . . . . . . . 3
3.2. Centralized anchor model . . . . . . . . . . . . . . . . . 4
3.3. Distributed anchor model . . . . . . . . . . . . . . . . . 7
4. Traffic load analysis . . . . . . . . . . . . . . . . . . . . 8
5. Congestion analysis . . . . . . . . . . . . . . . . . . . . . 9
6. Delay analysis . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Liu, et al. Expires September 8, 2011 [Page 2]
Internet-Draft DMM Traffic Analysis March 2011
1. Introduction
Data traffic in mobile network is increasing rapidly. The huge
amount of data traffic gives much impact to the operator's core
network. This gives much presure to the gateways in the core
networks. On the other hand, the gateways in mobile network are
integrated more functions, such as content based charging, service
control etc. Those functions increase the complexity of the gateway
and have much impact to the gateway's performance. Under this
condition, traditional hierarchical architecture is not optimal for
the high volume traffic load. To address this challenge, the mobile
network is evolving towards more flatten architeture. "Flatten"
means less network layer in the architecture. The main advantage of
flat network architecture is that it enables the traffic to be
offloaded to the network edge. This architecture could improve the
performance of the gateway by distributing the complexity to the
network edge.
2. Conventions used in this document
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 [RFC2119].
3. Centralized and distributed network architecture analysis
3.1. Traffic load model
This section describes a traffic load model.
Liu, et al. Expires September 8, 2011 [Page 3]
Internet-Draft DMM Traffic Analysis March 2011
_____________________________+----+
+-----/--------------------------+ |PEER|
| / Backbone | +----+
|+--|----+ +-------+ +-------+ |
||Anchor1| |Anchor2| |Anchorn| |
|+--|----+ +-------+ +-------+ |
+---|----------------------------+
|
+---|----------------------------+
| ____________________________|__+----+
| / \ | |PEER|
| +-|--+ +----+ +-\--+ | +----+
| |xGW1| |xGW2| |xGWn| |
| +-|--+ +----+ +--|-+ |
| | Metro Network | |
+---|----------------------|-----+
| |
+---+ +----------+
|MN | |Another MN|
+---+ +----------+
Figure 1: Traffic Load Model
Figure 1 shows a representative traffic model. The traffic anchor of
the MN is deployed in the higher layer of network (e.g. in the
backbone) and the access gateway is deployed in the metro network.
The traffic from the MN to the correspondent node (e.g. the peer in
the figure) consists of two parts. One part is that the traffic from
the MN to the PEER which connects to the backbone (e.g. Peer locates
in Internet). The other part is the traffic from the MN to the PEER
which connects to the metro network (e.g. peer is operator's metro
service platform) and the traffic from the MN to another MN (e.g.
P2P application).
3.2. Centralized anchor model
This section analysis the traffic load in centralized anchor model.
This model is abstracted from 3GPP SAE network architeture.
Liu, et al. Expires September 8, 2011 [Page 4]
Internet-Draft DMM Traffic Analysis March 2011
+----------------------+
| Backbone |
|+-------+ +-------+ | +-----+
/---||RouterB|-|RouterB|---|---| Peer|
/ |+-------+ +-------+ | +-----+
+----+ / +----------------------+
|P-GW|- | | | |
+----+ | | | +---------------+
/-------+ | +-----+ |
+-------|------------|-------+ +-------|-------------|------+
| | | | | | | |
| +-------+ +-------+ | | +-------+ +-------+ |
| |RouterA|----|RouterA| | | |RouterA|------|RouterA| |
| +-------+ +-------+ | | +-------+ +-------+ |
| \ / | | \ / |
| ,-'' -------+ | | ,-'' -------+ |
| / \ | | / \ |
| / Metro \ | | / Metro \ |+-----+
| | | | | | |-----|Peer |
| \ Network A ,' | | \ Network B ,' |+-----+
| `. _, | | `. _, |
| / `-..____,,' \ | | / `-..____,,' \ |
| / \ | | / \ |
| +------+ +------+ | | +------+ +------+ |
| | S-GW | | S-GW | | | | S-GW | | S-GW | |
| +------+ +------+ | | +------+ +------+ |
| | | |
+----------------------------+ +----------------------------+
Figure 2: Centralized anchor model
In this scenario, mobility anchor (P-GW) is deployed in the higher
layer of network. e.g. in the backbone level of the network. S-GW is
deployed in the metro network. All the traffic need to go through
the mobility anchor(P-GW).
There are two possibilities regarding to the correspondent node's
location (e.g. peer in the figure):
(1)Peer is connected via backbone network. The peer may be located
in Internet. For example, the peer may be an webserver in Internet.
In this case, all the traffic is tunnelled between S-GW and P-GW.
P-GW then de-capsulated the taffic from the tunnel then forward the
traffic to the peer.
Liu, et al. Expires September 8, 2011 [Page 5]
Internet-Draft DMM Traffic Analysis March 2011
The data forwarding path in this case is illustrated in the following
figure:
+----+ +----+ +------+ +-------+ +-----------------+
|UE |-->|S-GW|-->|Metro |-->|RouterA|-->|Metro to Backbone|
+----+ +----+ +------+ +-------+ +-----------------+
|
+----+ +----+ +-------+
|peer|<--|P-GW|<--|RouterB|
+----+ +----+ +-------+
Figure 3: Data forwarding path when peer is connected via backbone
network in centralized anchor model
(2)Peer is located in metro network.
In this case, the peer is located in metro network. The peer may be
an operator's metro service platform etc.
The data forwarding path in this case is illustrated in the following
figure:
+--+ +----+ +------+ +-------+ +-----------------+ +-------+
|UE|->|S-GW|->|Metro |->|RouterA|->|Metro to Backbone|->|RouterB|
+--+ +----+ +------+ +-------+ +-----------------+ +-------+
|
+----+
|P-GW|
+----+
|
+----+ +------+ +--------+ +------------------+ +-------+
|Peer|<--|Metro |<--| RouterA|<--| Metro to Backbone|<-|RouterB|
+----+ +------+ +--------+ +------------------+ +-------+
Figure 4: Data forwarding path when peer is connected via metro
network in centralized anchor model
Liu, et al. Expires September 8, 2011 [Page 6]
Internet-Draft DMM Traffic Analysis March 2011
3.3. Distributed anchor model
This section analyses the traffic load in distributed anchor model.
This model is also based on 3GPP SAE network architeture except that
the anchor function (i.e P-GW) is co-located with S-GW.
+----------------------+
| Backbone |
|+-------+ +-------+ | +-----+
||RouterB|-|RouterB|---|---| Peer|
|+-------+ +-------+ | +-----+
+----------------------+
| | | |
| | | +---------------+
/-------+ | +-----+ |
+-------|------------|-------+ +-------|-------------|------+
| | | | | | | |
| +-------+ +-------+ | | +-------+ +-------+ |
| |RouterA|----|RouterA| | | |RouterA|------|RouterA| |
| +-------+ +-------+ | | +-------+ +-------+ |
| \ / | | \ / |
| ,-'' -------+ | | ,-'' -------+ |
| / \ | | / \ |
| / Metro \ | | / Metro \ +-----+
| | | | | | |-----|Peer |
| \ Network A ,' | | \ Network B ,' +-----+
| `. _, | | `. _, |
| / `-..____,,' \ | | / `-..____,,' \ |
| / \ | | / \ |
| +------+ +------+ | | +------+ +------+ |
| |P-GW | | P-GW | | | | P-GW | | P-GW | |
| |S-GW | | S-GW | | | | S-GW | | S-GW | |
| +------+ +------+ | | +------+ +------+ |
| | | |
+----------------------------+ +----------------------------+
Figure 5: Distributed anchor model
In this scenario, the mobility anchor (P-GW) is deployed in the edge
of network. P-GW is co-located with S-GW which is located in the
metro network.
There are also two possibilities regarding to the correspondent
Liu, et al. Expires September 8, 2011 [Page 7]
Internet-Draft DMM Traffic Analysis March 2011
node's location (e.g. peer in the figure):
(1) Peer is connected via backbone network. The peer may be located
in Internet. for example, the peer may be an web server in Internet.
The data forwarding path in this case is illustrated in the following
figure:
+----+ +----+ +------+ +-------+ +-----------------+
|UE |-->|P-GW| | | | | | |
+----+ |S-GW|-->|Metro |-->|RouterA|-->|Metro to Backbone|
+----+ +------+ +-------+ +-----------------+
|
+-------+ +-------+
| Peer |<--|RouterB|
+-------+ +-------+
Figure 6: Data forwarding path when peer is connected via backbone
network in distributed anchor model
(2) Peer is located in metro network.
In this case, the peer is located in metro network. The peer may be
an operator's metro service platform etc.
The data forwarding path in this case is illustrated in the following
figure:
+----+ +----+ +------+ +-------+
|UE |-->|S-GW|-->|Metro |-->| Peer |
+----+ +----+ +------+ +-------+
Figure 7: Data forwarding path when peer is connected via metro
network in distributed anchor model
4. Traffic load analysis
The traffic from UE can be divided into three parts: the traffic
within metro network, the traffic within backbone, the traffic
between metro and backbone network.
Liu, et al. Expires September 8, 2011 [Page 8]
Internet-Draft DMM Traffic Analysis March 2011
It is assumed that the traffic to the backbone network is 60% and the
traffic to metro network is 40% in this traffic model as described
above.
Based on the above traffic model, the traffic analysis result is:
+------------------------------------------------------------------+
|Traffic | peer in Backbone | peer in Metro | average |
|------------------------------------------------------------------|
|Centra- | | | |
|lized |1 volume within |2 volume within |1.4 volume within |
| |metro. | metro. |metro. |
| |1 volume between |2 volume between |1.4 volume between |
| |metro and backbone|metro and backbone|metro and backbone |
| |1 volume within |2 volume within |1.4 volume within |
| |backbone |backbone |backbone |
|------------------------------------------------------------------+
|Distri- |1 volume within |1 volume within |1 volume within |
|buted |Metro. |metro. |metro. |
| |1 volume between |0 volume between |0.6 volume between |
| |metro and backbone|metro and backbone|metro and backbone |
| |1 volume within |0 volume within |0.6 volume within |
| |backbone |backbone |backbone |
+------------------------------------------------------------------+
Figure 8: Traffic Analysis result
According to analysis result above, distributed model can save 28.6%
traffic within metro network. It can save 57.1% traffic between
metro network and backbone network. It can save 57.1% traffic within
backbone network.
5. Congestion analysis
We assume that the congestion possibility within metro network is X,
the congestion possibility between metro network and backbone network
is Y. Based on the analysis model, we have the following result:
Liu, et al. Expires September 8, 2011 [Page 9]
Internet-Draft DMM Traffic Analysis March 2011
+-------------------------------------------------------------+
|congestion |peer in | | |
|probability|backbone |peer in metro| average |
|-------------------------------------------------------------|
|Centralized| |1-(1-x)*(1-Y)|0.6*[1-(1-X)*(1-Y)]+0.4*|
| |1-(1-X)* |*(1-Y)*(1-X) |[1-(1-X)*(1-Y)*(1-X)* |
| | (1-Y) | | (1-Y) |
| | | | |
|-----------+----------+-------------+------------------------+
|Distributed| | |0.6*[1-(1-X)*(1-Y)]+ |
| |1-(1-X)* | | |
| | (1-Y) | X |0.4*X |
+-------------------------------------------------------------+
Figure 9: Congestion Analysis result
According to the analysis result above, we can conclude that the
congestion probability in distributed deployment is lower than in
centralized deployment. if X=3%, Y=3%, distributed model's congestion
probability will be lower 3.39% compared with centralized model. if
X=Y=10%, distributed model's congestion probability will be lower
9.76% compared with centralized model.
6. Delay analysis
The delay from UE to the peer is composed by three parts: the delay
within metro network: T1; the delay between metro network to backbone
network:T2, the delay within backbone network: T3.
Based on the above model, we have the following analysis result:
+--------------------------------------------------------------+
| | | | |
| Delay | Peer in Backbone| peer in Metro |Average |
|--------------------------------------------------------------|
| Centralized | | | |
| | T1+T2+T3 | 2*(T1+T2+T3) |1.4*(T1+T2+T3)|
|--------------------------------------------------------------+
| Distributed | | |T1+0.6*(T2+T3)|
| | T1+T2+T3 | T1 | |
+--------------------------------------------------------------+
Liu, et al. Expires September 8, 2011 [Page 10]
Internet-Draft DMM Traffic Analysis March 2011
Figure 10: Delay Analysis result
According to the analysis result above, we conclude that the delay in
distributed model is less than centralized model. Specifically, the
delay within metro network will less 28.6%; the delay between metro
network and backbone network will less 57.1%; the delay within
backbone will less 57.1%.
7. Security Considerations
TBD
8. IANA Considerations
None
9. Contributors
The following people contributed to this document (in no specific
order):
Zhihai Wang
ZTE
wang.zhihai@zte.com.cn
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.chan-netext-distributed-lma]
Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed
Local Mobility Anchors",
draft-chan-netext-distributed-lma-03 (work in progress),
March 2010.
[I-D.ietf-mext-flow-binding]
Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
Basic Support", draft-ietf-mext-flow-binding-11 (work in
Liu, et al. Expires September 8, 2011 [Page 11]
Internet-Draft DMM Traffic Analysis March 2011
progress), October 2010.
[I-D.kassi-mobileip-dmi]
Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)",
draft-kassi-mobileip-dmi-01 (work in progress),
January 2003.
[I-D.seite-netext-dma]
Seite, P. and P. Bertin, "Dynamic Mobility Anchoring",
draft-seite-netext-dma-00 (work in progress), May 2010.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
Authors' Addresses
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Jun Song
ZTE
No.68,Zijinghua Road, Yuhuatai District
Nanjing 210012
China
Email: song.jun@zte.com.cn
Liu, et al. Expires September 8, 2011 [Page 12]
Internet-Draft DMM Traffic Analysis March 2011
Wen Luo
ZTE
No.68,Zijinghua Road, Yuhuatai District
Nanjing 210012
China
Email: luo.wen@zte.com.cn
Liu, et al. Expires September 8, 2011 [Page 13]