Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7426

Software-Defined Networking (SDN): Layers and Architecture Terminology

Pages: 35
Part 2 of 2 – Pages 19 to 35
First   Prev   None

Top   ToC   RFC7426 - Page 19   prevText

4. SDN Model View

We advocate that the SDN southbound interface should encompass both CPSI and MPSI. SDN controllers such as [NOX] and [Beacon] are a collection of control-plane applications and services that implement a CPSI ([NOX] and [Beacon] both use OpenFlow) and provide a northbound interface for applications. The SDN northbound interface for controllers is implemented in the Network Services Abstraction Layer (NSAL) of Figure 1. The above model can be used to describe all prominent SDN-enabling technologies in a concise manner, as we explain in the following subsections.

4.1. ForCES

The IETF Forwarding and Control Element Separation (ForCES) framework [RFC3746] consists of one model and two protocols. ForCES separates the forwarding plane from the control plane via an open interface, namely the ForCES protocol [RFC5810], which operates on entities of the forwarding plane that have been modeled using the ForCES model [RFC5812]. The ForCES model [RFC5812] is based on the fact that a network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as routing or IP switching) and yet appear as a normal integrated network element to external entities. ForCES models the forwarding plane using Logical Functional Blocks (LFBs), which, when connected in a graph, compose the Forwarding Element (FE). LFBs are described in XML, based on an XML schema.
Top   ToC   RFC7426 - Page 20
   LFB definitions include base and custom-defined datatypes; metadata
   definitions; input and output ports; operational parameters or
   components; and capabilities and event definitions.

   The ForCES model can be used to define LFBs from fine- to coarse-
   grained as needed, irrespective of whether they are physical or

   The ForCES protocol is agnostic to the model and can be used to
   monitor, configure, and control any ForCES-modeled element.  The
   protocol has very simple commands: Set, Get, and Del(ete).  The
   ForCES protocol has been designed for high throughput and fast

   With respect to Figure 1, the ForCES model [RFC5812] is suitable for
   the DAL, both for the operational and the forwarding plane, using
   LFBs.  The ForCES protocol [RFC5810] has been designed and is
   suitable for the CPSI, although it could also be utilized for the


The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF network management protocol [RFC6632]. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF protocol operations are realized as remote procedure calls (RPCs). The NETCONF protocol uses XML-based data encoding for the configuration data as well as the protocol messages. Recent studies, such as [ESNet] and [PENet], have shown that NETCONF performs better than SNMP [RFC3411]. Additionally, the YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations. YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. YANG models the hierarchical organization of data as a tree, in which each node has either a value or a set of child nodes. Additionally, YANG structures data models into modules and submodules, allowing reusability and augmentation. YANG models can describe constraints to be enforced on the data. Additionally, YANG has a set of base datatypes and allows custom-defined datatypes as well.
Top   ToC   RFC7426 - Page 21
   YANG allows the definition of NETCONF RPCs, which allows the protocol
   to have an extensible number of commands.  For RPC definitions, the
   operations names, input parameters, and output parameters are defined
   using YANG data definition statements.

   With respect to Figure 1, the YANG model [RFC6020] is suitable for
   specifying DAL for the forwarding and operational planes.  NETCONF
   [RFC6241] is suitable for the MPSI.  NETCONF is a management protocol
   [RFC6632], which was not (originally) designed for fast CP updates,
   and it might not be suitable for addressing the requirements of CPSI.

4.3. OpenFlow

OpenFlow is a framework originally developed at Stanford University and currently under active standards development [OpenFlow] through the Open Networking Foundation (ONF). Initially, the goal was to provide a way for researchers to run experimental protocols in a production network [OF08]. OpenFlow has undergone many revisions, and additional revisions are likely. The following description reflects version 1.4 [OpenFlow]. In short, OpenFlow defines a protocol through which a logically centralized controller can control an OpenFlow switch. Each OpenFlow-compliant switch maintains one or more flow tables, which are used to perform packet lookups. Distinct actions are to be taken regarding packet lookup and forwarding. A group table and an OpenFlow channel to external controllers are also part of the switch specification. With respect to Figure 1, the OpenFlow switch specifications [OpenFlow] define a DAL for the forwarding plane as well as for CPSI. The OF-CONFIG protocol [OF-CONFIG], based on the YANG model [RFC6020], provides a DAL for the forwarding and operational planes of an OpenFlow switch and specifies NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol, it shares the limitations described in the previous section.

