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]