idnits 2.17.1 draft-yin-sdn-sdni-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 date (June 27, 2012) is 4314 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ONIX' on line 365 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force H. Yin 3 Internet-Draft H. Xie 4 Intended status: Informational T. Tsou 5 Expires: December 29, 2012 Huawei Technologies 6 D. Lopez 7 P. Aranda 8 Telefonica I+D 9 R. Sidi 10 ConteXtream 11 June 27, 2012 13 SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS) 14 across Multiple Domains 15 draft-yin-sdn-sdni-00.txt 17 Abstract 19 This draft proposes a protocol SDNi for the interface between 20 Software Defined Networking (SDN) domains to exchange information 21 between the domain SDN Controllers. It defines the concept of a SDN 22 domain; its need, what are its components and how SDNi helps in inter 23 domain communication. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 29, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Motivation Behind SDN . . . . . . . . . . . . . . . . . . . . 5 62 3. SDN Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. SDN Functionality . . . . . . . . . . . . . . . . . . . . . . 8 64 5. SDN Domains . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. SDNi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. SDNi Message . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.2. SDNi Protocol . . . . . . . . . . . . . . . . . . . . . . 11 68 6.3. Practical Considerations . . . . . . . . . . . . . . . . . 11 69 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 11. Informative References . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Software Defined/Driven Networking (SDN) is generally defined as an 79 emerging network architecture where network control is decoupled from 80 forwarding and is directly programmable. This migration of control, 81 formerly tightly bound in individual network devices, into accessible 82 computing devices enables the underlying infrastructure to be 83 abstracted for applications and network services, which can treat the 84 network as a logical or virtual entity. 86 SDN focuses on four key features: 88 o Separation of the control plane from the data plane. 90 o A centralized controller and view of the network. 92 o Open interfaces between the devices in the control 93 plane(controllers) and those in the data plane. 95 o Programmability of the network by external applications. 97 The centralized view and the separation of the control plane and the 98 data plane means that the SDN controller can create a physical 99 topology of how nodes are connected and, based on some combination of 100 algorithms, create paths through the network. Finally, the paths are 101 programmed into the devices' forwarding engines. That allows the SDN 102 controller to better manage traffic flows across the entire network 103 and react to changes quicker and more intelligently. How well the 104 controller defines those paths is, of course, critical to the 105 operation of an SDN. 107 The controller is akin to a computer's operating system (a network- 108 control operating system, if you will) on which applications are 109 written. It communicates with the underlying network hardware 110 (switches and routers) through a protocol such as OpenFlow. 111 Different types of SDN controller software, then, are analogous, in 112 certain respects, to Windows, Linux, and Mac OS X. What's more, just 113 like those computer-based operating systems, today's controller 114 software is not interoperable. 116 As much as OpenFlow and SDN have been conflated and intertwined in 117 the minds of many, we need to understand that SDN controllers are at 118 higher layer of network abstraction, providing a platform for network 119 applications and a foundation for networking programmability. 120 OpenFlow is just an underlying protocol that facilitates interaction 121 between the controller and data-forwarding tables on switches. 123 Due to the great potentials of SDN and the unique requirements of 124 Data Center Networks (DCNs), Data Centers are likely to become a 125 first place where SDN could be deployed. We envision that SDN could 126 be gradually adopted by enterprise networks and then by carrier 127 networks due to its unique, attractive features. When deploying SDN 128 in large- scale distributed networks, we expect to see a collection 129 of deployments limited to portions of a bigger network (referred to 130 as SDN domains). In other words, the operator of a large-scale 131 enterprise / carrier network should divide the whole networks into 132 multiple connected SDN domains, where each of such domains 133 corresponds to a relatively small portion of the whole network. Such 134 a divide-and- conquer methodology not only allows gradual deployment 135 and continuous evolution, but also enables flexible provisioning of 136 the network. 138 With the deployment of multiple SDN domains comes the issue of 139 exchanging information between these domains. This draft defines the 140 concept of an SDN domain and proposes a protocol SDNi as a protocol 141 for interface between inter SDN domains. 143 1.1. Terminology 145 While the definition of software define/driven networks is still 146 "nebulous" to some extent, we refer to as SDN the networks that 147 implement the separation of the control and data/forwarding planes 148 and software defined/driven interactions between these two separated 149 planes. SDN provides capability of network openness in that 150 applications can program networking devices via APIs. The software 151 defined/driven interactions could be similar to OpenFlow or the like. 152 However, how the two separated planes interact is not a focus of this 153 draft. 155 Networking devices: networking devices are hardware devices or 156 software elements capable of forwarding data packets and 157 communicating with Network Operating System (NOS). 159 Network Operating System (NOS): NOS is software responsible for 160 monitoring and controlling a network system. It has whole knowledge 161 of the underlying network topology and resources. NOS provides a 162 programmatic platform based on the abstraction of the underlying 163 network devices to applications by means of appropriate virtual 164 elements, controlled by APIs that provide access to network functions 165 and common functionalities. It facilitates network access and 166 control to applications by translating their requests to actions on 167 networking devices. The traditional device control plane can be 168 built within NOS or above NOS. 170 SDN controller: SDN controller represents a SDN open platform, and 171 responsible for managing the platform. With or without NOS, SDN 172 controller implements SDN's functionality. A general SDN controller 173 is a software entity that opens SDN APIs to applications, and 174 translates application's request to actions on network devices using 175 proprietary protocol or OpenFlow -like protocol with or without NOS's 176 supports. The SDN controller can reside in an NOS or run separately 177 on a server in network. 179 SDN controller-based applications: Applications interacting with 180 underlying networks via SDN controller. They can run inside the 181 controller or they can be (virtual) appliances distributed throughout 182 the network and serve some (specific) high-function and have the 183 controller configure the network devices to steer traffic through 184 those elements selectively according to SDN policy. 186 Some controllers leverage OpenFlow exclusively, and others are (or 187 will be) capable of accommodating other protocols and mechanisms to 188 achieve the same practical result. A normal OpenFlow controller can 189 be integrated within NOS or run within SDN controller depending on 190 implementation. 192 SDN-capable devices: networking devices are capable of communicating 193 with NOS/SDN controller using proprietary protocol or standard 194 protocol, like OpenFlow. The devices which do not support the 195 proprietary protocol or OpenFlow are normal devices. 197 An SDN domain is a portion of a network infrastructure, consisting of 198 numerous connected networking devices that are SDN-capable and NOS 199 that supports proprietary protocol or OpenFlow. A SDN domain 200 controller (SDN controller) can cover multiple NOSs, means it can 201 communicating with multiple NOSs via some proprietary protocol or NOS 202 APIs, or it can communicates with OpenFlow-enabled devices directly 203 if OpenFlow protocol is supported in the controller. An SDN domain 204 can be as small as a sub-network of a dozen devices or as large as a 205 medium/large data center network. An network can consist of one or 206 many SDN domains. Hence an inter-SDN domain protocol is needed. 208 2. Motivation Behind SDN 210 There has been a great deal of innovation in networking software but 211 not that much in networking. Networks are still stuck in the past 212 with routing algorithms that change very slowly or with primitive 213 network management. Computation and storage have been virtualized, 214 creating a more flexible and manageable infrastructure, but networks 215 are still hard to manage. Networking is built with limited view of 216 application needs. Networks used to be simple: basic Ethernet/IP 217 straightforward, easy to manage but new application requirements have 218 led to control plane complexities. Each control requirement leads to 219 new mechanisms and so networks continue to grow more complex. 221 By simplifying network's structures and allowing applications to take 222 part in the control of networks, SDN provides innovative principles 223 of networking system construction. With the trends of the network 224 development that moving from networks to more and more services and 225 applications, applications are taking more roles in network routing 226 decisions and affecting the traditional network functionalities and 227 behaviors. As an interaction and control point between applications/ 228 services and underlying networks, SDN controller is a key point in 229 SDN networks and clearly a SDNi protocol among controllers is clearly 230 a necessity in our opinion. 232 3. SDN Architecture 234 As software-defined networking gains traction, vendors and 235 enterprises will generally adopt a three-tiered architecture as seen 236 in Figure 1. 238 +-----+ +-----+ 239 | App | | App | 240 +-----+ +-----+ 241 | | 242 | RESTFUL APIs | 243 | | 244 +--------------------------+ SDNi +-----------------+ 245 | | protocol | | 246 | SDN Controller |<---------->| SDN Controller | 247 | | | | 248 +--------------------------+ +--------------- -+ 249 / \ \ 250 /<-----+ \ ----- 251 / | \ \ 252 / | \ \ 253 +-----------+ | +-----------+\ 254 | | proprietary | | \ 255 | NOS | protocol/API | NOS | \ 256 | | | | | \ 257 +-----------+ | +-----------+ \ 258 / | \ | / \ \ 259 / | \<---+ / \ \ 260 ..... / | \ / \ \ .... 261 : / | \ / \ \ : 262 : +----+ +----+ +----+ +----+ +----+ +-------+ : 263 : | ND | | ND | | ND | | ND | | ND | | OF SW | : 264 : +----+ +----+ +----+ +----+ +----+ +-------+ : 265 : : 266 : : 267 : SDN Domain : 268 : ND: Networking Device : 269 : OF SW: OpenFlow-enabled switch : 270 :.................................................................: 272 Figure 1: An Architecture For SDN 274 The architecture's first tier will involve the physical network 275 equipment, including Ethernet switches and routers. This forms the 276 dataplane. The middle tier consists of the controllers that 277 facilitate setting up and tearing down flows and paths in the network 278 leveraging information about capacity and demand obtained from the 279 networking gear through which the traffic flows. This forms the 280 control plane, NOS and SDN controller/platform over it. The top tier 281 will involve applications to direct security, management and other 282 specific functions through the controller. However, instead of 283 relying on proprietary software running on each switch to control its 284 forwarding behavior, switches in a SDN architecture are controlled by 285 a Network OS (NOS) that collects information and manipulates their 286 low-level forwarding plane, providing an abstract model of the 287 network topology to the SDN controller hosting the applications. 288 Applications can adapt the network behavior to suit specialized 289 requirements, for example, providing network virtualization services 290 that allow multiple logical networks to share a single physical 291 network - similar to the way in which a hypervisor allows multiple 292 virtual machines to share a single physical machine. 294 These controller-based applications will serve the same roles that 295 physical appliances play in the network today. For example, network 296 architects who are building software-defined networks could deploy 297 applications like a virtual load balancer, a virtual intrusion 298 detection system (IDS), or a virtual firewall on a controller. The 299 application could tap into information the controller possesses about 300 traffic patterns, application data and capacity. Cloud computing 301 applications could be a big beneficiary of software-defined 302 networking and OpenFlow because these technologies make provisioning 303 in a multi-vendor virtual environment much simpler. For instance a 304 controller-based load balancing application could automate the 305 movement of workloads among virtual machines by using the 306 controller's view of the capacity of individual network devices. 308 SDN controller is a software module in a SDN domain; logically it 309 represents the highest control point in a SDN domain network, and 310 physically it can reside in NOS or run independently at a separate 311 server. SDN controller provides north- bound APIs to user 312 applications, and interacts with NOS to collect network information 313 for applications. 315 4. SDN Functionality 317 This section provides a detailed explanation of the role of SDN 318 controller in SDN. 320 SDN is constructed through the separation of control plane and 321 forwarding plane of networking devices. The decoupling is achieved 322 by turning the network control problem into a state management 323 problem, and only exposing the state to be managed to the 324 application, and not the mechanisms by which it arrived. 325 Applications operate over control traffic, flow table state, 326 configuration state, port state, counters, etc. However, how this 327 data is pulled into the controller, and how any changes are pushed 328 back down to the switch is not the application's concern. It can 329 just use the controller API to modify network state which in turn 330 will be translated to necessary commands on the relevant devices to 331 have the new state correctly applied on the network. 333 SDN controller should provide following functionality: 335 o Provide northbound APIs for applications so they can program 336 underlying network properties such as bandwidth assignments, 337 network isolation, routing properties, redundancy properties, or 338 security requirements. 340 o Provide covered SDN domain network topology view to applications 341 so that applications can define data flow and flow path within the 342 view. 344 o Respond and adapt to the network conditions and provide event- 345 handling mechanisms for applications so that they can receive 346 feedback and adapt accordingly. 348 o Have covered SDN domain network services and resources views so 349 that the controller can coordinate application's requests. 351 o Work with NOS/control plane to collect underlying device 352 information and translate application's request to actions on 353 network devices and feed into NOS/control plane. 355 o Act as the controller of physical devices, such as the OpenFlow 356 control mechanism if such mechanism is not implemented in NOS[1]. 358 5. SDN Domains 360 An SDN domain is a portion of the network determined by the network 361 operator. It has a SDN controller to control the domain, it can 362 cover multiple NOS or communicate with some SDN-capable devices 363 directly. Each NOS typically consists of numerous inter-connected 364 SDN-capable devices. An example of such NOS is illustrated in 365 [ONIX]. The SDN controller aggregates network topology views from 366 multiple NOS and maintain a global network view of networks covered 367 by the domain. The controller is responsible for dispatching and 368 disseminating application's request to corresponding NOS. Two SDN 369 domains are adjacent if there is a physical link between two 370 underlying networks. 372 Inside each SDN domain, its controller may define domain-specific 373 policies on information importing from devices, aggregating, and 374 exporting to external entities. Such policies may not be made 375 public; therefore, other domain controllers may not know the 376 existence of such policies for any given SDN domain. 378 When receiving an application request for certain network resources, 379 the SDN controller should decide if the request can be satisfied. If 380 it can be satisfied, the controller should instruct the devices in 381 its domain by updating them with a set of data/forwarding rules so 382 that the devices could implement such rules and fulfill the request. 384 6. SDNi 386 SDNi is a protocol for interfacing SDN domains. It is responsible 387 for coordinating behaviors between SDN controllers and exchange 388 control and application information across multiple SDN domains. 389 SDNi is an "east-west" protocol between SDN controllers, as an 390 analogy to OpenFlow being a "north-south" protocol between NOS and 391 Network devices. As such, SDNi should be a protocol implemented by 392 the NOS (the same as OpenFlow or any other control protocols as 393 mentioned above) and how the applications/SDN controllers that run in 394 the NOS use this protocol (i.e. what is the API to use it) is out of 395 scope of this document. 397 SDNi protocol should be able to 399 o Coordinate flow setup originated by applications, containing 400 information such as path requirement, QoS, SLA etc. across 401 multiple SDN domains. 403 o Exchange reachability information to facilitate inter-SDN routing. 404 This will allow a single flow to traverse multiple SDNs and have 405 each controller select the most appropriate path when multiple 406 such paths are available. 408 SDNi depends on the types of available resources and capabilities 409 available and managed by the different controllers in each domain. 410 Hence it is important to implement SDNi in a descriptive and open 411 manner so that new capabilities offered by different types of 412 controllers will be supported. 414 Since SDN in essence allows for innovation, it is important that data 415 exchanged between controllers will be dynamic in nature, i.e. there 416 should be some meta-data exchange that will allow SDNi to exchange 417 information about unknown capabilities. 419 6.1. SDNi Message 421 The types of messages exchanged via SDNi can be: 423 o Reachability update 425 o Flow setup/tear-down/update request (including application 426 capability requirement such as QoS, BW, latency etc.) 428 o Capability update (including network related capabilities such as 429 BW, QoS etc. and system and software capabilities available inside 430 the domain). 432 6.2. SDNi Protocol 434 SDNi is used to exchange information between SDN domains that are 435 under the control of a single network operator or collaborating 436 operators. One way to implement SDNi is to use extension of BGP and 437 SIP over SCTP protocols to exchange information. 439 6.3. Practical Considerations 441 SDN domains are built by network operator for flexible administration 442 purpose. It depends on the scale of underlying network that the 443 operator decides how to divide whole network into SDN domains. For 444 some small-scale data centers, only one SDN domain may be enough. 445 For a Service Provider with large carrier network, it is most likely 446 better to divide the network into SDN domains as centralizing the 447 control onto a single NOS/controller will create a bottleneck. For 448 example, Operator can divide its network into different SDN domains 449 based on physical locations. It can lease such part of its network 450 to local content provider, etc. Such deployment scenario requires an 451 SDN controller providing powerful network service capability to 452 applications. 454 Also defining domains and interconnections between them involves more 455 than simple connections between SDN boxes; it requires to consider 456 various aspects such as to work out how their network topologies 457 connect together, which neighbor controller boxes to talk to and how 458 to get their addresses, what rights and policies control the 459 conversation etc. 461 Other aspects to be considered are who is allowed to deploy 462 'programs' on the SDN infrastructure what actions can a 'program' 463 execute depending on who deployed them: the SDN network manager is 464 likely in control to deploy 'programs' on the SDN infrastructure. 465 The focus then is on how the deployed programs might affect other 466 domains and what mechanism we want to use to communicate this effect 467 to the other domains. 469 7. Conclusions 471 Add any conclusions 473 8. Acknowlegements 475 The authors would like to thank Aditi Vira for editing the draft. 477 9. Security Considerations 479 o What actions are 'applications' allowed to execute? 481 o How is the security policy propagated to other SDN domains. 483 o An application should not be able to do a DoS attack (either 484 willingly or unwillingly) 486 10. IANA Considerations 488 This document makes no specific request of IANA. 490 Note to RFC Editor: this section may be removed on publication as an 491 RFC. 493 11. Informative References 495 [1] Xie, H., Yin, H., Tsou, T., and V. Hilt, 496 "draft-xie-alto-sdn-use-cases-00.txt", June 2012. 498 Authors' Addresses 500 Hongtao Yin 501 Huawei (USA) 502 2330 Central Expy 503 Santa Clara, CA 95050 504 USA 506 Phone: 507 Email: Hongtao.yin@huawei.com 508 Haiyong Xie 509 Huawei & USTC 510 2330 Central Expy 511 Santa Clara, CA 95050 512 USA 514 Phone: 515 Email: Haiyong.xie@huawei.com 517 Tina Tsou 518 Huawei Technologies (USA) 519 2330 Central Expressway 520 Santa Clara, CA 95050 521 USA 523 Phone: 524 Email: Tina.Tsou.Zouting@huawei.com 526 Diego R. Lopez 527 Telefonica I+D 528 Don Ramon de la Cruz, 84 529 Madrid, 28006 530 Spain 532 Phone: 533 Email: diego@tid.es 535 Pedro Andres Aranda 536 Telefonica I+D 537 Don Ramon de la Cruz, 84 538 Madrid, 28006 539 Spain 541 Phone: 542 Email: pedro.aranda@tid.es 543 Ron Sidi 544 ConteXtream 545 3600 West Bayshore Rd. 546 Palo Alto, CA 94303 547 USA 549 Phone: 550 Email: ron@contextream.com