4.4. Interface to the Routing System

Interface to the Routing System (I2RS) provides a standard interface to the routing system for real-time or event-driven interaction through a collection of protocol-based control or management interfaces. Essentially, one of the main goals of I2RS, is to make the Routing Information Base (RIB) programmable, thus enabling new kinds of network provisioning and operation. I2RS did not initially intend to create new interfaces but rather leverage or extend existing ones and define informational models for the routing system. For example, the latest I2RS problem statement
Top   ToC   RFC7426 - Page 22
   [I2RSProb] discusses previously defined IETF protocols such as ForCES
   [RFC5810], NETCONF [RFC6241], and SNMP [RFC3417].  Regarding the
   definition of informational and data models, the I2RS working group
   has opted to use the YANG [RFC6020] modeling language.

   Currently the I2RS working group is developing an Information Model
   [I2RSInfo] in regards to the Network Services Abstraction Layer for
   the I2RS agent.

   With respect to Figure 1, the I2RS architecture [I2RSArch]
   encompasses the control and application planes and uses any CPSI and
   DAL that is available, whether that may be ForCES [RFC5810], OpenFlow
   [OpenFlow], or another interface.  In addition, the I2RS agent is a
   control-plane service.  All services or applications on top of that
   belong to either the Control, Management, or Application plane.  In
   the I2RS documents, management access to the agent may be provided by
   management protocols like SNMP and NETCONF.  The I2RS protocol may
   also be mapped to the service interface as it will even provide
   access to services and applications other than control-plane services
   and applications.

4.5. SNMP

The Simple Network Management Protocol (SNMP) is an IETF-standardized management protocol and is currently at its third revision (SNMPv3) [RFC3417] [RFC3412] [RFC3414]. It consists of a set of standards for network management, including an application-layer protocol, a database schema, and a set of data objects. SNMP exposes management data (managed objects) in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried and set by managing applications. SNMP uses an extensible design for describing data, defined by Management Information Bases (MIBs). MIBs describe the structure of the management data of a device subsystem. MIBs use a hierarchical namespace containing object identifiers (OIDs). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2 [RFC2578]. An early example of SNMP in the context of SDN is discussed in [Peregrine]. With respect to Figure 1, SNMP MIBs can be used to describe DAL for the forwarding and operational planes. Similar to YANG, SNMP MIBs are able to describe DAL for the forwarding plane. SNMP, similar to NETCONF, is suited for the MPSI.
Top   ToC   RFC7426 - Page 23

4.6. PCEP

The Path Computation Element (PCE) [RFC4655] architecture defines an entity capable of computing paths for a single service or a set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for a variety of path computation problems and switching technologies. The PCE Communication Protocol (PCEP) [RFC5440] is used between a Path Computation Client (PCC) and a PCE, or between multiple PCEs. The PCE architecture represents a vision of networks that separates path computation for services, the signaling of end-to-end connections, and actual packet forwarding. The definition of online and offline path computation is dependent on the reachability of the PCE from network and Network Management System (NMS) nodes and the type of optimization request that may significantly impact the optimization response time from the PCE to the PCC. The PCEP messaging mechanism facilitates the specification of computation endpoints (source and destination node addresses), objective functions (requested algorithm and optimization criteria), and the associated constraints such as traffic parameters (e.g., requested bandwidth), the switching capability, and encoding type. With respect to Figure 1, PCE is a control-plane service that provides services for control-plane applications. PCEP may be used as an east-west interface between PCEs that may act as domain control entities (services and applications). The PCE working group is specifying extensions [PCEActive] that allow an active PCE to control, using PCEP, MPLS or GMPLS Label Switched Paths (LSPs), thus making it applicable for the CPSI for MPLS and GMPLS switches.

