Internet Engineering Task Force (IETF) M. Boucadair Request for Comments: 7149 C. Jacquenet Category: Informational France Telecom ISSN: 2070-1721 March 2014 Software-Defined Networking: A Perspective from within a Service Provider Environment
AbstractSoftware-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7149.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................3 2. Introducing Software-Defined Networking .........................4 2.1. A Tautology? ...............................................4 2.2. On Flexibility .............................................4 2.3. A Tentative Definition .....................................5 2.4. Functional Metadomains .....................................6 3. Reality Check ...................................................6 3.1. Remember the Past ..........................................7 3.2. Be Pragmatic ...............................................8 3.3. Measure Experience against Expectations ....................8 3.4. Design Carefully ...........................................9 3.5. On OpenFlow ................................................9 3.6. Non-goals .................................................10 4. Discussion .....................................................11 4.1. Implications of Full Automation ...........................11 4.2. Bootstrapping an SDN ......................................12 4.3. Operating an SDN ..........................................14 4.4. The Intelligence Resides in the PDP .......................15 4.5. Simplicity and Adaptability vs. Complexity ................16 4.6. Performance and Scalability ...............................16 4.7. Risk Assessment ...........................................17 5. Security Considerations ........................................17 6. Acknowledgements ...............................................18 7. Informative References .........................................18
In addition, various tools are used for different, sometimes service- centric, management purposes, but their usage is not necessarily coordinated for event aggregation, correlation, and processing. This lack of coordination may come at the cost of extra complexity and possible customer Quality-of-Experience degradation. Multi-service, multi-protocol, multi-technology-convergent, and dynamically adaptive networking environments of the near future have therefore become one of the major challenges faced by service providers. This document aims to clarify the SDN landscape by providing a perspective on the functional taxonomy of the techniques that can be used in SDN, as seen from within a service provider environment.
For example, the ability to accommodate short duration extra bandwidth requirements so that end users can stream a video file to their 4G terminal device is an example of the flexibility that several mobile operators are currently investigating. From this perspective, the ability to predict the network behavior as a function of the network services to be delivered is of paramount importance for service providers, so that they can assess the impact of introducing new services or activating additional network features or enforcing a given set of (new) policies from both financial and technical standpoints. This argues in favor of investigating advanced network emulation engines, which can be fed with information that can be derived from [LS-DISTRIB], for example. Given the rather broad scope that the term "flexibility" suggests: o Current SDN-labeled solutions are claimed to be flexible, although the notion is hardly defined. The exact characterization of what flexibility actually means is yet to be provided. Further work needs, therefore, to be conducted so that flexibility can be precisely defined in light of various criteria such as network evolution capabilities as a function of the complexity introduced by the integration of SDN techniques and seamless capabilities (i.e., the ability to progressively introduce SDN-enabled devices without disrupting network and service operation, etc.). o The exposure of programmable interfaces is not a goal per se; rather, it is a means to facilitate configuration procedures for improved flexibility. Section 2.4 below).
Such a definition assumes the introduction of a high level of automation in the overall service delivery and operation procedures. Because networking is software driven by nature, the above definition does not emphasize the claimed "software-defined" properties of SDN- labeled solutions. CPP]. o Techniques used by service-requirement-derived dynamic resource allocation and policy enforcement schemes, so that networks can be programmed accordingly. Decisions made to dynamically allocate resources and enforce policies are typically the result of the correlation of various inputs, such as the status of available resources in the network at any given time, the number of customer service subscription requests that need to be processed over a given period of time, the traffic forecasts, the possible need to trigger additional resource provisioning cycles according to a typical multi-year master plan, etc. o Dynamic feedback mechanisms that are meant to assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspective.
The introduction of new SDN-based networking features should obviously take into account this context, especially from a cost impact assessment perspective. AN] [PN]. As a matter of fact, some of the claimed "new" SDN features have been already implemented (e.g., Network Management System (NMS) and Path Computation Element (PCE) [RFC4655]) and supported by vendors for quite some time. Some of these features have also been standardized (e.g., DNS-based routing [RFC1383]) that can be seen as an illustration of separated control and forwarding planes or Forwarding and Control Element Separation (ForCES) [RFC5810] [RFC5812]. Also, the policy-based management framework [RFC2753] introduced in the early 2000's was designed to orchestrate available resources by means of a typical Policy Decision Point (PDP), which masters advanced offline traffic engineering capabilities. As such, this framework has the ability to interact with in-band software modules embedded in controlled devices (or not). PDP is where policy decisions are made. PDPs use a directory service for policy repository purposes. The policy repository stores the policy information that can be retrieved and updated by the PDP. The PDP delivers policy rules to the Policy Enforcement Point (PEP) in the form of policy-provisioning information that includes configuration information. PEP is where policy decisions are applied. PEPs are embedded in (network) devices, which are dynamically configured based upon the policy-formatted information that has been processed by the PEP. PEPs request configuration from the PDP, store the configuration information in the Policy Information Base (PIB), and delegate any policy decision to the PDP. SDN techniques as a whole are an instantiation of the policy-based management framework. Within this context, SDN techniques can be used to activate capabilities on demand, to dynamically invoke network and storage resources, and to operate dynamically adaptive networks according to events (e.g., alteration of the network topology), triggers (e.g., dynamic notification of a link failure), etc.
AUTOMATION], from service negotiation (e.g., [CPNP]) and creation (e.g., [SLA-EXCHANGE]) to assurance and fulfillment. Because the complexity of activating SDN capabilities is largely hidden from the end user and is software handled, a clear understanding of the overall ecosystem is needed to figure out how to manage this complexity and to what extent this hidden complexity does not have side effects on network operation. As an example, SDN designs that assume a central decision-making entity must avoid single points of failure. They must not affect packet forwarding performances either (e.g., transit delays must not be impacted). SDN techniques are not necessary to develop new network services per se. The basic service remains as (IP) connectivity that solicits resources located in the network. SDN techniques can thus be seen as another means to interact with network service modules and invoke both connectivity and storage resources accordingly in order to meet service-specific requirements. By definition, SDN technique activation and operation remain limited to what is supported by embedded software and hardware. One cannot expect SDN techniques to support unlimited customizable features. CPP] [CPNP]). This requirement applies to several regions of a network, including:
1. At the interface between two adjacent IP network providers. 2. At the access interface between a service provider and an IP network provider. 3. At the interface between a customer and the IP network provider. Ideally, a fully automated service delivery procedure, from negotiation, ordering, and order processing to delivery, assurance, and fulfillment, should be supported at the cost of implications that are discussed in Section 4.1. This approach also assumes widely adopted standard data and information models in addition to interfaces.
Indeed, there are many other candidate protocols that can be used for the same or even a broader purpose (e.g., resource reservation purposes). The forwarding of the configuration information can, for example, rely upon protocols like the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440], the Network Configuration Protocol (NETCONF) [RFC6241], COPS Usage for Policy Provisioning (COPS-PR) [RFC3084], Routing Policy Specification Language (RPSL) [RFC2622], etc. There is, therefore, no 1:1 relationship between OpenFlow and SDN. Rather, OpenFlow is one of the candidate protocols to convey specific configuration information towards devices. As such, OpenFlow is one possible component of the global SDN toolkit.
* These information models and data need to be carefully structured for efficiency and flexibility. This probably suggests that a set of simplified pseudo-blocks can be assembled as per the nature of the service to be delivered. o The need for abstraction layers -- clear interfaces between business actors and between layers, let alone cross-layer considerations, etc. Such abstraction layers are invoked within the context of service structuring and packaging and are meant to facilitate the emergence of the following: * IP connectivity service exposure to customers, peers, applications, content/service providers, etc. (an example of this can be seen in [CPP]). * Solutions that accommodate IP connectivity service requirements with network engineering objectives. * Dynamically adaptive decision-making processes, which can properly operate according to a set of input data and metrics, such as current resource usage and demand, traffic forecasts and matrices, etc., all for the sake of highly responsive dynamic resource allocation and policy enforcement schemes. o Better accommodation of technologically heterogeneous networking environments through the following: * Vendor-independent configuration procedures based upon the enforcement of vendor-agnostic generic policies instead of vendor-specific languages. * Tools to aid manageability and orchestrate resources. * Avoiding proxies and privileging direct interaction with engines (e.g., routing and forwarding).
delivered, thus yielding the establishment of different routes towards the same destination depending on the nature of the traffic, the location of the functions that need to be invoked to forward such traffic, etc. Such dynamic discovery capability can rely upon the exchange of specific information by means of an IGP or BGP between network devices or between network devices and the PDP in legacy networking environments. The PDP can also send unsolicited commands towards network devices to acquire the description of their functional capabilities in return and derive network and service topologies accordingly. Of course, SDN techniques (as introduced in Section 2.4) could be deployed in an IGP-/BGP-free networking environment, but the SDN bootstrapping procedure in such an environment still assumes the support of the following capabilities: o Dynamically discover SDN participating nodes (including the PDP) and their respective capabilities in a resilient manner, assuming the mutual authentication of the PDP and the participating devices Section 5. The integrity of the information exchanged between the PDP and the participating devices during the discovery phase must also be preserved; o Dynamically connect the PDP to the participating nodes and avoid any forwarding loops; o Dynamically enable network services as a function of the device capabilities and (possibly) what has been dynamically negotiated between the customer and the service provider; o Dynamically check connectivity between the PDP and the participating nodes and between participating nodes for the delivery of a given network service (or a set thereof); o Dynamically assess the reachability scope as a function of the service to be delivered; o Dynamically detect and diagnose failures, and proceed with corrective actions accordingly. Likewise, the means to dynamically acquire the descriptive information (including the base configuration) of any network device that may participate in the delivery of a given service should be provided so as to help the PDP structure the services that can be delivered as a function of the available resources, their location, etc.
In IGP-/BGP-free networking environments, a specific bootstrap protocol may thus be required to support the aforementioned capabilities for proper PDP- and SDN-capable device operation, in addition to the possible need for a specific additional network that would provide discovery and connectivity features. In particular, SDN design and operation in IGP-/BGP-free environments should provide performances similar to those of legacy environments that run an IGP and BGP. For example, the underlying network should remain operational even if connection with the PDP has been lost. Furthermore, operators should assess the cost of introducing a new, specific bootstrap protocol compared to the cost of integrating the aforementioned capabilities in existing IGP/BGP protocol machineries. Since SDN-related features can be grafted into an existing network infrastructure, they may not be all enabled at once from a bootstrapping perspective; a gradual approach can be adopted instead. A typical deployment example would be to use an SDN decision-making process as an emulation platform that would help service providers and operators make appropriate technical choices before their actual deployment in the network. Finally, the completion of the discovery procedure does not necessarily mean that the network is now fully operational. The operationality of the network usually assumes a robust design based upon resilience and high availability features. RFC6291], running an SDN-capable network raises several issues such as those listed below: o How do SDN service and network management blocks interact? For example, how the results of the dynamic negotiation of service parameters with a customer or a set thereof over a given period of time will affect the PDP decision-making process (resource allocation, path computation, etc.). o What should be the appropriate OAM tools for SDN network operation (e.g., to check PDP or PEP reachability)? o How can performance (expressed in terms of service delivery time, for example) be optimized when the activation of software modules is controlled by an external entity (typically a PDP)?
o To what extent does an SDN implementation ease network manageability, including service and network diagnosis? o Should the "control and data plane separation" principle be applied to the whole network or a portion thereof, as a function of the nature of the services to be delivered or by taking into account the technology that is currently deployed? o What is the impact on the service provider's testing procedures and methodologies (that are used during validation and pre- deployment phases)? Particularly, (1) how test cases will be defined and executed when the activation of customized modules is supported, (2) what the methodology is to assess the behavior of SDN-controlled devices, (3) how test regression will be conducted, (4) etc. o How do SDN techniques impact service fulfillment and assurance? How the resulting behavior of SDN devices (completion of configuration tasks, for example) should be assessed against what has been dynamically negotiated with a customer. How to measure the efficiency of dynamically enforced policies as a function of the service that has been delivered. How to measure that what has been delivered is compliant with what has been negotiated. What the impact is of SDN techniques on troubleshooting practice. o Is there any risk to operate frozen architectures because of potential interoperability issues between a controlled device and an SDN controller? o How does the introduction of SDN techniques affect the lifetime of legacy systems? Is there any risk of (rapidly) obsoleting existing technologies because of their hardware or software limitations? The answers to the above questions are very likely to be service provider specific, depending on their technological and business environments. Section 2.3 assumes an intelligence that may reside in the control or the management planes (or both). This intelligence is typically represented by a Policy Decision Point (PDP) [RFC2753], which is one of the key functional components of the policy-based management framework.
SDN networking, therefore, relies upon PDP functions that are capable of processing various input data (traffic forecasts, outcomes of negotiation between customers and service providers, resource status as depicted in appropriate information models instantiated in the PIB, etc.) to make appropriate decisions. The design and the operation of such PDP-based intelligence in a scalable manner remains a part of the major areas that need to be investigated. To avoid centralized design schemes, inter-PDP communication is likely to be required, and corresponding issues and solutions should be considered. Several PDP instances may thus be activated in a given domain. Because each of these PDP instances may be responsible for making decisions about the enforcement of a specific policy (e.g., one PDP for QoS policy enforcement purposes, another one for security policy enforcement purposes, etc.), an inter-PDP communication scheme is required for global PDP coordination and correlation. Inter-domain PDP exchanges may also be needed for specific usages. Examples of such exchanges are as follows: (1) during the network attachment phase of a node to a visited network, the PDP operated by the visited network can contact the home PDP to retrieve the policies to be enforced for that node, and (2) various PDPs can collaborate in order to compute inter-domain paths that satisfy a set of traffic performance guarantees. Section 2.4 assume the introduction of a high level of automation, from service negotiation to delivery and operation. Automation is the key to simplicity, but it must not be seen as a magic button that would be hit by a network administrator whenever a customer request has to be processed or additional resources need to be allocated. The need for simplicity and adaptability, thanks to automated procedures, generally assumes some complexity that lies beneath automation.
For example, networks deployed in Data Centers (DCs) and that rely upon OpenFlow switches are unlikely to raise important FIB scalability issues. Conversely, DC interconnect designs that aim to dynamically manage Virtual Machine (VM) mobility, possibly based upon the dynamic enforcement of specific QoS policies, may raise scalability issues. The claimed flexibility of SDN networking in the latter context will have to be carefully investigated by operators. SDNSEC] should make sure that SDN resources are properly safeguarded against actions that may jeopardize network or application operations. In particular, service providers should define procedures to assess the reliability of software modules embedded in SDN nodes. Such procedures should include the means to also assess the behavior of software components (under stress conditions), detect any exploitable vulnerability, reliably proceed with software upgrades, etc. These
security guards should be activated during initial SDN node deployment and activation but also during SDN operation that implies software upgrade procedures. Although these procedures may not be SDN-specific (e.g., operators are familiar with firmware updates with or without service disruption), it is worth challenging existing practice in light of SDN deployment and operation. Likewise, PEP-PDP interactions suggest the need to make sure that (1) a PDP is entitled to solicit PEPs, so that they can apply the decisions made by the said PDP, (2) a PEP is entitled to solicit a PDP for whatever reason (request for additional configuration information, notification about the results of a set of configuration tasks, etc.), (3) a PEP can accept decisions made by a PDP, and (4) communication between PDPs within a domain or between domains is properly secured (e.g., make sure a pair of PDPs are entitled to communicate with each other, make sure the confidentiality of the information exchanged between two PDPs can be preserved, etc.). [AN] Tennenhouse, D. and D. Wetherall, "Towards an Active Network Architecture", Multimedia Computing and Networking (MMCN), January 1996. [AUTOMATION] Boucadair, M. and C. Jacquenet, "Requirements for Automated (Configuration) Management", Work in Progress, January 2014. [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, October 2013. [CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS Connectivity Provisioning Profile", Work in Progress, September 2012.
[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, November 2013. [PN] Campbell, A., De Meer, H., Kounavis, M., Kazuho, M., Vincente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, April 1999. [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992. [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 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. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011. [SDNSEC] Hartman, S. and D. Zhang, "Security Requirements in the Software Defined Networking Model", Work in Progress, April 2013. [SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, "Inter-domain SLA Exchange", Work in Progress, November 2013.