idnits 2.17.1 draft-gu-sdnrg-network-management-consideration-02.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 (Oct 2016) is 2750 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2234' is defined on line 363, 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 R. Wang 4 Intended status: Informational China Mobile 5 Expires: April 4, 2017 Y. Zhuang 6 Huawei 7 Oct 2016 9 SDN network management consideration 10 draft-gu-sdnrg-network-management-consideration-02 12 Abstract 14 This draft introduces consideration about SDN network management 15 after the deployment of SDN and NFV in cloud datacenters. The 16 content of SDN network management and some specific technique are 17 included from the network administrator's point of view. 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 April 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Definition of terms . . . . . . . . . . . . . . . . . . . . . 4 56 4. SDN network management architecture . . . . . . . . . . . . . 4 57 5. SDN management usecases . . . . . . . . . . . . . . . . . . . 5 58 5.1. Topology display . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Network detection . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Network monitoring . . . . . . . . . . . . . . . . . . . . 8 61 5.4. Alarm and log of new SDN devices and network . . . . . . . 9 62 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 In cloud datacenter, virtualized infrastructure of virtual machines 71 and physcial infrastructure of bare-metal servers are both deployed 72 in the network. Actually Openstack K version, SDN controller, open 73 virtual switch, SDN ToR (top of rack) switches and SDN gateways act 74 as network devices. In this cloud-based deployment, Openstack 75 manages computing, storage and network of the entire system by its 76 modules including neutron, nova, ironic, swift and so on. SDN 77 controller is responsible for the network provision and management. 78 It receives messages of network operations from applications or 79 Openstack neutron and translates them into commands/operations for 80 forwarding devices such as open virtual switch, SDN ToR and SDN 81 gateways. 83 Network administrators face the task of SDN network management after 84 the practical deployment of these heterogeneous devices and networks 85 in several levels. Up to now, our network administrator focuses SDN 86 management on network topology, network detection and monitoring. 88 During research we found out difficulties and confusions in several 89 aspects: 91 (1) Several network layers and virtualization enlarge the range and 92 increase the difficulty in network mangement. 94 (2) Network monitoring needs to be inserted into servers as 95 virtualization is brought in which is different from traditional 96 network devices monitoring. 98 (3) Network management should be nearly real time as network is open 99 to tenants which can be operated at real time. 101 (4) New techniques about the SDN network detection as traditional 102 ping or trace need to be discovered. 104 This draft presents considerations about SDN datacenters management 105 including architecture, use case and potential techniques. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Definition of terms 115 NFV: network function virtualization 117 NVE: network virtualization edge 119 SDN: software defined network 121 SFC: service function chaining 123 ToR: top of rack 125 VM: virtual machine 127 VPC: virtual private cloud 129 ovs: open virtual switch 131 4. SDN network management architecture 133 In considering SDN network management, we focus on the content of 134 topology display, network detection and monitor. In fabric networks, 135 there are controlling nodes and forwarding nodes based on SDN. 136 Besides, traditional physical devices such as normal physical 137 switches for traditional network connection and servers are deployed 138 whose information need to be collected for the topology display and 139 network detection and monitoring. 141 +---------------------------------------------------------------+ 142 |SDN network management | 143 | ------------ ------------ ------------ | 144 | | topology | | detection| | monitor | | 145 | ------------ ------------ ------------ | 146 +------------^-----------------------^--------------------------+ 147 | | 148 |---------------| | 149 | | 150 | |-------------------------+---------------------| 151 | | | | 152 | | | | 153 | +----------+---------+ +-------------+------+ +------------+------+ 154 | | fabric 1 | | | fabric 2 | | | fabric N | | 155 | | | | | | | | | | 156 | | ---------+-------- | | ------------+----- | | -----------+------| 157 | | |controlling node| | | |controlling node| | | |controlling node|| 158 | | ---------+-------- | | ------------+----- | | -----------+------| 159 | | | | | | | | | | 160 | | ---------+-------- | | ------------+----- | | -----------+------| 161 | | | forwarding node| | | | forwarding node| | | | forwarding node|| 162 | | ------------------ | | ------------------ | | ------------------| 163 | | | | | | | 164 | | ------------------ | | ------------------ | | ------------------| 165 | | |physical devices| | | |physical devices| | | |physical devices|| 166 | | ---------+-------- | | ----------+------- | | ----------+-------| 167 | +----------|---------+ +-----------|--------+ +-----------|-------+ 168 | | | | 169 |------------+-----------------------+----------------------| 171 Figure 1: SDN network management architecture 173 5. SDN management usecases 175 5.1. Topology display 177 Commonly, several levels of network is involved which we call tenants 178 network, logical network and physical network. Tenants network is 179 connected with tenants with their network displaying as the abstract 180 models such as the vitual machines, virtual links and virtual 181 gateways which is known as VPC. The difference between tenants 182 network and logical network lies in that tenants network faces to 183 tenants while logical network faces to network administrators. As a 184 result, logical network is displayed as the connection between all 185 the NVE (Network Virtualization Edge). Thus controlling nodes and 186 forwarding nodes are related with logical network. Physical network 187 means the network provides the basic connections between physical 188 devices. All the three networks need to be cooperated with each 189 other. In providing the network topology, logical network needs to 190 be related with physical network in order to provide the overall 191 information including the NVE and its corresponding physical devices. 192 Besides, tenants view their network mainly focusing on their created 193 virtual network. 195 ------------------ 196 | vrouter +------------+-------+---------| 197 -----+------+----- | | | 198 | | | | | 199 --| |-- -----+----- | | 200 | | | FW | | | 201 -----+----- -----+----- ----------- | | 202 | vbridge | | vbridge | -----+----- | 203 --+-----+-- --+-----+-- | LB | | 204 | | | | ----------- | 205 --+-- --+-- --+-- --+-- -----+----- 206 |V M| |V M| |V M| |V M| | NAT | 207 ----- ----- ----- ----- ----------- 209 Figure 2: Tenants network 211 ----------------------------------------------- 212 | Core SW | 213 -----+---------------+----------------+-------- 214 | | | 215 --| | |-- 216 | | | 217 -----+----- -------+-------- -------+-------- 218 | ToR | | hardware vtep| | hardware vtep| 219 -----+----- -------+-------- -------+-------- 220 | | | 221 -------+------- -------+------- -------+-------- 222 | ----------- | | ----------- | | physical | 223 | | vtep | | | | ovs | | | devices | 224 | --+-----+-- | | --+-----+-- | | | 225 | | | | | | | | | NAT/ | 226 | --+-- --+-- | | --+-- --+-- | | FW/ | 227 | |V M| |V M| | | |V M| |V M| | | LB/ | 228 | ----- ----- | | ----- ----- | | VPN | 229 --------------- --------------- ---------------- 231 Figure 3: Overall network 233 5.2. Network detection 235 Network detection aims at trouble-shooting automatically and fault 236 prediction. Traditional detection technologies such as ping and 237 trace can be used in the physical network detection. While in the 238 logical network, detection should also be provided including the 239 connection between NVE and NVE (vtep detection)and connections inner 240 a VPC (service detection). 242 The vtep detection can detect the time delay and packet-loss between 243 vteps. If packet loss are found out in vteps, fault point can be 244 found. Based on this, adminitrators can locate the fault point and 245 be more efficient in recovering the network. 247 - ----------------------------------------------------------- 248 | Core switch | 249 -----+--------------------+-----------------------+-------- 250 | ...(detection)... | | 251 | . . | | 252 -----+--.-- ---.-+------ ------+------ 253 | ToR . | | . ToR | | ToR | 254 -----+--.-- ---.-+------ ------------- 255 | . . | | 256 | . .| | 257 ------+-.--- --- .+------ ------+----- 258 | -----V- | | -V----- | | Physical | 259 | | vtep| | | | vtep| | | devices | 260 | +-----+ | | +-----+ | | | 261 | | | | | | | | | NAT/ | 262 |--+- --+-| |--+- --+-| | FW/ | 263 ||VM| |VM|| ||VM| |VM|| | LB/ | 264 |---- ----| |---- ----| | VPN | 265 ------------ ------------ ------------ 267 Figure 4: vtep detection 269 Service detection verifies the service availability such as VPC or 270 service function chain. Traffic flow inner virtual private cloud of 271 one tenant is simulated in order to get the information of packet 272 loss and time delay. With the collected information of traffic, the 273 availability of tenants' service is detected. 275 ---------------------------------------------------------- 276 | Controlling node | 277 -----------------------------V---------------------------- 278 | | 279 |traffic |information 280 |simulation |collection 281 ------------V--------------------------------------------- 282 | VPC -------------- | 283 | | vRouter1 | | 284 | --V.--------V- | 285 | . | | . (detection) | 286 | ......... | | ........... | 287 | . ----------- ----------- . | 288 | . | | . | 289 | ---V-+----- -----+-V--- | 290 | | vBridge1| | vBridge1| | 291 | -----+----- -----+----- | 292 -----------------/-\----------------------/-\------------ 293 ------ ------ ----- --------- 294 | | | | 295 ----+--- ----+--- ---+---- ----+--- 296 | VM1 | | VM2 | | VM3 | | VM4 | 297 -------- -------- -------- -------- 299 Figure 5: service detection 301 5.3. Network monitoring 303 Network administrator needs to monitor the network in several sides. 304 On one side, administrator can get information of logical network 305 resouces such as subnets, traffic path with the help of data derived 306 from network detection. Besides, administrator needs to monitor 307 physical network devices such as controlling nodes and forwarding 308 nodes with their configurations and status such as performance. From 309 the other side, system resources need to be monitored as well 310 including the tenants information and physical fabric resource 311 information. Real-time monitoring is required. 313 ---------------------------------------------------------- 314 | Network Monitoring | Contents | 315 |--------------------------------------------------------| 316 | logical network resources | subnets, traffic path, | 317 | | virtual interface... | 318 |--------------------------------------------------------| 319 | | controlling nodes, | 320 | physical network resources| physical interface, | 321 | | forwarding nodes... | 322 |--------------------------------------------------------| 323 | system resource |tenants related information,| 324 | |fabric information... | 325 ---------------------------------------------------------- 327 Figure 6: Network monitoring 329 Some uniform network monitoring model needs to be designed for the 330 SDN network monitoring from the management platform. 332 5.4. Alarm and log of new SDN devices and network 334 From the summary of network topology, network detection and 335 monitoring, changes on the network should be reported as log of SDN 336 network. If network abnormal phenomenon happens, alarm should be 337 reported. The content and form of alarm and log needs to be 338 designed. And the pull or push method needs to be recommend. 340 6. Conclusion 342 In SDN network deployment,new challenages are brought in such as 343 several levels of network layers and large-scale range. Network 344 topology, network detetion and monitoring are concentrated by network 345 administrators as netowrk management use case. Uniform models such 346 as topology display and network monitoring are in absence. 348 7. Security Considerations 350 None. 352 8. IANA Considerations 354 None. 356 9. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 360 RFC2119, March 1997, 361 . 363 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 364 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 365 November 1997, . 367 Authors' Addresses 369 Rong Gu (editor) 370 China Mobile 371 32 Xuanwumen West Ave, Xicheng District 372 Beijing 100053 373 China 375 Email: gurong_cmcc@outlook.com 377 Ruixue Wang 378 China Mobile 379 32 Xuanwumen West Ave, Xicheng District 380 Beijing 100053 381 China 383 Email: wangruixue@chinamobile.com 385 Yan Zhuang 386 Huawei 387 101 Software Avenue, Yuhua District 388 Nanjing, Jiangsu 210012 389 China 391 Email: zhuangyan.zhuang@huawei.com