4.7. BFD

Bidirectional Forwarding Detection (BFD) [RFC5880] is an IETF- standardized network protocol designed for detecting path failures between two forwarding elements, including physical interfaces, subinterfaces, data link(s), and, to the extent possible, the forwarding engines themselves, with potentially very low latency. BFD can provide low-overhead failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links where there exists a return path as well. It is often implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated.
Top   ToC   RFC7426 - Page 24
   With respect to Figure 1, a BFD agent can be implemented as a
   control-plane service or application that would use the CPSI towards
   the forwarding plane to send/receive BFD packets.  However, a BFD
   agent is usually implemented as an application on the device and uses
   the forwarding plane to send/receive BFD packets and update the
   operational-plane resources accordingly.  Services and applications
   of the control and management planes that monitor or have subscribed
   to changes of resources can learn about these changes through their
   respective interfaces and take any actions as necessary.

5. Summary

This document has been developed after a thorough and detailed analysis of related peer-reviewed literature, the RFC series, and documents produced by other relevant standards organizations. It has been reviewed publicly by the wider SDN community, and we hope that it can serve as a handy tool for network researchers, engineers, and practitioners in the years to come. We conclude this document with a brief summary of the terminology of the SDN layer architecture. In general, we consider a network element as a composition of resources. Each network element has a forwarding plane (FP) that is responsible for handling packets in the data path and an operational plane (OP) that is responsible for managing the operational state of the device. Resources in the network element are abstracted by the Device and resource Abstraction Layer (DAL) to be controlled and managed by services or applications that belong to the control or management plane. The control plane (CP) is responsible for making decisions on how packets should be forwarded. The management plane (MP) is responsible for monitoring, configuring, and maintaining network devices. Service interfaces are abstracted by the Network Services Abstraction Layer (NSAL), where other network applications or services may use them. The taxonomy introduced in this document defines distinct SDN planes, abstraction layers, and interfaces; it aims to clarify SDN terminology and establish commonly accepted reference definitions across the SDN community, irrespective of specific implementation choices.

6. Security Considerations

This document does not propose a new network architecture or protocol and therefore does not have any impact on the security of the Internet. That said, security is paramount in networking; thus, it should be given full consideration when designing a network architecture or operational deployment. Security in SDN is discussed in the literature, for example, in [SDNSecurity], [SDNSecServ], and
Top   ToC   RFC7426 - Page 25
   [SDNSecOF].  Security considerations regarding specific interfaces
   (such as, for example, ForCES, I2RS, SNMP, or NETCONF) are addressed
   in their respective documents as well as in [RFC7149].

7. Informative References

