idnits 2.17.1 draft-haleplidis-sdnrg-layer-terminology-07.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 (August 1, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SDNSecurity' is defined on line 1396, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-04 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG E. Haleplidis, Ed. 3 Internet-Draft University of Patras 4 Intended status: Informational K. Pentikousis, Ed. 5 Expires: February 2, 2015 EICT 6 S. Denazis 7 University of Patras 8 J. Hadi Salim 9 Mojatatu Networks 10 D. Meyer 11 Brocade 12 O. Koufopavlou 13 University of Patras 14 August 1, 2014 16 SDN Layers and Architecture Terminology 17 draft-haleplidis-sdnrg-layer-terminology-07 19 Abstract 21 Software-Defined Networking (SDN) can be defined as a new approach 22 for network programmability. Network programmability in this context 23 refers to the capacity to initialize, control, change, and manage 24 network behavior dynamically via open interfaces as opposed to 25 relying on closed-box solutions and their associated proprietary 26 interfaces. SDN emphasizes the role of software in running networks 27 through the introduction of an abstraction for the data forwarding 28 plane and, by doing so, separates it from the control plane. This 29 separation allows faster innovation cycles at both planes as 30 experience has already shown. However, there is increasing confusion 31 as to what exactly SDN is, what is the layer structure in an SDN 32 architecture and how do layers interface with each other. This 33 document aims to answer these questions and provide a concise 34 reference document for SDNRG, in particular, and the SDN community, 35 in general, based on relevant peer-reviewed literature and documents 36 in the RFC series. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 2, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. SDN Layers and Architecture . . . . . . . . . . . . . . . . . 6 75 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Network Devices . . . . . . . . . . . . . . . . . . . . . 11 77 3.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. Management Plane . . . . . . . . . . . . . . . . . . . . 13 79 3.5. The Control vs. Management Plane Debate . . . . . . . . . 14 80 3.5.1. Timescale . . . . . . . . . . . . . . . . . . . . . . 14 81 3.5.2. Persistence . . . . . . . . . . . . . . . . . . . . . 15 82 3.5.3. Locality . . . . . . . . . . . . . . . . . . . . . . 15 83 3.5.4. CAP Theorem Insights . . . . . . . . . . . . . . . . 15 84 3.6. Network Services Abstraction Layer . . . . . . . . . . . 16 85 3.7. Application Plane . . . . . . . . . . . . . . . . . . . . 17 86 4. SDN Model View . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.1. ForCES . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.3. OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . 20 90 4.4. I2RS . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 4.5. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 4.6. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 4.7. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 95 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 9. Informative References . . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction 103 Software-Defined Networking (SDN) is a relevant new term for the 104 programmable networks paradigm [PNSurvey99][OF08]. In short, SDN 105 refers to the ability of software applications to program individual 106 network devices dynamically and therefore control the behavior of the 107 network as a whole [NV09]. [RFC7149] points out that SDN is a set of 108 techniques used to facilitate the design, delivery and operation of 109 network services in a deterministic, dynamic, and scalable manner. 111 A key element in SDN is the introduction of an abstraction between 112 the (traditional) forwarding and control planes in order to separate 113 them and provide applications with the means necessary to 114 programmatically control the network. The goal is to leverage this 115 separation, and the associated programmability, in order to reduce 116 complexity and enable faster innovation at both planes [A4D05]. 118 The historical evolution of the programmable networks R&D area is 119 reviewed in detail in [SDNHistory][SDNSurvey], starting with efforts 120 dating back to the 1980s. As Feamster et al. document [SDNHistory], 121 many of the ideas, concepts and concerns are applicable to the latest 122 R&D in SDN, and SDN standardization we may add, and have been under 123 extensive investigation and discussion in the research community for 124 quite some time. For example, Rooney et al. [Tempest] discuss how 125 to allow third-party access to the network without jeopardizing 126 network integrity, or how to accommodate legacy networking solutions 127 in their (then new) programmable environment. Further, the concept 128 of separating the control and data planes, which is prominent in SDN, 129 has been extensively discussed even prior to 1998 [Tempest][P1520], 130 in SS7 networks [ITUSS7], Ipsilon Flow Switching [RFC1953][RFC2297] 131 and ATM [ITUATM]. 133 SDN research often focuses on varying aspects of programmability, and 134 we are frequently confronted with conflicting points of view 135 regarding what exactly SDN is. For instance, we find that for 136 various reasons (e.g. work focusing on one domain and therefore not 137 necessarily applicable as-is to other domains), certain well-accepted 138 definitions do not correlate well with each other. For example, both 139 OpenFlow [OpenFlow] and NETCONF [RFC6241] have been characterized as 140 SDN interfaces, but they refer to control and management 141 respectively. 143 This motivates us to consolidate the definitions of SDN in the 144 literature and correlate them with earlier work in IETF and the 145 research community. Of particular interest is, for example, to 146 determine which layers comprise the SDN architecture and which 147 interfaces and their corresponding attributes are best suitable to be 148 used between them. As such, the aim of this document is not to 149 standardize any particular layer or interface but rather to provide a 150 concise reference document which reflects current approaches 151 regarding the SDN layers architecture. We expect that this document 152 would be useful to upcoming work in SDNRG as well as future 153 discussions within the SDN community as a whole. 155 This document addresses the work item in the SDNRG charter named 156 "Survey of SDN approaches and Taxonomies", fostering better 157 understanding of prominent SDN technologies in a technology-impartial 158 and business-agnostic manner. It is meant as a common base for 159 further discussion. As such, we do not make any value statements nor 160 discuss the applicability of any of the frameworks examined in this 161 draft for any particular purpose. Instead, we document their 162 characteristics and attributes and classify them, thus providing a 163 taxonomy. This document does not intend to provide an exhaustive 164 list of SDN research issues; interested readers should consider 165 reviewing [SLTSDN] and [SDNACS]. In particular, [SLTSDN] overviews 166 SDN-related research topics, e.g. control partitioning, which is 167 related to the CAP theorem (Section 3.5.4) discussed later in this 168 document. 170 This document does not constitute a new IETF standard nor a new 171 specification but obtained the consensus within SDNRG to be published 172 in the IRTF Stream as per [RFC5743]. 174 The remainder of this document is organized as follows. Section 2 175 explains the terminology used in this document. Section 3 introduces 176 a high-level overview of current SDN architecture abstractions. 177 Finally, Section 4 discusses how the SDN Layer Architecture relates 178 with prominent SDN-enabling technologies 180 2. Terminology 182 This document uses the following terms: 184 Software-Defined Networking (SDN) - A programmable networks 185 approach that supports the separation of control and forwarding 186 planes via standardized interfaces. 188 Resource - A physical or virtual component available within a 189 system. Resources can be very simple or fine-grained, e.g. a port 190 or a queue; or complex, comprised of multiple resources, e.g. a 191 network device. 193 Network Device - A device that performs one or more network 194 operations related to packet manipulation and forwarding. This 195 reference model makes no distinction whether a network device is 196 physical or virtual. A device can also be considered as a 197 container for resources and can be a resource in itself. 199 Interface - A point of interaction between two entities. In case 200 the entities are not in the same physical location, the interface 201 is usually implemented as a network protocol. In case the 202 entities are collocated in the same physical location the 203 interface can be a network protocol or a software Application 204 Programming Interface (API). 206 Application (App) - An application in the context of SDN is a 207 piece of software that utilizes underlying services to perform a 208 function. Application operation can be parametrized, for example 209 by passing certain arguments at call time, but it is meant to be a 210 standalone piece of software: an App does not offer any interfaces 211 to other applications or services. 213 Service - A piece of software that performs one or more functions 214 and provides one or more APIs to applications or other services of 215 the same or different layers to make use of said functions and 216 returns one or more results. Services can be combined with other 217 services, or called in a certain serialized manner, to create a 218 new service. 220 Forwarding Plane (FP) - The network device part responsible for 221 forwarding traffic. 223 Operational Plane (OP) - The network device part responsible for 224 managing the overall device operation. 226 Control Plane (CP) - Part of the network functionality that is 227 assigned to control one or more network devices. CP instructs 228 network devices with respect to how to treat and forward packets. 229 The control plane interacts primarily with the forwarding plane 230 and to a lesser extent with the operational plane. 232 Management Plane (MP) - Part of the network functionality 233 responsible for monitoring, configuring and maintaining one or 234 more network devices. The management plane is mostly related with 235 the operational plane and less with the forwarding plane. 237 Device and resource Abstraction Layer (DAL) - The device's 238 resource abstraction layer based on one or more models. If it is 239 a physical device it may be referred to as the Hardware 240 Abstraction Layer (HAL). DAL provides a uniform point of 241 reference for the device's forwarding and operational plane 242 resources. 244 Control Abstraction Layer (CAL) - The control plane's abstraction 245 layer. CAL provides access to the control plane southbound 246 interface. 248 Management Abstraction Layer (MAL) - The management plane's 249 abstraction layer. MAL provides access to the management plane 250 southbound interface. 252 3. SDN Layers and Architecture 254 Figure 1 summarizes in the form of a detailed high-level schematic 255 the SDN architecture abstractions. Note that in a particular 256 implementation planes can be collocated with other planes or can be 257 physically separated, as we discuss below. 259 SDN is based on the concept of separation between a controlled entity 260 and a controller entity. The controller manipulates the controlled 261 entity via an Interface. Interfaces, when local, are mostly API 262 calls through some library or system call. However, such interfaces 263 may be extended via some protocol definition, which may use local 264 inter-process communication (IPC) or a protocol that could also act 265 remotely; the protocol may be defined as an open standard or in a 266 proprietary manner. 268 Day [PiNA] explores the use of IPC as the mainstay for the definition 269 of recursive network architectures with varying degrees of scope and 270 range of operation. RINA [RINA] outlines a recursive network 271 architecture based on IPC which capitalizes on repeating patterns and 272 structures. This document does not propose a new architecture--we 273 simply document previous work through a taxonomy. Although recursion 274 is out of scope for this work, Figure 1 illustrates a hierarchical 275 model in which layers can be stacked on top of each other and 276 recursively employed as needed. 278 o--------------------------------o 279 | | 280 | +-------------+ +----------+ | 281 | | Application | | Service | | 282 | +-------------+ +----------+ | 283 | Application Plane | 284 o---------------Y----------------o 285 | 286 *-----------------------------Y---------------------------------* 287 | Network Services Abstraction Layer (NSAL) | 288 *------Y------------------------------------------------Y-------* 289 | | 290 | Service Interface | 291 | | 292 o------Y------------------o o---------------------Y------o 293 | | Control Plane | | Management Plane | | 294 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 295 | | Service | | App | | | | App | | Service | | 296 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 297 | | | | | | | | 298 | *----Y-----------Y----* | | *---Y---------------Y----* | 299 | | Control Abstraction | | | | Management Abstraction | | 300 | | Layer (CAL) | | | | Layer (MAL) | | 301 | *----------Y----------* | | *----------Y-------------* | 302 | | | | | | 303 o------------|------------o o------------|---------------o 304 | | 305 | CP | MP 306 | Southbound | Southbound 307 | Interface | Interface 308 | | 309 *------------Y---------------------------------Y----------------* 310 | Device and resource Abstraction Layer (DAL) | 311 *------------Y---------------------------------Y----------------* 312 | | | | 313 | o-------Y----------o +-----+ o--------Y----------o | 314 | | Forwarding Plane | | App | | Operational Plane | | 315 | o------------------o +-----+ o-------------------o | 316 | Network Device | 317 +---------------------------------------------------------------+ 319 Figure 1: SDN Layer Architecture 321 3.1. Overview 323 This document follows a network device centric approach: Control 324 mostly refers to the device packet handling capability, while 325 management tends to refer to the overall device operation aspects. 327 We view a network device as a complex resource which contains and is 328 part of multiple resources similar to [DIOPR]. Resources can be 329 simple, single components of a network device, for example a port or 330 a queue of the device, and can also be aggregated into complex 331 resources, for example a network card or a complete network device. 333 The reader should keep in mind throughout this document that we make 334 no distinction between "physical" and "virtual" resources, as we do 335 not delve into implementation or performance aspects. In other 336 words, a resource can be implemented fully in hardware, fully in 337 software, or any hybrid combination in between. Further, we do not 338 distinguish on whether a resource is implemented as an overlay or as 339 a part/component of some other device. In general, network device 340 software can run on so-called "bare metal" or on a virtualized 341 substrate. Finally, this document does not discuss how resources are 342 allocated, orchestrated, and released. Indeed, orchestration is out 343 of scope for this document. 345 SDN spans multiple planes as illustrated in Figure 1. Starting from 346 the bottom part of the figure and moving towards the upper part, we 347 identify the following planes: 349 o Forwarding Plane - Responsible for handling packets in the 350 datapath. Actions of the forwarding plane include, but are not 351 limited to, forwarding, dropping and changing packets. The 352 forwarding plane is usually the termination point for control 353 plane services and applications. The forwarding plane can contain 354 forwarding resources such as classifiers. 356 o Operational Plane - Responsible for managing the operational state 357 of the network device, e.g. whether the device is active or 358 inactive, the number of ports available, the status of each port, 359 and so on. The operational plane is usually the termination point 360 for management plane services and applications. The operational 361 plane relates to (operational aspects of) network device resources 362 such as ports, memory, and so on. We note that some participants 363 of the IRTF SDNRG have a different opinion in regards to the 364 definition of the operational plane. That is, one can argue that 365 the operational plane does not constitute a "plane" per se, but it 366 is in practice an amalgamation of functions on the forwarding 367 plane. For others, however, a "plane" allows to distinguish 368 between different areas of operations and therefore the 369 operational plane should be included as a "plane" in Figure 1. We 370 have adopted this latter view in this document. 372 o Control Plane - Responsible for taking decisions on how packets 373 should be forwarded by one or more network devices and pushing 374 such decisions down to the network devices for execution. The 375 control plane usually focuses mostly on the forwarding plane and 376 less on the operational plane of the device. The control plane 377 may be interested in operational plane information which could 378 include, for instance, the current state of a particular port or 379 its capabilities. The control plane's main job is to fine-tune 380 the forwarding tables that reside in the forwarding plane, based 381 on the network topology or external service requests. 383 o Management Plane - Responsible for monitoring, configuring and 384 maintaining network devices, e.g. taking decisions regarding the 385 state of a network device. The management plane usually focuses 386 mostly on the operational plane of the device and less on the 387 forwarding plane. The management plane may be used to configure 388 the forwarding plane, but it does so infrequently and through a 389 more wholesale approach than the control plane. For instance, the 390 management plane may set up all or part of the forwarding rules at 391 once, although such action would be expected to be taken 392 sparingly. 394 o Application Plane - The plane where applications that rely on the 395 network to provide services for end users and processes reside. 396 Applications that directly (or primarily) support the operation of 397 the forwarding plane (such as routing processes within the control 398 plane) are not considered part of the application plane. Note 399 that applications may be implemented in a modular and distributed 400 fashion and, therefore, can often span multiple planes in 401 Figure 1. 403 All planes mentioned above are connected via interfaces (as indicated 404 with "Y" in Figure 1. An interface may take multiple roles depending 405 on whether the connected planes reside on the same (physical or 406 virtual) device. If the respective planes are designed so that they 407 do not have to reside in the same device, then the interface can only 408 take the form of a protocol. If the planes are co-located on the 409 same device, then the interface could be implemented via an open/ 410 proprietary protocol, an open/proprietary software inter-process 411 communication API, or operating system kernel system calls. 413 Applications, i.e. software programs that perform specific 414 computations that consume services without providing access to other 415 applications, can be implemented natively inside a plane or can span 416 multiple planes. For instance, applications or services can span 417 both the control and management plane and, thus, be able to use both 418 the Control Plane Southbound Interface (CPSI) and Management Plane 419 Southbound Interface (MPSI), although this is only implicitly 420 illustrated in Figure 1. An example of such a case would be an 421 application that uses both [OpenFlow] and [OF-CONFIG]. 423 Services, i.e. software programs that provide APIs to other 424 applications or services, can also be natively implemented in 425 specific planes. Services that span multiple planes belong to the 426 application plane as well. 428 While not shown explicitly in Figure 1, services, applications and 429 entire planes, can be placed in a recursive manner thus providing 430 overlay semantics to the model. For example, application plane 431 services can provide through NSAL services to other applications or 432 services. Additional examples include virtual resources that are 433 realized on top of a physical resources and hierarchical control 434 plane controllers [KANDOO]. 436 It must be noted, however, that in Figure 1 we present an abstract 437 view of the various planes, which is devoid of implementation 438 details. Many implementations in the past have opted for placing the 439 management plane on top of the control plane. This can be 440 interpreted as having the control plane acting as a service to the 441 management plane. Further, traditionally, the control plane was 442 tightly coupled with the network device. When taken as whole, the 443 control plane was distributed network-wide. On the other hand, the 444 management plane has been traditionally centralized and was 445 responsible for managing the control plane and the devices. However, 446 with the adoption of SDN principles, this distinction is no longer so 447 clear-cut. 449 Additionally, this document considers four abstraction layers: 451 The Device and resource Abstraction Layer (DAL) abstracts the 452 device's forwarding and operational plane resources to the control 453 and management plane. Variations of DAL may abstract both planes 454 or either of the two and may abstract any plane of the device to 455 either the control or management plane. 457 The Control Abstraction Layer (CAL) abstracts the CP southbound 458 interface and the DAL from the applications and services of the 459 control plane. 461 The Management Abstraction Layer (MAL) abstracts the MP southbound 462 interface and the DAL from the applications and services of the 463 management plane. 465 The Network Services Abstraction Layer (NSAL) provides service 466 abstractions for use by applications and other services. 468 We observe that the view presented in this document is quite well- 469 aligned with recently published work by the ONF; see [ONFArch]. A 470 key difference, however, is that the ONF architecture does not 471 include the management plane in its scope. 473 At the time of this writing, SDN-related activities have begun in 474 other SDOs. For example, in ITU work on architectural [ITUSG13] and 475 signaling requirements and protocols [ITUSG11] has commenced, but the 476 respective study groups have yet to publish their documents at the 477 time of this writing. In addition, ITU has started a Joint 478 Collaboration Activity (JCA) in regards to SDN. 480 3.2. Network Devices 482 A Network Device is an entity that receives packets on its ports and 483 performs one or more network functions on them. For example, the 484 network device could forward a received packet, drop it, alter the 485 packet header (or payload) and forward the packet, and so on. A 486 Network Device is an aggregation of multiple resources such as ports, 487 CPU, memory and queues. Resources are either simple or can be 488 aggregated to form complex resources that can be viewed as one 489 resource. The Network Device is in itself a complex resource. 490 Examples of Network Devices include switches and routers. Additional 491 examples include network elements that may operate at a layer above 492 IP, such as firewalls, load balancers and video transcoders. 494 Network devices can be implemented in hardware or software and can be 495 either physical or virtual. As has already been mentioned before, 496 this document makes no such distinction. Each network device has 497 both a Forwarding Plane and an Operational Plane. 499 The Forwarding Plane, commonly referred to as the "data path", is 500 responsible for handling and forwarding packets. The Forwarding 501 Plane provides switching, routing transformation and filtering 502 functions. Resources of the forwarding plane include but are not 503 limited to filters, meters, markers and classifiers. 505 The Operational Plane is responsible for the operational state of the 506 network device, for instance, with respect to status of network ports 507 and interfaces. Operational plane resources include, but are not 508 limited to, memory, CPU, ports, interfaces and queues. 510 The Forwarding and the Operational Planes are exposed via the Device 511 and resource Abstraction Layer (DAL), which may be expressed by one 512 or more abstraction models. Examples of Forwarding Plane abstraction 513 models are ForCES [RFC5812] and OpenFlow [OpenFlow]. Examples of the 514 Operational Plane abstraction model include the ForCES model 515 [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418]. 517 Note that applications can also reside in a network device. Examples 518 of such applications include event monitoring, and handling 519 (offloading) topology discovery or ARP [RFC0826] in the device itself 520 instead of forwarding such traffic to the control plane. 522 3.3. Control Plane 524 The control plane is usually distributed and is responsible mainly 525 for the configuration of the forwarding plane using a Control Plane 526 Southbound Interface (CPSI) with DAL as a point of reference. CP is 527 responsible for instructing FP about how to handle network packets. 529 Communication between control planes, colloquially referred to as the 530 "east-west" interface, is usually implemented through gateway 531 protocols such as BGP [RFC4271] or other protocols such as [RFC5440]. 532 However, the corresponding protocol messages are in fact exchanged 533 in-band and subsequently redirected by the forwarding plane to the 534 control plane for further processing. Examples in this category 535 include [RCP], [SoftRouter] and [RouteFlow]. 537 Control Plane functionalities usually include: 539 o Topology discovery and maintenance 541 o Packet route selection and instantiation 543 o Path failover mechanisms 545 The CPSI is usually defined with the following characteristics: 547 o time-critical interface which requires low latency and sometimes 548 high bandwidth in order to perform many operations in short order. 550 o oriented towards wire efficiency and device representation instead 551 of human readability 553 Examples include fast- and high-frequency of flow or table updates, 554 high throughput and robustness for packet handling and events. 556 CPSI can be implemented using a protocol, an API or even interprocess 557 communication. If the Control Plane and the Network Device are not 558 collocated, then this interface is certainly a protocol. Examples of 559 CPSIs are ForCES [RFC5810] and the Openflow protocol [OpenFlow]. 561 The Control Abstraction Layer (CAL) provides access to control 562 applications and services to various CPSIs. The Control Plane may 563 support more than one CPSIs. 565 Control applications can use CAL to control a network device without 566 providing any service to upper layers. Examples include applications 567 that perform control functions, such as OSPF, IS-IS, and BGP. 569 Control Plane service examples include a virtual private LAN service, 570 service tunnels, topology services, etc. 572 3.4. Management Plane 574 The Management Plane is usually centralized and aims to ensure that 575 the network as a whole is running optimally by communicating with the 576 network devices' Operational Plane using a Management Plane 577 Southbound Interface (MPSI) with DAL as a point of reference. 579 Management plane functionalities are typically initiated, based on an 580 overall network view, and traditionally have been human-centric. 581 However, lately algorithms are replacing most human intervention. 582 Management plane functionalities [FCAPS] [RFC3535] usually include: 584 o Fault and Monitoring management 586 o Configuration management 588 In addition, management plane functionalities may also include 589 entities such as orchestrators, Virtual Function Managers (VNF 590 manager) and Virtualised Infrastructure Managers, as described in 591 [NFVArch]. Such entities can use management interfaces to 592 operational plane resources to request and provision resources for 593 virtual functions, as well as instruct the instantiation of virtual 594 forwarding functions on top of physical forwarding functions. 595 explores the possibility of a common abstraction model for both SDN 596 and NFV [SDNNFV]. Note, however, that these are only examples of 597 applications and services in the management plane and not formal 598 definitions of entities in this document. As has been noted above, 599 orchestration and therefore the definition of any associated entities 600 is out of scope for this document. 602 Normally MPSI, in contrast to the CPSI, is not a time-critical 603 interface and does not share the CPSI requirements. 605 MPSI is [RFC3535] typically closer to human interaction than CPSI 606 and, therefore, MPSI usually has the following characteristics: 608 o It is oriented more towards usability, with optimal wire 609 performance being a secondary concern. 611 o Messages tend to be less frequent than in the CPSI 612 As an example of usability versus performance, we refer to the 613 consensus of the 2002 IAB Workshop [RFC3535], as per [RFC6632], where 614 textual configuration files should be able to contain international 615 characters. Human-readable strings should utilize UTF-8, and 616 protocol elements should be in case-insensitive ASCII which require 617 more processing capabilities to parse. 619 MPSI can range from a protocol, to an API or even interprocess 620 communication. If the Management Plane is not embedded in the 621 network device, the MPSI is certainly a protocol. Examples of MPSIs 622 are ForCES [RFC5810], NETCONF [RFC6241], OVSDB [RFC7047] and SNMP 623 [RFC3411]. 625 The Management Abstraction Layer (MAL) provides access to management 626 applications and services to various MPSIs. The Management Plane may 627 support more than one MPSI. 629 Management Applications can use MAL to manage the network device 630 without providing any service to upper layers. Examples of 631 management applications include network monitoring, fault detection 632 and recovery applications. 634 Management Plane Services provide access to other services or 635 applications above the Management Plane. 637 3.5. The Control vs. Management Plane Debate 639 During the IETF 88 and 89 SDNRG meetings as well as on the 640 corresponding mailing list, one of the most commonly discussed 641 topics, in regards to this document, was the definition of clear 642 distinction between control and management. Earlier we have observed 643 that the role of the management plane has been largely ignored or 644 specified as out-of-scope for the SDN ecosystem. We argue that it is 645 important to characterize and distinguish these two planes in order 646 to have a clear understanding of the mechanics, capabilities and 647 needs of the each respective interface. 649 In the remainder of this subsection we summarize the characteristics 650 that differentiate the two planes as per the discussions mentioned 651 above. 653 3.5.1. Timescale 655 A point has been raised regarding the reference timescales for the 656 control and management planes. That is, how fast is the respective 657 plane required to react, or needs to manipulate, the forwarding or 658 operational plane of the device. In general, the control plane needs 659 to send updates "often", which translates roughly to a range of 660 milliseconds; that requires high-bandwidth and low-latency links. In 661 contrast, the management plane reacts generally at longer time 662 frames, i.e. minutes, hours or even days, and thus wire-efficiency is 663 not always a critical concern. A good example of this is the case of 664 changing the configuration state of the device. 666 3.5.2. Persistence 668 Another distinction between the control and management planes relates 669 to state persistence. A state is considered ephemeral if it has a 670 very limited lifespan. A good example is determining routing, which 671 is usually associated with the control plane. On the other hand, a 672 persistent state has an extended lifespan which may range from hours 673 to days and months and is usually associated with the management 674 plane. Persistent state is also usually associated with data store 675 of the state. 677 3.5.3. Locality 679 As mentioned earlier, traditionally the control plane has been 680 executed locally on the network device and is distributed in nature 681 whilst the management plane is usually executed in a centralized 682 manner, remotely from the device. However, with the advent of SDN 683 centralizing, or "locally centralizing" the controller tends to 684 muddle the distinction of the control and management plane based on 685 locality. 687 3.5.4. CAP Theorem Insights 689 An additional distinction was introduced at IETF 89 with a reference 690 to the CAP theorem. The CAP theorem views a distributed computing 691 system as composed of multiple computational resources (i.e., CPU, 692 memory, storage) that are connected via a communications network and 693 together perform a task. The theorem (or conjecture by some) 694 identifies three characteristics of distributed systems that are 695 universally desirable: 697 Consistency, meaning that the system responds identically to a 698 query no matter which node receives the request (or does not 699 respond at all) 701 Availability, i.e. that the system always responds to a request 702 (although the response may not be consistent or correct) 704 Partition tolerance, namely that the system continues to function 705 even when specific nodes or the communications network fail. 707 In 2000 Eric Brewer [CAPBR] conjectured that a distributed system can 708 satisfy any two of these guarantees at the same time, but not all 709 three. This conjecture was later proven by Gilbert and Lynch [CAPGL] 710 and is now usually referred to as the CAP theorem [CAPFN]. 712 Forwarding a packet through a network correctly is a computational 713 problem. One of the major abstractions that SDN posits is that all 714 network elements are computational resources that perform the simple 715 computational task of inspecting fields in an incoming packet and 716 deciding how to forward it. Since the task of forwarding a packet 717 from network ingress to network egress is obviously carried out by a 718 large number of forwarding elements, the network of forwarding 719 devices is a distributed computational system. Hence, the CAP 720 theorem applies to forwarding of packets. 722 In the context of the CAP theorem, if one considers partition 723 tolerance of paramount importance, traditional control plane 724 operations are usually local and fast (available), while management 725 plane operations are usually centralized (consistent) and may be 726 slow. 728 The CAP theorem also provides insights into SDN architectures. For 729 example a centralized SDN controller acts as a consistent global 730 database, and specific SDN mechanisms ensure that a packet entering 731 the network is handled consistently by all SDN switches. The issue 732 of tolerance to loss of connectivity to the controller is not 733 addressed by the basic SDN model. When an SDN switch cannot reach 734 its controller, the flow will be unavailable until the connection is 735 restored. The use of multiple non-collocated SDN controllers has 736 been proposed (e.g., by configuring the SDN switch with a list of 737 controllers); this may improve partition tolerance, but at the cost 738 of loss of absolute consistency. Panda et al. [CAPFN] provide a 739 first exploration of how the CAP theorem applies to SDN. 741 3.6. Network Services Abstraction Layer 743 The Network Services Abstraction Layer (NSAL) provides access from 744 services of the control, management and application planes to 745 services and applications of the application plane. We note that the 746 term SAL is overloaded, as it is often used in several contexts 747 ranging from system design to service-oriented architectures, 748 therefore we explicitly add "Network" to the title of this layer to 749 emphasize that this term relates to Figure 1 and we map it 750 accordingly in Section 4 to prominent SDN approaches. 752 Service Interfaces can take many forms pertaining to their specific 753 requirements. Examples of service interfaces include but are not 754 limited to, RESTful APIs, open or proprietary protocols such as 755 NETCONF, inter-process communication, CORBA interfaces, and so on. 756 The two leading approaches for service interfaces are RESTful 757 interfaces and RPC interfaces. Both follow a client-server 758 architecture and use XML or JSON to pass messages but each has some 759 slightly different characteristics. 761 RESTful interfaces, designed according to the representational state 762 transfer design paradigm [REST], have the following characteristics: 764 Resource identification - individual resources are identified 765 using a resource identifier, for example a URI. 767 Manipulation of resources through representations - Resources are 768 represented in a format like JSON, XML or HTML. 770 Self-descriptive messages - Each message has enough information to 771 describe how the message is to be processed. 773 Hypermedia as the engine of application state - a client needs no 774 prior knowledge of how to interact with a server, not through a 775 fixed interface. 777 Remote procedure calls (RPC), e.g. [RFC5531], XML-RPC and the like., 778 have the following characteristics: 780 Individual procedures are identified using an identifier 782 A client needs to know the procedure name and the associated 783 parameters 785 3.7. Application Plane 787 Applications and services that use services from the control and/or 788 management plane form the Application Plane. 790 Additionally, services residing in the Application Plane may provide 791 services to other services and applications that reside in the 792 application plane via the service interface. 794 Examples of applications include network topology discovery, network 795 provisioning, path reservation, etc. 797 4. SDN Model View 799 We advocate that the SDN southbound interface should encompass both 800 CSPI and MPSI. 802 The SDN northbound interface is implemented in the Network Services 803 Abstraction Layer of Figure 1. 805 The above model can be used to describe in a concise manner all 806 prominent SDN-enabling technologies, as we explain in the following 807 subsections. 809 4.1. ForCES 811 The IETF-standardized Forwarding and Control Element Separation 812 (ForCES [RFC5810]) framework consists of one model and two protocols. 813 ForCES separates the Forwarding from the Control Plane via an open 814 interface, namely the ForCES protocol which operates on entities of 815 the forwarding plane that have been modeled using the ForCES model. 817 The ForCES model is based on the fact that a network element is 818 composed of numerous logically separate entities that cooperate to 819 provide a given functionality -such as routing or IP switching- and 820 yet appear as a normal integrated network element to external 821 entities and secondly with a protocol to transport information. 823 ForCES models the Forwarding Plane using Logical Functional Blocks 824 (LFBs) which are connected in a graph, composing the Forwarding 825 Element (FE). LFBs are described in an XML language, based on an XML 826 schema. 828 LFB definitions include: 830 o Base and custom-defined datatypes 832 o Metadata definitions 834 o Input and Output ports 836 o Operational parameters, or components 838 o Capabilities 840 o Event definitions 842 The ForCES model can be used to define LFBs from fine- to coarse- 843 grained as needed, irrespective of whether they are physical or 844 virtual. 846 The ForCES protocol is agnostic to the model and can be used to 847 monitor, configure and control any ForCES-modeled element. The 848 protocol has very simple commands: Set, Get and Del(ete). The ForCES 849 protocol designed for high throughput and fast updates. 851 ForCES [RFC5810] can be mapped to the framework illustrated in 852 Figure 1 as follows: 854 o The ForCES model can be used to describe DAL, both for the 855 Operational and the Forwarding Plane, using LFBs . 857 o The ForCES protocol can then be both the CPSI and the MPSI. 858 ForCES is inherently specified for the CPSI and satisfies its 859 requirements, however it can also be utilized for the MPSI. 861 o CAL and MAL must be able to utilize the ForCES protocol. 863 4.2. NETCONF 865 The Network Configuration Protocol (NETCONF [RFC6241]), is an IETF- 866 standardized network management protocol [RFC6632]. NETCONF provides 867 mechanisms to install, manipulate, and delete the configuration of 868 network devices. 870 NETCONF protocol operations are realized as remote procedure calls 871 (RPCs). The NETCONF protocol uses an Extensible Markup Language 872 (XML) based data encoding for the configuration data as well as the 873 protocol messages. Recent studies, such as [ESNet] and [PENet], have 874 shown that NETCONF performs better than SNMP [RFC3411]. 876 Additionally, the YANG data modeling language [RFC6020] has been 877 developed for specifying NETCONF data models and protocol operations. 878 YANG is a data modeling language used to model configuration and 879 state data manipulated by NETCONF, NETCONF remote procedure calls, 880 and NETCONF notifications. 882 YANG models the hierarchical organization of data as a tree, in which 883 each node has either a value or a set of child nodes. Additionally, 884 YANG structures data models into modules and submodules allowing 885 reusability and augmentation. YANG models can describe constraints 886 to be enforced on the data. Additionally YANG has a set of base 887 datatype and allows custom defined datatypes as well. 889 YANG allows the definition of NETCONF RPCs allowing the protocol to 890 have an extensible number of commands. For RPC definition, the 891 operations names, input parameters, and output parameters are defined 892 using YANG data definition statements. 894 NETCONF can be mapped to the framework illustrated in Figure 1 as 895 follows: 897 o The YANG model [RFC6020] is suitable for specifying DAL for the 898 operational plane and NETCONF [RFC6241] for the MPSI. 900 o Technically, the YANG model [RFC6020] can be used to specify DAL 901 for the Forwarding plane as well. That said, in principle, 902 NETCONF [RFC6241] is a management protocol which was not 903 (originally) designed for fast CP updates, and it might not be 904 suitable for addressing the requirements of CPSI. 906 4.3. OpenFlow 908 [OpenFlow] is a framework originally developed by Stanford, and 909 currently under active standards development through the Open 910 Networking Foundation (ONF). Initially, the goal was to provide a 911 way for researchers to run experimental protocols in a production 912 network [OFSIGC]. OpenFlow provides a protocol with which a 913 controller may manage a static model of an OpenFlow switch. 915 An OpenFlow switch consists of one or more flow tables which perform 916 packet lookups, actions on a success packet lookup and forwarding, a 917 group table and an OpenFlow channel to an external controller. The 918 switch communicates with the controller which manages the switch via 919 the OpenFlow protocol. 921 OpenFlow has undergone many revisions. The current version is 1.4 922 [OpenFlow] and supports amongst others, multiple controllers for high 923 availability and extensible flow match field protocol messages to 924 support arbitrary match fields. Efforts to define OpenFlow 2.0 925 [PPIPP] are already underway aiming to provide an abstract forwarding 926 model to provide protocol independence and device programmability. 928 OpenFlow can be mapped to the framework illustrated in Figure 1 as 929 follows: 931 o The Openflow switch specifications [OpenFlow] covers DAL for the 932 Forwarding Plane and provides the specification for CPSI. 934 o The OF-CONFIG protocol [OF-CONFIG] based on the YANG model 935 [RFC6020], provides DAL for the Operational Plane and specifies 936 NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the 937 OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol 938 it shares the limitations described in the previous section. 940 o CAL must be able to utilize the OpenFlow protocol. 942 o MAL must be able to utilize the NETCONF protocol. 944 4.4. I2RS 946 I2RS is currently developed by a recently-established IETF working 947 group. The intention is to provide a standard interface to the 948 routing system for real-time or event-driven interaction through a 949 collection of protocol-based control or management interfaces. 950 Essentially, I2RS aims to make the routing information base (RIB) 951 programmable thus enabling new kinds of network provisioning and 952 operation. 954 I2RS does not initially intend to create new interfaces, but rather 955 leverage or extend existing ones and define informational models for 956 the routing system. For example, the latest I2RS problem statement 957 [I-D.ietf-i2rs-problem-statement] discusses previously-defined IETF 958 protocols such as ForCES [RFC5810], NETCONF [RFC6241], and SNMP 959 [RFC3417]. Regarding the definition of informational and data 960 models, the I2RS working group has opted to use the YANG [RFC6020] 961 modelling language. 963 Currently the I2RS working group is developing an Information Model 964 [I-D.ietf-i2rs-rib-info-model] in regards to the Network Services 965 Abstraction Layer for the I2RS agent. 967 I2RS can be mapped to the framework illustrated in Figure 1 as 968 follows: 970 o The I2RS architecture [I-D.ietf-i2rs-architecture] encompasses the 971 Control and Application Planes and uses any CPSI and DAL that is 972 available, whether that may be ForCES [RFC5810], OpenFlow 973 [OpenFlow] or another interface. 975 o The I2RS agent is a Control Plane Service. All services or 976 applications on top of that belong to either the Control, 977 Management or the Application plane. In the I2RS documents, 978 management access to the agent may be provided by management 979 protocols like SNMP and NETCONF. The I2RS protocol may also be 980 mapped to the Service Interface as it will provide access even to 981 other than control applications. 983 4.5. SNMP 985 The Simple Network Management Protocol (SNMP) is an IETF-standardized 986 management protocol and is currently at its third revision (SNMPv3) 987 RFC 3417 [RFC3417], RFC 3412 [RFC3412] and RFC 3414 [RFC3414]. It 988 consists of a set of standards for network management, including an 989 application layer protocol, a database schema, and a set of data 990 objects. SNMP exposes management data (managed objects) in the form 991 of variables on the managed systems, which describe the system 992 configuration. These variables can then be queried and set by 993 managing applications. 995 SNMP uses an extensible design for describing data, defined by 996 management information bases (MIBs). MIBs describe the structure of 997 the management data of a device subsystem. MIBs use a hierarchical 998 namespace containing object identifiers (OID). Each OID identifies a 999 variable that can be read or set via SNMP. MIBs use the notation 1000 defined by Structure of Management Information Version 2 SMIv2 1001 [RFC2578] 1003 SNMP could be mapped to the framework illustrated in Figure 1 as 1004 follows: 1006 1. SNMP MIBs can be used to describe DAL for the Operational Plane. 1007 Similar to YANG, SNMP MIBs are able to describe DAL for the 1008 Forwarding Plane. 1010 2. SNMP is suited for the MPSI. 1012 4.6. PCEP 1014 The Path Computation Element (PCE) [RFC4655] architecture describes 1015 the PCE, an entity capable of computing paths for a single or set of 1016 services. A PCE might be a network node, network management station, 1017 or dedicated computational platform that is resource-aware and has 1018 the ability to consider multiple constraints for a variety of path 1019 computation problems and switching technologies. The PCE 1020 Communication Protocol (PCEP) (PCEP) [RFC5440]. is an IETF protocol 1021 for communication between a Path Computation Client (PCC) and a PCE, 1022 or between multiple PCEs. 1024 The PCE represents a vision of networks that separates path 1025 computation for services, the signaling of end-to-end connections and 1026 actual packet forwarding. The definition of online and offline path 1027 computation is dependent on the reachability of the PCE from network 1028 and NMS nodes, and the type of optimization request which may 1029 significantly impact the optimization response time from the PCE to 1030 the PCC. 1032 The PCEP messaging mechanism facilitates the specification of 1033 computation endpoints (source and destination node addresses) and 1034 objective functions (requested algorithm and optimization criteria), 1035 and the associated constraints such as traffic parameters (e.g. 1036 requested bandwidth), the switching capability, and encoding type. 1038 The PCE is a control plane service that provides services for control 1039 plane applications. 1041 The PCEP may be used as an east-west interface between domain control 1042 entities (services and applications). 1044 4.7. BFD 1046 Bidirectional Forwarding Detection (BFD) [RFC5880], is an IETF- 1047 standardized network protocol designed for detecting communication 1048 failures between two forwarding elements which are directly 1049 connected. It is intended to be implemented in some component of the 1050 forwarding engine of a system, in cases where the forwarding and 1051 control engines are separated. BFD provides low-overhead detection 1052 of faults even on physical media that do not support failure 1053 detection of any kind, such as Ethernet, virtual circuits, tunnels 1054 and MPLS Label Switched Paths. 1056 BFD could be mapped to the framework illustrated in Figure 1 either 1057 as: 1059 1. A control plane service or application that would use the CPSI 1060 towards the forwarding plane to send/receive BFD packets. 1062 2. Or, better, as it was intended for, i.e. as an application that 1063 runs on the device itself and uses the forwarding plane to send/ 1064 receive BFD packets and update the operational plane resources 1065 accordingly. 1067 5. Contributors 1069 The authors would like to acknowledge (in alphabetical order) the 1070 following persons as contributors to this document. They all 1071 provided text, pointers and comments that made this document more 1072 complete: 1074 Daniel King for providing text related to the PCEP protocol. 1076 Scott Mansfield for information regarding the ITU status on SDN. 1078 Yaakov Stein for providing text related to the CAP theorem and SDO- 1079 related information. 1081 Russ White for text suggestions on the definitions on control, 1082 management and application. 1084 6. Acknowledgements 1086 The authors would like to acknowledge Salvatore Loreto and Sudhir 1087 Modali for their contributions in the initial discussion on the SDNRG 1088 mailing list as well as their draft-specific comments; they helped 1089 put this document in a better shape. 1091 Additionally we would like to thank (in alphabetical order) Shivleela 1092 Arlimatti, Roland Bless, Scott Brim, Alan Clark, Tim Copley, Gurkan 1093 Deniz, Linda Dunbar, Francisco Javier Ros Munoz, Georgios 1094 Karagiannis, Bhumip Khasnabish, Sriganesh Kini, Ramki Krishnan, Dirk 1095 Kutscher, Diego Lopez, Scott Mansfield, Pedro Martinez-Julia, David E 1096 Mcdysan, Erik Nordmark, Carlos Pignataro, Robert Raszuk, Bless 1097 Roland, Yaakov Stein, Dimitri Staessens, Russ White and Lee Young for 1098 their critical comments and discussions at the IETF 88, IETF 89 and 1099 IETF 90 meetings and the SDNRG mailing list, which we took into 1100 consideration while revising this document. 1102 7. IANA Considerations 1104 This memo makes no requests to IANA. 1106 8. Security Considerations 1108 This document does not propose a new network architecture or protocol 1109 and therefore does not have any impact on the security of the 1110 Internet. That said, security is paramount in networking and thus it 1111 should be given full consideration when designing a network 1112 architecture or operational deployment. Security in SDN is discussed 1113 in the literature, for example in [SDNSecurity]and 1114 [SDNSecServ][SDNSecOF]. Security considerations regarding specific 1115 interfaces, such as, for example, ForCES, I2RS, SNMP, or NETCONF are 1116 addressed in their respective documents. 1118 9. Informative References 1120 [A4D05] Greenberg, Albert, et al., "A clean slate 4D approach to 1121 network control and management", ACM SIGCOMM Computer 1122 Communication Review 35.5 (2005): 41-54 , 2005. 1124 [CAPBR] Eric A. Brewer, "Towards robust distributed systems.", 1125 Symposium on Principles of Distributed Computing (PODC). 1126 2000 , 2000. 1128 [CAPFN] Panda, Aurojit, Colin Scott, Ali Ghodsi, Teemu Koponen, 1129 and Scott Shenker., "CAP for Networks.", In Proceedings of 1130 the second ACM SIGCOMM workshop on Hot topics in software 1131 defined networking, pp. 91-96. ACM, 2013. , 2013. 1133 [CAPGL] Seth Gilbert, and Nancy Ann Lynch., "Brewer's conjecture 1134 and the feasibility of consistent, available, partition- 1135 tolerant web services", ACM SIGACT News 33.2 (2002): 1136 51-59. , 2002. 1138 [DIOPR] Denazis, Spyros, Kazuho Miki, John Vicente, and Andrew 1139 Campbell., "Designing interfaces for open programmable 1140 routers.", In Active Networks, pp. 13-24. Springer Berlin 1141 Heidelberg, 1999 , 1999. 1143 [ESNet] Yu, James, and Imad Al Ajarmeh., "An empirical study of 1144 the NETCONF protocol.", In Networking and Services (ICNS), 1145 2010 Sixth International Conference on, pp. 253-258. IEEE, 1146 2010. , 2010. 1148 [FCAPS] International Telecommunication Union, "X.700: Management 1149 Framework For Open Systems Interconnection (OSI) For CCITT 1150 Applications", September 1992, 1151 . 1153 [I-D.ietf-i2rs-architecture] 1154 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1155 Nadeau, "An Architecture for the Interface to the Routing 1156 System", draft-ietf-i2rs-architecture-05 (work in 1157 progress), July 2014. 1159 [I-D.ietf-i2rs-problem-statement] 1160 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1161 Routing System Problem Statement", draft-ietf-i2rs- 1162 problem-statement-04 (work in progress), June 2014. 1164 [I-D.ietf-i2rs-rib-info-model] 1165 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 1166 Information Base Info Model", draft-ietf-i2rs-rib-info- 1167 model-03 (work in progress), May 2014. 1169 [ITUATM] CCITT, Geneva, Switzerland, "CCITT Recommendation 1.361, 1170 B-ISDN ATM Layer Specification", 1990. 1172 [ITUSG11] Telecommunication Standardization sector of ITU, "ITU, 1173 Study group 11", 2013, . 1176 [ITUSG13] Telecommunication Standardization sector of ITU, "ITU, 1177 Study group 13", 2013, . 1180 [ITUSS7] Telecommunication Standardization sector of ITU, "ITU, 1181 Q.700 : Introduction to CCITT Signalling System No. 7", 1182 1993. 1184 [KANDOO] Hassas Yeganeh, Soheil, and Yashar Ganjali., "Kandoo: a 1185 framework for efficient and scalable offloading of control 1186 applications.", In Proceedings of the first workshop on 1187 Hot topics in software defined networks, pp. 19-24. ACM 1188 SIGCOMM, 2012. , 2012. 1190 [NFVArch] European Telecommunication Standards Institute, "Network 1191 Functions Virtualisation (NFV): Architectural Framework; 1192 White paper, ETSI GS 9 NFV 002, 2013", December 2013, 1193 . 1196 [NV09] Chowdhury, NM Mosharaf Kabir, and Raouf Boutaba, "Network 1197 virtualization: state of the art and research challenges", 1198 Communications Magazine, IEEE 47.7 (2009): 20-26 , 2009. 1200 [OF-CONFIG] 1201 Open Networking Foundation, "OpenFlow Management and 1202 Configuration Protocol 1.1.1", March 2013, 1203 . 1207 [OF08] McKeown, Nick, et al., "OpenFlow: enabling innovation in 1208 campus networks", ACM SIGCOMM Computer Communication 1209 Review 38.2 (2008): 69-74 , 2008. 1211 [OFSIGC] McKeown, Nick, Tom Anderson, Hari Balakrishnan, Guru 1212 Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, 1213 and Jonathan Turner., "OpenFlow: enabling innovation in 1214 campus networks.", ACM SIGCOMM Computer Communication 1215 Review 38, no. 2 (2008): 69-74. , 1998. 1217 [ONFArch] Open Networking Foundation, "SDN Architecture Overview", 1218 December 2013, 1219 . 1223 [OpenFlow] 1224 Open Networking Foundation, "The OpenFlow 1.4 1225 Specification.", October 2013, 1226 . 1230 [P1520] Biswas, Jit, Aurel A. Lazar, J-F. Huard, Koonseng Lim, 1231 Semir Mahjoub, L-F. Pau, Masaaki Suzuki, Soren 1232 Torstensson, Weiguo Wang, and Stephen Weinstein., "The 1233 IEEE P1520 standards initiative for programmable network 1234 interfaces.", Communications Magazine, IEEE 36, no. 10 1235 (1998): 64-70. , 1998. 1237 [PENet] Hedstrom, Brian, Akshay Watwe, and Siddharth Sakthidharan, 1238 "Protocol Efficiencies of NETCONF versus SNMP for 1239 Configuration Management Functions", PhD dissertation, 1240 Master's thesis, University of Colorado, 2011 , 2011. 1242 [PNSurvey99] 1243 Campbell, Andrew T., et al, "A survey of programmable 1244 networks", ACM SIGCOMM Computer Communication Review 29.2 1245 (1999): 7-23 , September 1992. 1247 [PPIPP] Bosshart, Pat, Dan Daly, Martin Izzard, Nick McKeown, 1248 Jennifer Rexford, Dan Talayco, Amin Vahdat, George 1249 Varghese, and David Walker., "Programming Protocol- 1250 Independent Packet Processors.", arXiv preprint 1251 arXiv:1312.1719 (2013). , 2013. 1253 [PiNA] John Day, "Patterns in network architecture: a return to 1254 fundamentals.", Prentice Hall (ISBN 0132252422). , 2007. 1256 [RCP] Caesar, Matthew, Donald Caldwell, Nick Feamster, Jennifer 1257 Rexford, Aman Shaikh, and Jacobus van der Merwe., "Design 1258 and implementation of a routing control platform.", In 1259 Proceedings of the 2nd conference on Symposium on 1260 Networked Systems Design & Implementation-Volume 2, pp. 1261 15-28. USENIX Association, 2005. , 2005. 1263 [REST] Fielding, Roy, "Fielding Dissertation: Chapter 5: 1264 Representational State Transfer (REST).", 2000. 1266 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1267 converting network protocol addresses to 48.bit Ethernet 1268 address for transmission on Ethernet hardware", STD 37, 1269 RFC 826, November 1982. 1271 [RFC1953] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching 1272 Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow 1273 Management Protocol Specification for IPv4 Version 1.0", 1274 RFC 1953, May 1996. 1276 [RFC2297] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw, 1277 F., Lyon, T., and G. Minshall, "Ipsilon's General Switch 1278 Management Protocol Specification Version 2.0", RFC 2297, 1279 March 1998. 1281 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1282 Schoenwaelder, Ed., "Structure of Management Information 1283 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1285 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1286 Architecture for Describing Simple Network Management 1287 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1288 December 2002. 1290 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1291 "Message Processing and Dispatching for the Simple Network 1292 Management Protocol (SNMP)", STD 62, RFC 3412, December 1293 2002. 1295 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1296 (USM) for version 3 of the Simple Network Management 1297 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1299 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1300 Management Protocol (SNMP)", STD 62, RFC 3417, December 1301 2002. 1303 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1304 Simple Network Management Protocol (SNMP)", STD 62, RFC 1305 3418, December 2002. 1307 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 1308 Management Workshop", RFC 3535, May 2003. 1310 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1311 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1313 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1314 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1316 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1317 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1318 2009. 1320 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 1321 Specification Version 2", RFC 5531, May 2009. 1323 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1324 (IRTF) Document Stream", RFC 5743, December 2009. 1326 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1327 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1328 Control Element Separation (ForCES) Protocol 1329 Specification", RFC 5810, March 2010. 1331 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1332 Element Separation (ForCES) Forwarding Element Model", RFC 1333 5812, March 2010. 1335 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1336 (BFD)", RFC 5880, June 2010. 1338 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1339 Network Configuration Protocol (NETCONF)", RFC 6020, 1340 October 2010. 1342 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1343 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1344 6241, June 2011. 1346 [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network 1347 Management Standards", RFC 6632, June 2012. 1349 [RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database 1350 Management Protocol", RFC 7047, December 2013. 1352 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1353 Networking: A Perspective from within a Service Provider 1354 Environment", RFC 7149, March 2014. 1356 [RINA] John Day, Ibrahim Matta, and Karim Mattar., "Networking is 1357 IPC: a guiding principle to a better internet.", In 1358 Proceedings of the 2008 ACM CoNEXT Conference, p. 67. ACM, 1359 2008. , 2008. 1361 [RouteFlow] 1362 Nascimento, Marcelo R., Christian E. Rothenberg, Marcos R. 1363 Salvador, Carlos NA Correa, Sidney C. de Lucena, and 1364 Mauricio F. Magalhaes., "Virtual routers as a service: the 1365 routeflow approach leveraging software-defined networks.", 1366 In Proceedings of the 6th International Conference on 1367 Future Internet Technologies, pp. 34-37. ACM, 2011. , 1368 2011. 1370 [SDNACS] Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo, 1371 Christian Esteve Rothenberg, Siamak Azodolmolky, Steve 1372 Uhlig, "Software-Defined Networking: A Comprehensive 1373 Survey.", arXiv preprint arXiv:1406.0440 , 2014. 1375 [SDNHistory] 1376 Feamster, Nick, Jennifer Rexford, and Ellen Zegura., "The 1377 Road to SDN", ACM Queue11, no. 12 (2013): 20. , 2013. 1379 [SDNNFV] Haleplidis, Evangelos, Jamal Hadi Salim, Spyros Denazis, 1380 and Odysseas Koufopavlou., "Towards a Network Abstraction 1381 Model for SDN.", Journal of Network and Systems Management 1382 (2014): 1-19. Special Issue on Management of Software 1383 Defined Networks, Springer , 2014. 1385 [SDNSecOF] 1386 Kloti, Rowan, Vasileios Kotronis, and Paul Smith., 1387 "Openflow: A security analysis.", Proceedings Workshop on 1388 Secure Network Protocols (NPSec). IEEE (2013). , 2013, 1389 . 1391 [SDNSecServ] 1392 Sandra Scott-Hayward, Gemma O'Callaghan, and Sakir Sezer., 1393 "SDN security: A survey.", In Future Networks and Services 1394 (SDN4FNS), 2013 IEEE SDN for, pp. 1-7. IEEE, 2013. , 2013. 1396 [SDNSecurity] 1397 Diego Kreutz, Fernando Ramos, and Paulo Verissimo., 1398 "Towards secure and dependable software-defined 1399 networks.", In Proceedings of the second ACM SIGCOMM 1400 workshop on Hot topics in software defined networking, pp. 1401 55-60. ACM, 2013. , 2013. 1403 [SDNSurvey] 1404 Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen, 1405 Katia Obraczka, and Thierry Turletti, "A Survey of 1406 Software-Defined Networking: Past, Present, and Future of 1407 Programmable Networks", IEEE Communications Surveys and 1408 Tutorials DOI:10.1109/SURV.2014.012214.00180 , 2014. 1410 [SLTSDN] Yosr Jarraya, Taous Madi, and Mourad Debbabi, "A Survey 1411 and a Layered Taxonomy of Software-Defined Networking", To 1412 be published in Communications Surveys and Tutorials, IEEE 1413 Issue: 99 , 2014. 1415 [SoftRouter] 1416 Lakshman, T. V., T. Nandagopal, R. Ramjee, K. Sabnani, and 1417 T. Woo., "The softrouter architecture.", In Proc. ACM 1418 SIGCOMM Workshop on Hot Topics in Networking. 2004. , 1419 2004. 1421 [Tempest] Rooney, Sean, Jacobus E. van der Merwe, Simon A. Crosby, 1422 and Ian M. Leslie., "The Tempest: a framework for safe, 1423 resource assured, programmable networks.", Communications 1424 Magazine, IEEE 36, no. 10 (1998): 42-53 , 1998. 1426 Authors' Addresses 1428 Evangelos Haleplidis (editor) 1429 University of Patras 1430 Department of Electrical and Computer Engineering 1431 Patras 26500 1432 Greece 1434 Email: ehalep@ece.upatras.gr 1436 Kostas Pentikousis (editor) 1437 EICT GmbH 1438 Torgauer Strasse 12-15 1439 10829 Berlin 1440 Germany 1442 Email: k.pentikousis@eict.de 1444 Spyros Denazis 1445 University of Patras 1446 Department of Electrical and Computer Engineering 1447 Patras 26500 1448 Greece 1450 Email: sdena@upatras.gr 1451 Jamal Hadi Salim 1452 Mojatatu Networks 1453 Suite 400, 303 Moodie Dr. 1454 Ottawa, Ontario K2H 9R4 1455 Canada 1457 Email: hadi@mojatatu.com 1459 David Meyer 1460 Brocade 1462 Email: dmm@1-4-5.net 1464 Odysseas Koufopavlou 1465 University of Patras 1466 Department of Electrical and Computer Engineering 1467 Patras 26500 1468 Greece 1470 Email: odysseas@ece.upatras.gr