idnits 2.17.1 draft-gu-sdnrg-sdn-controller-requirement-01.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 are 27 instances of too long lines in the document, the longest one being 2 characters 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 seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2016) is 2843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2234' is defined on line 528, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 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 Jinzhu. Wang 5 Expires: January 7, 2017 China Mobile 6 July 6, 2016 8 SDN Controller Requirement 9 draft-gu-sdnrg-sdn-controller-requirement-01 11 Abstract 13 The requirements of SDN controllers including fundamental technical 14 requirements, requirements of the SDN controller architecture and the 15 requirements of the SDN controller functionality are provided. All 16 these requirements raised are focused on the scalability, 17 reliability, programmability, intercommunity, security and the 18 network management of the SDN controller.Based on the requirements, 19 we have realized the SDN controller based on Opendaylight foused on 20 cloud datacenter.Due to realization, the interface between other 21 devices besides the ovs is not included up to now, while in the 22 actual design, some connections between controller and the forwarding 23 devices such as SDN gateway, firewall, and NAT are added into the 24 requirement of controller. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 7, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Fundamental technical requirements of SDN controllers . . . . 3 60 4. Requirements of the SDN controller architecture . . . . . . . 3 61 5. Requirements of the SDN controller functionality . . . . . . 6 62 6. Development of controller based on opendaylight . . . . . . . 8 63 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Software-defined networking (SDN) is an intelligent network, 72 especially used in Data Centers, with configuration and operation 73 through a centralized software controller. SDN controller is a core 74 entity of the SDN architecture indicating how the network behaves and 75 where the traffic is sent. Network intelligence is logically 76 centralized in software-based SDN controllers that maintain an 77 abstract view of the network, which appears to applications and 78 policy engines as a single, logical switch. 80 Due to the importance of SDN controllers to the SDN architecture, the 81 requirements of SDN controllers should be come up with. The 82 requirements are divided into three parts: fundamental technical 83 requirements, requirements of the SDN controller architecture and the 84 requirements of the SDN controller functionality. 86 Based on the requirement of controller, in the actual design we have 87 found out that the connection between controller with the ovs is not 88 enougn. Thus more development on the controller is needed. 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. Fundamental technical requirements of SDN controllers 98 The fundamental technical requirements include scalability, 99 reliability, programmability, intercommunity, security, and the 100 network-based management. 102 Scalability: 104 SDN controller should meet the requirement of scalability in order to 105 adapt the changes and adjustments of the network. The computing and 106 controlling ability can be extended as the performance of hardware 107 increases. 109 Reliability: 111 SDN controller should meet the carrier-level requirement with rapid 112 fail-over mechanism. 114 Programmability: 116 SDN controller should offer APIs in order to provide rapid deployment 117 of new service through executing scripts such as Python and Java or 118 loading third-party module dynamically. 120 Intercommunity: 122 One SDN controller should support standard protocols in interacting 123 with other SDN controllers or with traditional network. 125 Security: 127 SDN controller should qualify the security requirements including the 128 communication security between the controllers and the switches, the 129 access control security of controllers and switches, TLS and IPsec 130 mechanism of the communication channels, DoS attacks prevention, 131 digital certificate of third-party support. 133 Network-based management: 135 SDN controller should provide tools for basic network management and 136 trouble diagnosis, such as secure access, status report, statistics, 137 forwarding operations and so on. 139 4. Requirements of the SDN controller architecture 141 SDN controller should support both traditional distributed forwarding 142 and centralized forwarding based on openflow. SDN controller 143 interacts with switch through southbound interface. 145 SDN controller is logically divided into several models, including 146 subsystem of protocol, forwarding abstraction layer (FAL), topology 147 management, route management, host management, flow table management, 148 interface management, database management, OAM interface management 149 and inter-application subsystems. 151 ---------------------------------------------------------------------- 152 | |------------------| |------------------| | 153 | | Orchestrator | | EPC | | 154 | |------------------| |------------------| | 155 | External application layer | 156 -----+---------------------------+------------------------------------ 157 | | 158 | | 159 | -------------------------+------------------------- 160 | | |------------------| |--------------| | 161 | | | L2/L3 forwarding | | ARP reply | | 162 | | |------------------| |--------------| | 163 | | | 164 | | |-----| |-----| |-----| |-----| | 165 | | | BGP | | IGP | | TE | | ... | | 166 | | |-----| |-----| |-----| |-----| | 167 | | Internal application layer | 168 | --------------------------------------------------- 169 | 170 -------+------------------------------------------------------------------ 171 | -------- ---------------------------------------------------- -------- | 172 | | | | | | | | 173 | | | | Route management | | | | 174 | | | | | | | | 175 | | | ---------------------------------------------------| | | | 176 | | | | | | 177 | | | |-----------||-----------||-----------||-----------| | | | 178 | | | | Topology || Host || Flow table|| Interface | | | | 179 | | | | Management|| Management|| Management|| Management| | | | 180 | | | |-----------||-----------||-----------||-----------| | | | 181 | | | | | | 182 | | DB | ---------------------------------------------------- | OAM | | 183 | |subsys| | Forwarding abstraction layer | |manage| | 184 | | | ---------------------------------------------------- | ment | | 185 | | | ---------------------------------------------------- | | | 186 | | | | Protocol subsystem | | | | 187 | | | | | | | | 188 | | | | ------------ ------------ ---------- --------- | | | | 189 | | | | | Openflow | | OF-Config| | BGP-LS | | XMPP | | | | | 190 | | | | ------------ ------------ ---------- --------- | | | | 191 | | | | ------------ ------------ ---------- | | | | 192 | | | | | OVSDB | | Netconf | | ... | | | | | 193 | | | | ------------ ------------ ---------- | | | | 194 | | | ---------------------------------------------------- | | | 195 | -------- -------- | 196 -------------------------------------------------------------------------- 198 Figure 1: Sample Calibration Permutation 200 Protocol subsystem: 202 The protocol subsystem of the SDN controller focuses on southbound 203 interface with protocols such as openflow, OF-Config, BGP-LS, OVSDB, 204 Netconf, XMPP and so on. 206 Forwarding abstraction layer (FAL): 208 FAL translates the different forwarding plane into the unified 209 interface upside in order to realize the abstraction of SDN 210 controller node. 212 Topology management: 214 Topology is calculated through the status of port reported by the 215 switch with the protocol such as LLDP, BGP-LS and so on. Logical 216 networks are supported by SDN controller. Physical network can be 217 divided into several logical networks with physical port and host 218 corresponding to the virtual networks. 220 Route management: 222 Centralized computing of every virtual network is supported by 223 controller. Forwarding path is calculated according to the ability 224 of switch and the constraint conditions such as link cost, and 225 bandwidth and network information. 227 Host management: 229 Host management takes the function of MAC and ARP learning. Host 230 position and ARP information is recorded and aging at a certain time. 232 Flow table management: 234 Basic functions such as forwarding table storage, routing coalescence 235 and re-forwarding are realized by the flow table management. It's 236 suggested that both distributed and centralized forwarding models are 237 supported. 239 Interface management: 241 Interface configurations are maintained in the interface management, 242 including dynamic and static interface configuration information. 243 Virtual ARP table is also generated in the interface management 244 model. 246 Database management: 248 Forwarding table and openflow table are managed in the database 249 management with data synchronization. 251 OAM interface management: 253 Configuration command of command-line terminal and visualized network 254 management server is written into database. Management interface is 255 provided. 257 Inter-application subsystem: 259 Inter-application subsystem supports the interface to openstack and 260 cloud platform by restful. Layer 2 and Layer 3 forwarding, traffic 261 engineering, and ARP reply features are equipped. IGP/BGP protocols 262 are supported. 264 5. Requirements of the SDN controller functionality 266 Due to the fundamental techinical requirements of SDN controllers, 267 the follow functionality aspects need to be considered. 269 1. Requirement of multi-tenants and self-service 271 Multi-tenants with their self-service are typical scenarios of SDN. 272 Multi tenants are existed in data centers with several virtual 273 networks per tenant. IP address pool is allocated in every virtual 274 network. Virtual network is logically isolated with each other. 275 Same IP addresses can be assigned to different tenants. Virtual 276 routers are used in different virtual network communications. 278 2. Requirement of network function 280 Basic network functions SDN controller needs to support list as 281 follows. 283 (a) The number of tenants should be over 4000 by tunneling technique. 285 (b)Virtual machines in one subnet can communicate with each other by 286 unicast of layer 2. 288 (c) Virtual machines in different subnets can't communicate with each 289 other. 291 (d)Virtual machines in different subnets can communicate with other 292 by configuring a virtual router. 294 (e)Virtual machine can access to the network by assigning a public IP 295 address. 297 (f)Tenants can translate private IP address into public IP address by 298 NAT. 300 (g)Different tenants can use the same IP address and VLAN ID. 302 (h)Network can be recovered rapidly when fails. 304 (i)ARP Broadcast storm should be suppressed. 306 (j) Equal-Cost Load Sharing is supported in both underlay and overlay 307 networks. 309 (k)Traditional protocols such as IGP , BGP and others are supported. 311 3. Requirement of administrator features 313 Administrators are responsible for tenants creation and deletion, 314 network creation and deletion, unbinding the relation between tenants 315 and network, query for tenants' information, query for physical and 316 virtual information, virtual machine immigration and so on. 318 4. Requirement of network management 320 The information of switches, hosts and network topologies can be 321 queried by management. Monitoring on network traffic is supported by 322 network management. Network management is also responsible for 323 network policies release and flow table configuration. 325 5. Requirement of reliability and scalability 327 Reliability of SDN controller relies on active-standby mode by 328 controller node, secure connection between controller and switch 329 nodes, multi-controllers based on openflow and so on. Scalability of 330 SDN controller relies on node upgrading without service interruption 331 and unique node upgrade in the distribute systems without any 332 influence on the whole system. 334 6. Requirement of performance 335 Performance of SDN controller is reflected in the number of 336 forwarding nodes supported per controller node, the capacity of flow 337 table per controller node, speed of forwarding table processing per 338 node and standby time of controller node. 340 7. Requirement of northbound and southbound interface 342 The northbound interface of the SDN controller is to achieve the 343 requirement of the administrators and network management. While the 344 southbound interface of the SDN controller is including the interface 345 of status/configuration information such as OVSDB, OF-Config, XMPP 346 and the interface of routing/forwarding information such as Openflow, 347 XMPP, IGP, BGP and so on. 349 8. Requirement of processing flow 351 The process of packet-forwarding network networks added or modified, 352 physical network topology discovered and network failure advertised 353 should be required. 355 6. Development of controller based on opendaylight 357 Based on opendaylight, we had a trial of development of controller 358 focused on cloud datacenter. In China Mobile cloud datacenter, 359 virtual private cloud and basic service function chain is provided. 360 The architecture includes application, openstack K version, 361 controller,virtual machines with ovs, bare-metal server with SDN ToR, 362 virtual network functions with VNF manager,physical NAT,physical 363 firewall, physical load balancer and physical VPN. 365 ------------------------------------------------------------ 366 | application | 367 -----------------------------+------------------------------ 368 | 369 -----------------------------+------------------------------ 370 | openstack | 371 -----------------------------+------------------------------ 372 | 373 ----------------+------------------ 374 | SDN controller | 375 -+--------------+-----------+------ 376 | | | 377 | | | 378 |----------- | ------------- 379 | | | 380 | +-----+----+ | 381 | | SDN ToR | | 382 ------------ +-----+----+ ------+----- 383 | ------- | | | Physical | 384 | | OVS | | ------------ | devices | 385 | +-----+ | | | | | 386 | | | | |bare-metal| | NAT/ | 387 |--+- --+-| | Server | | FW/ | 388 ||VM| |VM|| | | | LB/ | 389 |---- ----| | | | VPN | 390 ------------ ------------ ------------ 392 Figure 2: Architecture of SDN datacenter deployment 394 1.Connection between controller and ovs 396 Controller configures ovs with flow table of Layer2, Layer3, 397 ACL,security group, meter and so on.The connection between controller 398 and ovs has been defined in openflow. 400 2.Connection between controller and top of rack switch 402 Controller configures physical switch with the function of Lay2, 403 ACL,security group, meter and so on. Because of the limitation of 404 the physical switch, Lay3 function has been taken by SDN gateway. 406 3.Connection between controller and SDN gateway 408 SDN gateway is deployed as the outside of datacenter with the 409 function of vxlan encapsulation and de-encapsulation and acting as 410 v-router of north-south traffic and east-west traffic. 412 In connection with the SDN gateway, the interface of Controller lists 413 as: 415 (a)Ctreate vrouter with the information of vrouter-list, vrouter 416 UUID, vrouter's management ip and the tenant's id. 418 (b)Delete vrouter with the information of vrouter-list, vrouter UUID 419 and the tenant's id. 421 (c)Check vrouter with the information of vrouter UUID. 423 (d)Create interface of the vrouter which corresponds to sub-network 424 with information of router interfaces, vrouter UUID, interface UUID, 425 interface ip, interface netmask, interface macaddress, interface 426 attached tunnel, and tenand's id. 428 (e)Detele interface of the vrouter with the information of router 429 interfaces, interface UUID, and tenant's id. 431 (f)Check interface of the vrouter with the information of interface 432 UUID. 434 (g)Create vxlan tunnel with the informaion of tunnels, tunnel id, 435 tunnel source ip, tunnel destination ip, tunnel type, and tenant's 436 ip. 438 (h)Check the vxlan tunnel by tunnel id. 440 (i)Associate interface of the vrouter with tunnel including the 441 information of router interface, tunnel id, interface UUID, vxlan id, 442 and tenant's id. 444 (j)Add virtual machines or physical servers with the information of 445 host id, host ip address, host mac address, vxlan id, tunnel id and 446 tenant's id. 448 (k)Delete virtual machines or physical servers with the information 449 of host id and tenant's id. 451 (l)Check virtual machines or physical servers with the information of 452 host id. 454 4.Connection between controller and NAT 456 Nat device is taken the function as network address translation 457 including 1:1 NAT and N:1 NAT. 459 In connection with the NAT device, the interface of Controller lists 460 as: 462 (a) Create the routing configuration with the information of routing 463 id, routing prefix, the ip of next hop and the tenant's id. 465 (b)Delete the routing with the information of routing id and tenant's 466 id. 468 (c)Check the routing with the information of routing id. 470 (d)Create vlan with the information of vlan id, vlan port,vlan ip, 471 vlan netmask and tenant's id. 473 (e)Delete vlan with the information of vlan id and tenant's id. 475 (f)Check the vlan with the information of vlan id. 477 (g)Create N:1 NAT with the information of N:1 NAT id,vrouter UUID,NAT 478 ip address, NAT netmask, NAT gateway ip address, and tenant's id. 480 (h)Delete N:1 NAT with the information of N:1 NAT id and tenant's id. 482 (i)Check N:1 NAT with the information of N:1 NAT id. 484 (j)Create 1:1 NAT with the information of 1:1 NAT id,vrouter UUID, 485 1:1 NAT out ip address, 1:1 NAT in ip address and tenant's id. 487 (k)Delete 1:1 NAT with the information of 1:1 NAT id and tenant's id. 489 (l)Check 1:1 NAT with the information of 1:1 NAT id. 491 5.Connection between controller and firewall 493 Firewall is depolyed in the SDN network acting as the barrier 494 preventing some specific communications. 496 TBD 498 6.Connection between controller and Loadbalance 500 Loadbalancer is deployed in the SDN network distributing workloads 501 across mutiple computing resources. 503 TBD 505 7. Conclusion 507 All the requirements provided above are recommended to be taken into 508 consideration for the SDN controllers.And the development on 509 controller based on opendaylight can confirm these requirements.In 510 the actual design, connections between controller and ovs, SDN 511 gateway, firewall, LB and NAT should be taken into consideration. 513 8. Security Considerations 515 None. 517 9. IANA Considerations 519 None. 521 10. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 529 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 530 November 1997, . 532 Authors' Addresses 534 Rong Gu (editor) 535 China Mobile 536 32 Xuanwumen West Ave, Xicheng District 537 Beijing 100053 538 China 540 Email: gurong_cmcc@outlook.com 542 Chen Li 543 China Mobile 544 32 Xuanwumen West Ave, Xicheng District 545 Beijing 100053 546 China 548 Email: lichenyj@chinamobile.com 549 Jinzhu Wang 550 China Mobile 551 32 Xuanwumen West Ave, Xicheng District 552 Beijing 100053 553 China 555 Email: wangjinzhu@chinamobile.com