[A4D05] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and H. Zhang, "A Clean Slate 4D Approach to Network Control and Management", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 5, pp. 41-54, 2005. [ALIEN] Parniewicz, D., Corin, R., Ogrodowczyk, L., Fard, M., Matias, J., Gerola, M., Fuentes, V., Toseef, U., Zaalouk, A., Belter, B., Jacob, E., and K. Pentikousis, "Design and Implementation of an OpenFlow Hardware Abstraction Layer", In Proceedings of the ACM SIGCOMM Workshop on Distributed Cloud Computing (DCC), Chicago, Illinois, USA, pp. 71-76, doi 10.1145/2627566.2627577, August 2014. [Beacon] Erickson, D., "The Beacon OpenFlow Controller", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 13-18, 2013. [CAPBR] Brewer, E., "Towards Robust Distributed Systems", In Proceedings of the Symposium on Principles of Distributed Computing (PODC), 2000. [CAPFN] Panda, A., Scott, C., Ghodsi, A., Koponen, T., and S. Shenker, "CAP for Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 91-96, 2013. [CAPGL] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services", ACM SIGACT News, Volume 33, Issue 2, pp. 51-59, 2002. [CORBA] Object Management Group, "CORBA Version 3.3", November 2012, <>. [DIOPR] Denazis, S., Miki, K., Vicente, J., and A. Campbell, "Designing Interfaces for Open Programmable Routers", In "Active Networks", Springer Berlin Heidelberg, pp. 13-24, 1999.
Top   ToC   RFC7426 - Page 26
   [ESNet]       Yu, J. and I. Al Ajarmeh, "An Empirical Study of the
                 NETCONF Protocol", Sixth International Conference on
                 Networking and Services, pp. 253-258, 2010.

   [FCAPS]       ITU, "Management Framework For Open Systems
                 Interconnection (OSI) For CCITT Applications", ITU
                 Recommendation X.700, September 1992,

   [I2RSArch]    Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
                 Nadeau, "An Architecture for the Interface to the
                 Routing System", Work in Progress,
                 draft-ietf-i2rs-architecture-07, December 2014.

   [I2RSInfo]    Bahadur, N., Folkes, R., Kini, S., and J. Medved,
                 "Routing Information Base Info Model", Work in
                 Progress, draft-ietf-i2rs-rib-info-model-04, December

   [I2RSProb]    Atlas, A., Nadeau, T., and D. Ward, "Interface to the
                 Routing System Problem Statement", Work in Progress,
                 draft-ietf-i2rs-problem-statement-05, January 2015.

   [ITUATM]      ITU, "B-ISDN ATM Layer Specification", ITU
                 Recommendation I.361, 1990,

   [ITUSG11]     ITU, "ITU-T Study Group 11: Protocols and test
                 specifications", <

   [ITUSG13]     ITU, "ITU-T Study Group 13: Future networks including
                 cloud computing, mobile and next-generation networks",

   [ITUSS7]      ITU, "Introduction to CCITT Signalling System No. 7",
                 ITU Recommendation Q.700, 1993,

   [ITUY3300]    ITU, "Framework of software-defined networking", ITU
                 Recommendation Y.3300, June 2014,
Top   ToC   RFC7426 - Page 27
   [KANDOO]      Yeganeh, S. and Y. Ganjali, "Kandoo: A Framework for
                 Efficient and Scalable Offloading of Control
                 Applications", In Proceedings of the first ACM SIGCOMM
                 workshop on Hot Topics in Software Defined Networks,
                 pp. 19-24, 2012.

   [NFVArch]     ETSI, "Network Functions Virtualisation (NFV):
                 Architectural Framework", ETSI GS NFV 002, October
                 2013, <

   [NOX]         Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado,
                 M., McKeown, N., and S. Shenker, "NOX: Towards an
                 Operating System for Networks", ACM SIGCOMM Computer
                 Communication Review, Volume 38, Issue 3, pp. 105-110,
                 July 2008.

   [NV09]        Chowdhury, N. and R. Boutaba, "Network Virtualization:
                 State of the Art and Research Challenges",
                 Communications Magazine, IEEE, Volume 47, Issue 7,
                 pp. 20-26, 2009.

   [OF-CONFIG]   Open Networking Foundation, "OpenFlow Management and
                 Configuration Protocol (OF-Config 1.1.1)", March 2013,

   [OF08]        McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,
                 G., Peterson, L., Rexford, J., Shenker, S., and J.
                 Turner, "OpenFlow: Enabling Innovation in Campus
                 Networks", ACM SIGCOMM Computer Communication Review,
                 Volume 38, Issue 2, pp. 69-74, 2008.

   [ONFArch]     Open Networking Foundation, "SDN Architecture, Version
                 1", June 2014,

   [OpenFlow]    Open Networking Foundation, "The OpenFlow Switch
                 Specification, Version 1.4.0", October 2013,
