idnits 2.17.1 draft-liu-dmm-deployment-scenario-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE-802.11.2012' is defined on line 214, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Liu 2 Internet-Draft China Mobile 3 Intended status: Informational H. Chan 4 Expires: August 18, 2014 Huawei Technologies 5 H. Deng 6 China Mobile 7 February 14, 2014 9 DMM Deployment Scenario 10 draft-liu-dmm-deployment-scenario-00 12 Abstract 14 This document discusses the deployment scenario of distributed 15 mobility management. The purpose of this document is to trigger the 16 discussion in the group to understnad the DMM deployment scenario and 17 consideration from the operator's perspective. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 18, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 2 55 3. Deployment Scenario and Model of DMM . . . . . . . . . . . . 2 56 4. Network Function Virtualization Scenario . . . . . . . . . . 3 57 5. Problem statement of network function virtualization 58 deployment model . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Control and data plane separation . . . . . . . . . . . . 4 60 5.2. Mobility management . . . . . . . . . . . . . . . . . . . 4 61 6. SIPTO deployment scenario . . . . . . . . . . . . . . . . . . 4 62 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 12. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 Distributed mobility management aims at solving the centralized 73 mobility anchor problems of the tranditional mobility management 74 protocol. The benefit of DMM solution is that the data plane traffic 75 does not need to traverse the centralized anchoring point. This 76 document discusses the potential deployment scenario of DMM. The 77 purpose of this document is to help the group to reach consensus 78 regarding the deployment model of DMM and then develop the DMM 79 solution based on the deployment model. 81 2. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Deployment Scenario and Model of DMM 89 As discussed in the DMM requirement document, the centralized 90 mobility management has several drawbacks. The main problem of the 91 centralized mobility management protocols is that all the traffic 92 need to anchor to a centralized anchor point. This approach does not 93 cause any problem in current mobile network deployment but in the 94 scenario that will be discussed later in this document, centralized 95 mobility management protocols will have many drawbacks and it is 96 believed that DMM is more suitable in that scenario. 98 The main deployment scenario discussed in this document is divided 99 into two types. The first one is the network function virtualization 100 scenario. In this scenario, the mobile core network's control plane 101 function is centralized in the mobile cloud. Apparently, deploying 102 the data plane function also in the same centralized mobile cloud is 103 not optimized from the traffic routing's perspective. Another 104 deployment scenario is the SIPTO/LIPA scenario which is discussed in 105 3GPP. In this scenario, DMM can provide optimized traffic offloading 106 solution. 108 4. Network Function Virtualization Scenario 110 This section discusses network function virtualization scenario. 112 Mobile Cloud 113 ........... 114 (' ') 115 ( ))) 116 ((( +-----------+ ))) 117 (( |Mobile Core| ))) 118 ((( +-----------+ ))) 119 ('..............') 120 | 121 | IP Transit Network 122 (.........) 123 ( )) MN-Internet communication 124 ( ^ )) 125 ^ > > >( ^ ))> > > > > > > > > 126 ^ (( ^ ) v 127 ^ (.........^.) v 128 ^ +-------| | ^| v 129 ^ | | ^+--------------+ v 130 ^ | | < < | v MN-MN communication 131 ^ | | ^ | v 132 +--------------+ +--------------+ +--------------+ 133 |Access Network| |Access Network| |Access Network| 134 +--------------+ +--------------+ +--------------+ 135 ^ ^ v 136 ^ ^ v 137 +---------+ +---------+ +---------+ 138 | MN | | MN | | MN | 139 +---------+ +---------+ +---------+ 141 Figure 1: Network function virtualization deployment architecture 143 In this architecture, the mobile core network is located in the cloud 144 /data center, which can be the operator's private cloud. The access 145 network is connected through an IP transit network. The mobile core 146 network can run in a virtualized platform in the cloud/datacenter. 148 5. Problem statement of network function virtualization deployment 149 model 151 5.1. Control and data plane separation 153 The cloud based mobile core network architecture implies separation 154 of the control and data plane. The control plane is located in the 155 cloud and the data plane should be distributed. Otherwise, all the 156 data traffic will go through the cloud which is obviously not 157 optimized for the mobile node to mobile node communication. 159 For the mobile node to Internet communication, the Internet access 160 point is normally located in the metro IP transit network. In this 161 case, the mobile node to Internet traffic should also go through the 162 Internet access point instead of the mobile core in the cloud. 164 However, in some deployment scenario, the operator may choose to put 165 the mobile core cloud in the convergence layer of IP metro network. 166 In this case, the Internet access point may co-located with the 167 mobile core cloud. In this case, the mobile node to Internet traffic 168 may go through the mobile core cloud. 170 5.2. Mobility management 172 Since the control plane and data plane are separated and the data 173 plane is distributed, traditional mobility management can not meet 174 this requirement. 176 Distributed mobility management or SDN based mobility management may 177 be used in this architecture to meet the traffic routing requirement 178 (e.g. MN to MN and MN to Internet traffic should not go through from 179 the mobile core cloud.). 181 6. SIPTO deployment scenario 183 Another deployment scenario is the SIPTO scenario which is discussed 184 in 3GPP. DMM is believed to be able to provide dynamic anchoring. 185 It allows the mobile node to have several anchoring points and to 186 change the anchoring point according to the requirment of 187 application. In SIPTO scenario, the gateway function is located very 188 near to the access network and to the user. If using current 189 centralized mobility management, the traffic will need to tunnel back 190 to the previous anchor point even when the mobile node has changed 191 the point of attachment to a new one. 193 7. Conclusion 195 This document discusses the deployment scenario of DMM. Two types of 196 deployment scenario is discussed in this document. Further types of 197 deployment scenario can be added to this document according to the 198 progress of the group's discussion. 200 8. Security Considerations 202 N/A 204 9. IANA Considerations 206 N/A 208 10. Contributors 210 11. Acknowledgements 212 12. Normative References 214 [IEEE-802.11.2012] 215 March 2012. 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 Authors' Addresses 222 Dapeng Liu 223 China Mobile 224 No.32 Xuanwumen West Street 225 Beijing 100053 226 China 228 Email: liudapeng@chinamobile.com 229 H Anthony Chan 230 Huawei Technologies 231 5340 Legacy Dr. Building 3 232 Plano, TX 75024 233 USA 235 Email: h.a.chan@ieee.org 237 Hui Deng 238 China Mobile 239 No.32 Xuanwumen West Street 240 Beijing 100053 241 China 243 Email: denghui@chinamobile.com