Network Working Group V.Liu Internet Draft ChinaMobile Intended status: Standards Track D.Liu Expires: Nov 15, 2015January Alibaba H. Chan Huawei Technologies H. Deng China Mobile July 6, 2015 Distributed mobility management deployment scenario and architecture draft-liu-dmm-deployment-scenario-04 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 January 6, 2009. Copyright Notice Copyright (c) 2015 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 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. Liu, et al. ExpiresJanuaryNov 15, 2015 2016 [Page 1] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 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 to this document. Abstract This document discusses the deployment scenario of distributed mobility management. The purpose of this document is to trigger the discussion in the group to understnad the DMM deployment scenario and consideration from the operator's perspective. Table of Contents Table of Contents ................................................ 2 1. Introduction .................................................. 2 2. Conventions used in this document.............................. 3 2.1. Terminology .............................................. 3 3. Deployment Scenario and Model of DMM........................... 3 4. Network Function Virtualization Scenario....................... 4 4.1. Network function virtualization deployment architecture... 4 4.2. Control and data plane separation......................... 6 4.3. Mobility management architecture.......................... 6 5. SIPTO deployment scenario...................................... 8 6. WLAN deployment scenario....................................... 9 7. Conclusion ................................................... 10 8. Security Considerations....................................... 10 9. IANA Considerations .......................................... 10 10. Normative References......................................... 11 11. Informative References....................................... 11 12. Acknowledgments ............................................. 11 Authors' Addresses .............................................. 12 1. Introduction 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. Liu, et al. Expires Nov 15, 2015 [Page 2] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 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]. 2.1. Terminology 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 [RFC6275], in the Proxy mobile IPv6 specification [RFC5213], and in Mobility Related Terminology [RFC3753]. These terms include the following: mobile node (MN), correspondent node (CN), and home agent (HA) as per [RFC6275]; local mobility anchor (LMA) and mobile access gateway (MAG) as per [RFC5213], and context as per [RFC3753]. In addition, this draft introduces the following terms. Location information (LI) function is the logical function that manages and keeps track of the internet work 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. Forwarding management (FM) 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. 3. Deployment Scenario and Model of DMM 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 Liu, et al. Expires Nov 15, 2015 [Page 3] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 mobility management protocols will have many drawbacks and it is believed that DMM is more suitable in that scenario. The main deployment scenario discussed in this document is divided into three scenarios. 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. For the control plane The MME and PGW-F are implemented by NFV. For the dataplane the PGW-F/SGW-F can weither be implemented by NFV or lagacy devices. The second deployment scenario is the SIPTO/LIPA scenario which is discussed in 3GPP. In this scenario, DMM can provide optimized traffic offloading solution. The Third deploy scenario is the WLAN scenario. In this scenario, the AC is implemented in the cloud and the authentication status can maintained as the terminal move from one AP to another. 4. Network Function Virtualization Scenario This section discusses network function virtualization scenario, the associated control - data plane separation and the possible mobility management functions to support this scenario. 4.1. Network function virtualization deployment architecture The network function virtualization scenario is shown in Figure 1. Liu, et al. Expires Nov 15, 2015 [Page 4] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 Mobile Cloud ........... (' ') ( ))) ((( +-----------+ ))) (( |Mobile Core| ))) (( |MME+P/SGW-C| ))) ((( +-----------+ ))) ('..............') | | IP Transit Network (.........) ( )) MN-Internet communication ( ^ )) ^ > > >( ^ ))> > > > > > > > > ^ (( ^ ) v ^ (.........^.) v ^ +-------| | ^| v ^ | | ^+--------------+ v ^ | | < < | v MN-MN communication ^ | | ^ | v +--------------+ +--------------+ +--------------+ |Access Network| |Access Network| |Access Network| | PGW-F/SGW-F | | PGW-F/SGW-F | | PGW-F/SGW-F | +--------------+ +--------------+ +--------------+ ^ ^ v ^ ^ v +---------+ +---------+ +---------+ | MN | | MN | | MN | +---------+ +---------+ +---------+ Figure 1: Network function virtualization deployment architecture In this architecture, the mobile core include MME and PGW-F is located in the cloud data center, which can be the operator's private cloud using NFV. The access network cantains PGW-F/SGW-F is connected through an IP transit network. The PGW-F/SGW-F may also implement by NFV of small data center in convergence layer. The architecture of NFV based Mobile Core is shown in Figure 2. Liu, et al. Expires Nov 15, 2015 [Page 5] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 --------------------------------- ------------------- | ----------------------------- | | MANO LAYER | | | OSS/BSS LAYER | | | | | ----------------------------- | | ------------- | | | | | |Orchestrator| | | ----------------------------- | | ------------- | | | VNF LAYER | | | | | | | --------- ------ | | | ------------- | | | |P/SGW-C| | MME | | |-----| | VNFM | | | | --------- ------ | | ------------- | | ----------------------------- | | | | | | | | | | | ----------------------------- | | ------------- | | | NFVI LAYER | |-----| | VIM | | | ----------------------------- | | ------------- | --------------------------------- ------------------- Figure 2: NFV based Mobile Core Architecture In Figure 2, the MANO layer contains Orchestrator, VNFM and VIM. The Orchestrator is in charge of top-down service and source monitor and fulfillment. VNFM is incharge of manage the VNFs. And VIM normally is the Openstack which provide management of the whole virtualization layer. 4.2. Control and data plane separation 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. 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. 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. 4.3. Mobility management architecture Since the control plane and data plane are separated and the data plane is distributed, traditional mobility management cannot meet Liu, et al. Expires Nov 15, 2015 [Page 6] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 this requirement. 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.). 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). 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. core network controller +---------+ |LI, FM-CP| +---------+ +-------+ +-------+ +-------+ | FM-DP | | FM-DP | | FM-DP | +-------+ +-------+ +-------+ Figure 2: Mobility management functions with data plane - control plane separation under one controller When the control of the access network is separate from that of the core, there will be separate controllers as shown in Figure 3. Access network controller Core network controller +---------+ +---------+ |LI, FM-CP| |LI, FM-CP| +---------+ +---------+ +-------+ +-------+ +-------+ +-------+ | FM-DP | | FM-DP | | FM-DP | | FM-DP | +-------+ +-------+ +-------+ +-------+ Liu, et al. Expires Nov 15, 2015 [Page 7] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 Figure 2: Mobility management functions with data plane - control plane separation with separate control in core and in access networks. 5. SIPTO deployment scenario The Second 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. Figure 3 shows the architecture of SIPTO. Liu, et al. Expires Nov 15, 2015 [Page 8] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 +---------+ | GGSN | +---------+ | | ------------------------------------------ | | | | +---------+ +---------+ +---------+ +---------+ | MSC | | SGSN | | MSC | | SGSN | +---------+ +---------+ +---------+ +---------+ | | | | | | ------------ ---------- --------- | | | <<<<<<<<<| <<<<<<<| |>>>>>>>> +---------+ +---------+ +---------+ | GGSN | | GGSN | | GGSN | | RNC | | RNC | | RNC | +---------+ +---------+ +---------+ ^| |^ ^| ^| |^ ^| --------------- |^ ^| ^| |^ |^ ^| +---------+ +---------+ +---------+ +---------+ | NodeB | | NodeB | | NodeB | | NodeB | +---------+ +---------+ +---------+ +---------+ ^| ^| ^| +---------+ +---------+ +---------+ | Terminal| -> | Terminal| -> -> | Terminal| +---------+ +---------+ +---------+ Figure 3 SIPTO Scenario 6. WLAN deployment scenario The Third deployment scenario is the WLAN scenario. DMM can enable the AC in the cloud. The cloud AC and maintain the authentication and connection status. As the terminal move from one AP to another, it still can have the connection. Liu, et al. Expires Nov 15, 2015 [Page 9] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 ........... (' ') ((( +-----------+ ))) (( | Mobile AC | ))) ((( +-----------+ ))) ('..............') | | IP Transit Network (.........) ( )) ( )) ( )) (( ) (..........) +-----------------------------------+ | | | | | | | | | +----------+ +-----------+ +----------+ | AP | | AP | | AP | +----------+ +-----------+ +----------+ | | | +---------+ +---------+ +---------+ | Terminal| -> | Terminal| -> | Terminal| +---------+ +---------+ +---------+ 7. Conclusion This document discusses the deployment scenario of DMM. Three 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. 8. Security Considerations N/A 9. IANA Considerations N/A Liu, et al. Expires Nov 15, 2015 [Page 10] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 10. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 11. Informative References [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 1583. [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. 12. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Liu, et al. Expires Nov 15, 2015 [Page 11] Internet-Draft draft-liu-dmm-deployment-scenario July 2015 Authors' Addresses Vic Liu China Mobile 32 Xuanwumen West AVE, Xicheng, Beijing Email: liuzhiheng@chinamobile.com Dapeng Liu Alibaba Email: max@dotalks.com H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 USA Email: h.a.chan@ieee.org Hui Deng China Mobile 32 Xuanwumen West AVE, Xicheng, Beijing Email: denglingli@chinamobile.com Liu, et al. Expires Nov 15, 2015 [Page 12]