Top   ToC   RFC7426 - Page 28
   [P1520]       Biswas, J., Lazar, A., Huard, J., Lim, K., Mahjoub, S.,
                 Pau, L., Suzuki, M., Torstensson, S., Wang, W., and S.
                 Weinstein, "The IEEE P1520 standards initiative for
                 programmable network interfaces", IEEE Communications
                 Magazine, Volume 36, Issue 10, pp. 64-70, 1998.

   [PCEActive]   Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
                 Extensions for Stateful PCE", Work in Progress,
                 draft-ietf-pce-stateful-pce-10, October 2014.

   [PENet]       Hedstrom, B., Watwe, A., and S. Sakthidharan, "Protocol
                 Efficiencies of NETCONF versus SNMP for Configuration
                 Management Functions", Master's thesis, University of
                 Colorado, 2011.

   [PNSurvey99]  Campbell, A., De Meer, H., Kounavis, M., Miki, K.,
                 Vicente, J., and D. Villela, "A Survey of Programmable
                 Networks", ACM SIGCOMM Computer Communication Review,
                 Volume 29, Issue 2, pp. 7-23, September 1992.

   [Peregrine]   Chiueh, D., Tu, C., Wang, Y., Wang, P., Li, K., and Y.
                 Huang, "Peregrine: An All-Layer-2 Container Computer
                 Network", In Proceedings of the 2012 IEEE 5th
                 International Conference on Cloud Computing,
                 pp. 686-693, 2012.

   [PiNA]        Day, J., "Patterns in Network Architecture: A Return to
                 Fundamentals", Prentice Hall, ISBN 0132252422, 2008.

   [RCP]         Caesar, M., Caldwell, D., Feamster, N., Rexford, J.,
                 Shaikh, A., and J. van der Merwe, "Design and
                 Implementation of a Routing Control Platform", In
                 Proceedings of the 2nd conference on Symposium on
                 Networked Systems Design & Implementation Volume 2,
                 pp. 15-28, 2005.

   [REST]        Fielding, Roy, "Chapter 5: Representational State
                 Transfer (REST)", in Disseration "Architectural Styles
                 and the Design of Network-based Software
                 Architectures", 2000.

   [RFC0826]     Plummer, D., "Ethernet Address Resolution Protocol: Or
                 converting network protocol addresses to 48.bit
                 Ethernet address for transmission on Ethernet
                 hardware", STD 37, RFC 826, November 1982,
Top   ToC   RFC7426 - Page 29
   [RFC1953]     Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching
                 Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow
                 Management Protocol Specification for IPv4 Version
                 1.0", RFC 1953, May 1996,

   [RFC2297]     Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw,
                 F., Lyon, T., and G. Minshall, "Ipsilon's General
                 Switch Management Protocol Specification Version 2.0",
                 RFC 2297, March 1998,

   [RFC2578]     McCloghrie, K., Ed., Perkins, D., Ed., and J.
                 Schoenwaelder, Ed., "Structure of Management
                 Information Version 2 (SMIv2)", STD 58, RFC 2578, April
                 1999, <>.

   [RFC3411]     Harrington, D., Presuhn, R., and B. Wijnen, "An
                 Architecture for Describing Simple Network Management
                 Protocol (SNMP) Management Frameworks", STD 62, RFC
                 3411, December 2002,

   [RFC3412]     Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
                 "Message Processing and Dispatching for the Simple
                 Network Management Protocol (SNMP)", STD 62, RFC 3412,
                 December 2002,

   [RFC3414]     Blumenthal, U. and B. Wijnen, "User-based Security
                 Model (USM) for version 3 of the Simple Network
                 Management Protocol (SNMPv3)", STD 62, RFC 3414,
                 December 2002,

   [RFC3417]     Presuhn, R., "Transport Mappings for the Simple Network
                 Management Protocol (SNMP)", STD 62, RFC 3417, December
                 2002, <>.

   [RFC3418]     Presuhn, R., "Management Information Base (MIB) for the
                 Simple Network Management Protocol (SNMP)", STD 62, RFC
                 3418, December 2002,

   [RFC3535]     Schoenwaelder, J., "Overview of the 2002 IAB Network
                 Management Workshop", RFC 3535, May 2003,
