idnits 2.17.1 draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc-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 : ---------------------------------------------------------------------------- No issues found here. 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 seems to have RFC 2119 boilerplate text. -- The document date (June 30, 2015) is 3222 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2234' is defined on line 287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG R. Gu, Ed. 3 Internet-Draft C. Li 4 Intended status: Informational R. Wang 5 Expires: January 1, 2016 China Mobile 6 June 30, 2015 8 Problem statement of SDN and NFV co-deployment in cloud datacenters 9 draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc-00 11 Abstract 13 With the development of cloud computing technology, cloud datacenters 14 have been influenced. Co-deployment of SDN and NFV technology shows 15 its distinct advantages of vitalizing network resources in providing 16 VPC services and SFC services.In order to deploy SDN and NFV in cloud 17 datacenters, a resolution test has been conducted. According to the 18 resolution test, SDN and NFV technology has been mature already for 19 the commercial deployment in operators' network. However, there are 20 some key problems on network architecture, virtualized platform, 21 standard interfaces and so on to be working out in practical 22 practice. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 1, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 58 4. SDN and NFV usecase in cloud datacenters . . . . . . . . . . 3 59 5. Resolution test of SDN and NFV in cloud datacenters . . . . . 4 60 6. Problems and aspects to be considered in the trail deployment 5 61 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Datacenters have been heavily impacted due to the development and 70 large-scale deployment of cloud computing technology. Co-deployment 71 of SDN and NFV technology shows its distinct advantages of 72 virtualizing network resources in the scenario of cloud datacenter 73 such as convenient and elastic. 75 SDN technology helps the cloud datacenters with central-management 76 and resource efficiency. NFV brings up virtual machines instead of 77 physical firewall, load balancer, and VPN gateway devices. Thus VPC 78 services and service functions are provided with the SDN 79 architecture, NFV elements, standard interfaces and the designing 80 flow table. 82 In order to deploy SDN and NFV in cloud datacenters, we have 83 conducted a resolution test aiming at co-deployment of SDN and NFV. 84 According to the resolution test, SDN and NFV technology have been 85 mature already for the commercial deployment in operators' network. 86 However, there are some key problems on network architecture, 87 virtualized platform, standard interfaces and so on to be working out 88 in practical practice. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Definition of terms 98 NAT: network address translation 100 NFV: network function virtualization 102 SDN: software defined network 104 SF: service function 106 SFC: service function chaining 108 VAS: value-added service 110 VFW: virtual firewall 112 VLB: virtual load balancer 114 VM: virtual machine 116 VPC: virtual private cloud 118 4. SDN and NFV usecase in cloud datacenters 120 In cloud datacenters, the SDN and NFV architecture includes the 121 applications to tenants, SDN controller, network function virtualized 122 manager (NFVM), SFC controller and the service function node. With 123 the orchestration, the SDN controller, SFC controller and the NFV 124 manager work in coordination to provide the auto-deployed services 125 such as VPC, VAS of layer 4 - layer 7 and so on. 127 Tenants make the requirement of services in the service applications. 128 Service application records tenants' network and service requirements 129 and translates them into the SDN controller, SFC controller and the 130 NFV managers with the logical network mapping to the physical 131 network. The orchestrator including the virtualized platform is in 132 charge of the orchestration and management of NFV infrastructure and 133 software resources, and realizing network services. The SDN 134 controller is a logically centralized entity with a general view of 135 the network and in charge of SDN data paths, while the SFC controller 136 is in central control of the service function chain according to the 137 requirements from the service applications. The NFV manager is 138 responsible for NFV lifecycle management such as installation, 139 update, query, scaling and termination. In the bottom, network 140 elements are the resource instances which can be a virtual instance 141 such as a virtual machine or be embedded in a physical network 142 element such as the virtual load balance instances or the physical 143 firewall located in the resource pool. 145 -------------------------- 146 | | 147 | Service Application +--------------------------- 148 | | | 149 ----+--------------+------ | 150 | | | 151 | | | 152 | ---------+------- | 153 | | | | 154 | | Orchestrator +---------------------- | 155 | | | | | 156 | ----+---------+-- | | 157 | | | | | 158 | | | | | 159 ---+---------+---- --+--------------- -----+---+------ 160 | | | | | | 161 | SDN Controller | | SFC Controller | | NFV manager | 162 | | | | | | 163 ---+-------------- ---------+-------- ---------------- 164 | | 165 -----+--------------------------+--------------------------- 166 | | 167 | ----- ----- ----- ------ | 168 | |VSW| |VSW| |VSW| | VR | | 169 | ----- ----- ----- ------ | 170 | | 171 | ------ ------ ------ ------ ------- | 172 | | VM | | VM | | VLB| | VFW| | DPI | | 173 | ------ ------ ------ ------ ------- | 174 | | 175 | network element | 176 ------------------------------------------------------------ 178 Figure 1: SDN and NFV usecase in cloud datacenters 180 5. Resolution test of SDN and NFV in cloud datacenters 182 The resolution test is based on the architecture introduced with the 183 KVM virtualized platform, and Openstack as the orchestrator. In the 184 resolution test, the whole systems, network architecture, SDN 185 controller, and forwarding devices are tested of functions, 186 performances and security under normal and stress conditions. 188 6. Problems and aspects to be considered in the trail deployment 190 It's found out that some key problems exist when introducing SDN and 191 NFV technology into cloud datacenters under the resolution tests and 192 the practical trail. Problems rely on aspects such as virtualized 193 platforms, network architectures, interface standardization, and some 194 others listed as follows. 196 (1)Virtualized platforms 198 KVM virtualized platform is adopted in our test. However, other 199 virtualized platforms are not well supported by Openstack. The main 200 reason relies on that Openstack is an open-source cloud operating 201 system developing based on KVM platform, which is widely used in 202 public cloud datacenters. Actually in the private cloud datacenters, 203 other virtualized platforms such as VMware and XEN are widely 204 adopted. Thus more work needs to be focused on other virtualized 205 platforms carrying on SDN technology with platforms of much more open 206 interfaces and more interface docking attempts. 208 (2) Network architecture 210 The network architecture of SDN is clear according to other 211 standardization organizations with hierarchical layers of application 212 layer, orchestrator, controlling layer and forwarding layer. When 213 adding the virtualized network elements into the SDN architecture, 214 problems arise around the network architecture of SDN and NFV co- 215 deployed in the cloud datacenters. How can the orchestration layer, 216 SDN controller, SFC controller, NFV manager co-operate in order to 217 provide the VPC services and SFC services. What's the relationship 218 and specific role-taking between the service application, 219 orchestration layer, SDN controller, SFC controller and NFV manager. 220 The specific interfaces between these related parts are obscure as 221 well. 223 (3) Interface standardization 225 Due to the incomplete interface of Openstack, interface 226 standardization should be taking into consideration. Nowadays, 227 physical servers are out of the management scope of Openstack. 228 Besides, the FW and LB plug-ins are limited into only one vendor. 229 Service function chaining interfaces are still under discussion 230 without being published. The specific interfaces between SDN 231 controller, SFC controller and NFV manager are obscure as well. 232 Above all, the interface standardizations should be kept researching 233 on. 235 (4) Virtualization high availability 236 As virtual machines and virtualized platforms are brought in, 237 reliability can be a problem. Reliability can be divided into 238 several layers: the virtual network elements, Openstack, controller, 239 virtual link and so on. Up to now, Openstack has no ability of high 240 availability of its database. High availability of virtual network 241 elements integrated in the SDN architectures are without 242 standardization. 244 (5) Benchmark standardization 246 In the resolution test, it works out that the benchmark 247 standardization should be focused on. In actual test, both 248 encapsulation technology of VxLAN and MPLSoGRE exist in the SDN 249 overlay resolution with difficult comparison. Besides, there are two 250 realization mechanisms of active and passive trigger mode when SDN 251 controller communicates with the forwarding devices. Thus the 252 benchmark of SDN controller performance runs to a problem. 254 (6) Practical practice experience 256 The technology of NFV and SDN is still in the trial stage which is 257 lack of practical practice experience. According to the scenarios, 258 NFV elements can be deployed behind the gateway or in a hang-on mode 259 next to the core switch. Besides, centralized and distributed 260 deployments of NAT devices are alternated. The deployment guidance 261 of practical practice is eager. to be shared. 263 7. Conclusion 265 SDN and NFV technology has been planned to be co-deployed in the 266 cloud datacenters in providing services such as VPC and VAS of 267 layer4-layer7.Through the resolution test, we have found out that key 268 problems on network architecture, virtualized platform, standard 269 interfaces, high availability and practice guidance exist.More tests, 270 trails and standardization work need to be conducted in preparing the 271 large-scale commercial deployment of SDN and NFV technology in cloud 272 datacenters. 274 8. Security Considerations 276 None. 278 9. IANA Considerations 280 None. 282 10. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 288 Specifications: ABNF", RFC 2234, November 1997. 290 Authors' Addresses 292 Rong Gu (editor) 293 China Mobile 294 32 Xuanwumen West Ave, Xicheng District 295 Beijing 100053 296 China 298 Email: gurong_cmcc@outlook.com 300 Chen Li 301 China Mobile 302 32 Xuanwumen West Ave, Xicheng District 303 Beijing 100053 304 China 306 Email: lichenyj@chinamobile.com 308 Ruixue Wang 309 China Mobile 310 32 Xuanwumen West Ave, Xicheng District 311 Beijing 100053 312 China