Top   ToC   RFC7426 - Page 30
   [RFC3746]     Yang, L., Dantu, R., Anderson, T., and R. Gopal,
                 "Forwarding and Control Element Separation (ForCES)
                 Framework", RFC 3746, April 2004,

   [RFC4271]     Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
                 Protocol 4 (BGP-4)", RFC 4271, January 2006,

   [RFC4655]     Farrel, A., Vasseur, J., and J. Ash, "A Path
                 Computation Element (PCE)-Based Architecture", RFC
                 4655, August 2006,

   [RFC5424]     Gerhards, R., "The Syslog Protocol", RFC 5424, March
                 2009, <>.

   [RFC5440]     Vasseur, JP. and JL. Le Roux, "Path Computation Element
                 (PCE) Communication Protocol (PCEP)", RFC 5440, March
                 2009, <>.

   [RFC5531]     Thurlow, R., "RPC: Remote Procedure Call Protocol
                 Specification Version 2", RFC 5531, May 2009,

   [RFC5743]     Falk, A., "Definition of an Internet Research Task
                 Force (IRTF) Document Stream", RFC 5743, December 2009,

   [RFC5810]     Doria, A., Hadi Salim, J., Haas, R., Khosravi, H.,
                 Wang, W., Dong, L., Gopal, R., and J. Halpern,
                 "Forwarding and Control Element Separation (ForCES)
                 Protocol Specification", RFC 5810, March 2010,

   [RFC5812]     Halpern, J. and J. Hadi Salim, "Forwarding and Control
                 Element Separation (ForCES) Forwarding Element Model",
                 RFC 5812, March 2010,

   [RFC5880]     Katz, D. and D. Ward, "Bidirectional Forwarding
                 Detection (BFD)", RFC 5880, June 2010,

   [RFC6020]     Bjorklund, M., "YANG - A Data Modeling Language for the
                 Network Configuration Protocol (NETCONF)", RFC 6020,
                 October 2010, <>.
Top   ToC   RFC7426 - Page 31
   [RFC6241]     Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
                 Bierman, "Network Configuration Protocol (NETCONF)",
                 RFC 6241, June 2011,

   [RFC6632]     Ersue, M. and B. Claise, "An Overview of the IETF
                 Network Management Standards", RFC 6632, June 2012,

   [RFC7011]     Claise, B., Trammell, B., and P. Aitken, "Specification
                 of the IP Flow Information Export (IPFIX) Protocol for
                 the Exchange of Flow Information", STD 77, RFC 7011,
                 September 2013,

   [RFC7047]     Pfaff, B. and B. Davie, "The Open vSwitch Database
                 Management Protocol", RFC 7047, December 2013,

   [RFC7149]     Boucadair, M. and C. Jacquenet, "Software-Defined
                 Networking: A Perspective from within a Service
                 Provider Environment", RFC 7149, March 2014,

   [RFC7276]     Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
                 Weingarten, "An Overview of Operations, Administration,
                 and Maintenance (OAM) Tools", RFC 7276, June 2014,

   [RINA]        Day, J., Matta, I., and K. Mattar, "Networking is IPC:
                 A Guiding Principle to a Better Internet", In
                 Proceedings of the 2008 ACM CoNEXT Conference, Article
                 No. 67, 2008.

   [RouteFlow]   Nascimento, M., Rothenberg, C., Salvador, M., Correa,
                 C., de Lucena, S., and M. Magalhaes, "Virtual Routers
                 as a Service: The RouteFlow Approach Leveraging
                 Software-Defined Networks", In Proceedings of the 6th
                 International Conference on Future Internet
                 Technologies, pp. 34-37, 2011.

   [SDNACS]      Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C.,
                 Azodolmolky, S., and S. Uhlig, "Software-Defined
                 Networking: A Comprehensive Survey", Networking and
                 Internet Architecture (cs.NI), arXiv:1406.0440, 2014.
Top   ToC   RFC7426 - Page 32
   [SDNHistory]  Feamster, N., Rexford, J., and E. Zegura, "The Road to
                 SDN: An Intellectual History of Programmable Networks",
                 ACM Queue, Volume 11, Issue 12, 2013.

   [SDNNFV]      Haleplidis, E., Hadi Salim, J., Denazis, S., and O.
                 Koufopavlou, "Towards a Network Abstraction Model for
                 SDN", Journal of Network and Systems Management:
                 Special Issue on Management of Software Defined
                 Networks, pp. 1-19, 2014.

   [SDNSecOF]    Kloti, R., Kotronis, V., and P. Smith, "OpenFlow: A
                 Security Analysis", 21st IEEE International Conference
                 on Network Protocols (ICNP) pp. 1-6, October 2013.

   [SDNSecServ]  Scott-Hayward, S., O'Callaghan, G., and S. Sezer, "SDN
                 Security: A Survey", In IEEE SDN for Future Networks
                 and Services (SDN4FNS), pp. 1-7, 2013.

   [SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards
                 Secure and Dependable Software-Defined Networks", In
                 Proceedings of the second ACM SIGCOMM workshop on Hot
                 Topics in Software Defined Networking, pp. 55-60, 2013.

   [SDNSurvey]   Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., and
                 T.  Turletti, "A Survey of Software-Defined Networking:
                 Past, Present, and Future of Programmable Networks",
                 IEEE Communications Surveys and Tutorials,
                 DOI:10.1109/SURV.2014.012214.00180, 2014.

   [SLTSDN]      Jarraya, Y., Madi, T., and M. Debbabi, "A Survey and a
                 Layered Taxonomy of Software-Defined Networking", IEEE
                 Communications Surveys and Tutorials, Volume 16, Issue
                 4, pp. 1955-1980, 2014.

   [SoftRouter]  Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K.,
                 and T. Woo, "The SoftRouter Architecture", In
                 Proceedings of the ACM SIGCOMM Workshop on Hot Topics
                 in Networking, 2004.

   [Tempest]     Rooney, S., van der Merwe, J., Crosby, S., and I.
                 Leslie, "The Tempest: A Framework for Safe, Resource
                 Assured, Programmable Networks", Communications
                 Magazine, IEEE, Volume 36, Issue 10, pp. 42-53, 1998.
Top   ToC   RFC7426 - Page 33


The authors would like to acknowledge Salvatore Loreto and Sudhir Modali for their contributions in the initial discussion on the SDNRG mailing list as well as their document-specific comments; they helped put this document in a better shape. Additionally, we would like to thank (in alphabetical order) Shivleela Arlimatti, Roland Bless, Scott Brim, Alan Clark, Luis Miguel Contreras Murillo, Tim Copley, Linda Dunbar, Ken Gray, Deniz Gurkan, Dave Hood, Georgios Karagiannis, Bhumip Khasnabish, Sriganesh Kini, Ramki Krishnan, Dirk Kutscher, Diego Lopez, Scott Mansfield, Pedro Martinez-Julia, David E. Mcdysan, Erik Nordmark, Carlos Pignataro, Robert Raszuk, Bless Roland, Francisco Javier Ros Munoz, Dimitri Staessens, Yaakov Stein, Eve Varma, Stuart Venters, Russ White, and Lee Young for their critical comments and discussions at IETF 88, IETF 89, and IETF 90 and on the SDNRG mailing list, which we took into consideration while revising this document. We would also like to thank (in alphabetical order) Spencer Dawkins and Eliot Lear for their IRSG reviews, which further refined this document. Finally, we thank Nobo Akiya for his review of the section on BFD, Julien Meuric for his review of the section on PCE, and Adrian Farrel and Benoit Claise for their IESG reviews of this document. Kostas Pentikousis is supported by [ALIEN], a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 317880). The views expressed here are those of the author only. The European Commission is not liable for any use that may be made of the information in this document.
Top   ToC   RFC7426 - Page 34


The authors would like to acknowledge (in alphabetical order) the following persons as contributors to this document. They all provided text, pointers, and comments that made this document more complete: o Daniel King for providing text related to PCEP. o Scott Mansfield for information regarding current ITU work on SDN. o Yaakov Stein for providing text related to the CAP theorem and SDO-related information. o Russ White for text suggestions on the definitions of control, management, and application.

Authors' Addresses

Evangelos Haleplidis (editor) University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece EMail: Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 10829 Berlin Germany EMail: Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece EMail:
Top   ToC   RFC7426 - Page 35
   Jamal Hadi Salim
   Mojatatu Networks
   Suite 400, 303 Moodie Dr.
   Ottawa, Ontario  K2H 9R4


   David Meyer


   Odysseas Koufopavlou
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500