diff options
Diffstat (limited to 'doc/rfc/rfc7149.txt')
| -rw-r--r-- | doc/rfc/rfc7149.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7149.txt b/doc/rfc/rfc7149.txt new file mode 100644 index 0000000..52d12a0 --- /dev/null +++ b/doc/rfc/rfc7149.txt @@ -0,0 +1,1123 @@ + + + + + + +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 + +Abstract + + Software-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. + + + + + + + + + + +Boucadair & Jacquenet Informational [Page 1] + +RFC 7149 On SDN March 2014 + + +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. + +Table of Contents + + 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 + + + + + + + + + + +Boucadair & Jacquenet Informational [Page 2] + +RFC 7149 On SDN March 2014 + + +1. Introduction + + The Internet has become the federative network that supports a wide + range of service offerings. The delivery of network services such as + IP VPNs assumes the combined activation of various capabilities that + include (but are not necessarily limited to) forwarding and routing + (e.g., customer-specific addressing scheme management, dynamic path + computation to reach a set of destination prefixes, dynamic + establishment of tunnels, etc.); Quality of Service (e.g., traffic + classification, marking, conditioning, and scheduling); security + (e.g., filters to protect customer premises from network-originated + attacks, to avoid malformed route announcements, etc.); and + management (e.g., fault detection and processing). + + As these services not only grow in variety but also in complexity, + their design, delivery, and operation have become a complex alchemy + that often requires various levels of expertise. This situation is + further aggravated by the wide variety of (network) protocols and + tools, as well as recent convergence trends driven by Any Time, Any + Where, Any Device (ATAWAD); ATAWADs are meant to make sure that an + end user can access the whole range of services he/she has subscribed + to whatever the access and device technologies, wherever the end user + is connected to the network, and whether or not this end user is in + motion. + + Yet, most of these services have been deployed for the past decade, + primarily based upon often static service production procedures that + are more and more exposed to the risk of erroneous configuration + commands. In addition, most of these services do not assume any + specific negotiation between the customer and the service provider or + between service providers, besides the typical financial terms. + + At best, five-year master plans are referred to as the network + planning policy that will be enforced by the service provider given + the foreseen business development perspectives, manually computed + traffic forecasts, and market coverage (fixed/mobile and residential/ + corporate). This so-called network planning policy may very well + affect the way resources are allocated in a network, but it clearly + fails to be adequately responsive to highly dynamic customer + requirements in an "always-on" fashion. The need for improved + service delivery procedures (including the time it takes to deliver + the service once the possible negotiation phase is completed) is even + more critical for corporate customers. + + + + + + + + +Boucadair & Jacquenet Informational [Page 3] + +RFC 7149 On SDN March 2014 + + + 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. + +2. Introducing Software-Defined Networking + +2.1. A Tautology? + + The separation of the forwarding and control planes (beyond + implementation considerations) has almost become a gimmick to promote + flexibility as a key feature of the SDN approach. Technically, most + of the current router implementations have been assuming this + separation for decades. Routing processes (such as IGP and BGP route + computation) have often been software based, while forwarding + capabilities are usually implemented in hardware. + + As such, at the time of writing, what is considered to be state of + the art tends to confirm the said separation, which rather falls + under a tautology. + + But, a somewhat centralized, "controller-embedded", control plane for + the sake of optimized route computation before the Forwarding + Information Base (FIB) population is certainly another story. + +2.2. On Flexibility + + Promoters of SDN have argued that it provides additional flexibility + in how the network is operated. This is undoubtedly one of the key + objectives that must be achieved by service providers. This is + because the ability to dynamically adapt to a wide range of customer + requests for flexible network service delivery is an important + competitive advantage. But, flexibility is much, much more than + separating the control and forwarding planes to facilitate forwarding + decision-making processes. + + + + + + +Boucadair & Jacquenet Informational [Page 4] + +RFC 7149 On SDN March 2014 + + + 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. + +2.3. A Tentative Definition + + We define Software-Defined Networking as the set of techniques used + to facilitate the design, delivery, and operation of network services + in a deterministic, dynamic, and scalable manner. The said + determinism refers to the ability to completely master the various + components of the service delivery chain, so that the service that + has been delivered complies with what has been negotiated and + contractually defined with the customer. + + As such, determinism implies that the ability to control how network + services are structured, designed, and delivered and where traffic + should be forwarded in the network is for optimized resource usage. + Although not explicitly restated in the following sections of the + document, determinism lies beneath any action that may be taken by a + service provider once service parameter negotiation is completed, + from configuration tasks to service delivery, fulfillment, and + assurance (see Section 2.4 below). + + + +Boucadair & Jacquenet Informational [Page 5] + +RFC 7149 On SDN March 2014 + + + 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. + +2.4. Functional Metadomains + + SDN techniques can be classified into the following functional + metadomains: + + o Techniques for the dynamic discovery of network topology, devices, + and capabilities, along with relevant information and data models + that are meant to precisely document such topology, devices, and + their capabilities. + + o Techniques for exposing network services and their characteristics + and for dynamically negotiating the set of service parameters that + will be used to measure the level of quality associated with the + delivery of a given service or a combination thereof. An example + of this can be seen in [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. + +3. Reality Check + + The networking ecosystem has become awfully complex and highly + demanding in terms of robustness, performance, scalability, + flexibility, agility, etc. This means, in particular, that service + providers and network operators must deal with such complexity and + operate networking infrastructures that can evolve easily, remain + scalable, guarantee robustness and availability, and are resilient to + denial-of-service attacks. + + + + +Boucadair & Jacquenet Informational [Page 6] + +RFC 7149 On SDN March 2014 + + + The introduction of new SDN-based networking features should + obviously take into account this context, especially from a cost + impact assessment perspective. + +3.1. Remember the Past + + SDN techniques are not the next big thing per se but rather a kind of + rebranding of proposals that have been investigated for several + years, like active or programmable networks [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. + + + + +Boucadair & Jacquenet Informational [Page 7] + +RFC 7149 On SDN March 2014 + + +3.2. Be Pragmatic + + SDN approaches should be holistic, i.e., global and network wide. It + is not a matter of configuring devices one by one to enforce a + specific forwarding policy. Instead, SDN techniques are about + configuring and operating a whole range of devices at the scale of + the network for automated service delivery [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. + +3.3. Measure Experience against Expectations + + Because several software modules may be controlled by external + entities (typically, a PDP), there is a need for a means to make sure + that what has been delivered complies with what has been negotiated. + Such means belong to the set of SDN techniques. + + These typical policy-based techniques should interact with both + Service Structuring engines (that are meant to expose the service + characteristics and possibly negotiate those characteristics) and the + network to continuously assess whether the experienced network + behavior is compliant with the objectives set by the Service + Structuring engine and those that may have been dynamically + negotiated with the customer (e.g., as captured in a CPP [CPP] + [CPNP]). This requirement applies to several regions of a network, + including: + + + +Boucadair & Jacquenet Informational [Page 8] + +RFC 7149 On SDN March 2014 + + + 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. + +3.4. Design Carefully + + Exposing open and programmable interfaces has a cost from both + scalability and performance standpoints. + + Maintaining hard-coded performance optimization techniques is + encouraged. So is the use of interfaces that allow the direct + control of some engines (e.g., routing and forwarding) without + requiring any in-between adaptation layers (generic objects to + vendor-specific command line interfaces (CLIs), for instance). + Nevertheless, the use of vendor-specific access means to some engines + that it could be beneficial from a performance standpoint, at the + cost of increasing the complexity of configuration tasks. + + SDN techniques will have to accommodate vendor-specific components + anyway. Indeed, these vendor-specific features will not cease to + exist mainly because of the harsh competition. + + The introduction of new functions or devices that may jeopardize + network flexibility should be avoided or at least carefully + considered in light of possible performance and scalability impacts. + SDN-enabled devices will have to coexist with legacy systems. + + One single SDN network-wide deployment is, therefore, very unlikely. + Instead, multiple instantiations of SDN techniques will be + progressively deployed and adapted to various network and service + segments. + +3.5. On OpenFlow + + Empowering networking with in-band controllable modules may rely upon + the OpenFlow protocol but also use other protocols to exchange + information between a control plane and a data plane. + + + + +Boucadair & Jacquenet Informational [Page 9] + +RFC 7149 On SDN March 2014 + + + 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. + +3.6. Non-goals + + There are inevitable trade-offs to be found between operating the + current networking ecosystem and introducing some SDN techniques, + possibly at the cost of introducing new technologies. Operators do + not have to choose between the two as both environments will have to + coexist. + + In particular, the following considerations cannot justify the + deployment of SDN techniques: + + o Fully flexible software implementations because the claimed + flexibility remains limited by the software and hardware + limitations, anyway. + + o Fully modular implementations are difficult to achieve (because of + the implicit complexity) and may introduce extra effort for + testing, validation, and troubleshooting. + + o Fully centralized control systems that are likely to raise some + scalability issues. Distributed protocols and their ability to + react to some events (e.g., link failure) in a timely manner + remains a cornerstone of scalable networks. This means that SDN + designs can rely upon a logical representation of centralized + features (an abstraction layer that would support inter-PDP + communications, for example). + + + + + + + + + + + +Boucadair & Jacquenet Informational [Page 10] + +RFC 7149 On SDN March 2014 + + +4. Discussion + +4.1. Implications of Full Automation + + The path towards full automation is paved with numerous challenges + and requirements, including: + + o Making sure automation is well implemented so as to facilitate + testing (including validation checks) and troubleshooting. + + * This suggests the need for simulation tools that accurately + assess the impact of introducing a high level of automation in + the overall service delivery procedure to avoid a typical "mad + robot" syndrome, whose consequences can be serious from control + and QoS standpoints, among others. + + * This also suggests careful management of human expertise, so + that network operators can use robust, flexible means to + automate repetitive or error-prone tasks and then build on + automation or stringing together multiple actions to create + increasingly complex tasks that require less human interaction + (guidance and input) to complete. + + o Simplifying and fostering service delivery, assurance, and + fulfillment, as well as network failure detection, diagnosis, and + root cause analysis for cost optimization. + + * Such cost optimization relates to improved service delivery + times as well as optimized human expertise (see above) and + global, technology-agnostic service structuring and delivery + procedures. In particular, the ability to inject new functions + in existing devices should not assume a replacement of the said + devices but rather allow smart investment capitalization. + + * This can be achieved thanks to automation, possibly based upon + a logically centralized view of the network infrastructure (or + a portion thereof), yielding the need for highly automated + topology, device and capabilities discovery means, and + operational procedures. + + * The main intelligence resides in the PDP, which suggests that + an important part of the SDN-related development effort should + focus on a detailed specification of the PDP function, + including algorithms and behavioral state machineries that are + based upon a complete set of standardized data and information + models. + + + + + +Boucadair & Jacquenet Informational [Page 11] + +RFC 7149 On SDN March 2014 + + + * 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). + +4.2. Bootstrapping an SDN + + Means to dynamically discover the functional capabilities of the + devices that will be steered by a PDP intelligence for automated + network service delivery need to be provided. This is because the + acquisition of the information related to what the network is + actually capable of will help structure the PDP intelligence so that + policy provisioning information can be derived accordingly. + + A typical example would consist in documenting a traffic engineering + policy based upon the dynamic discovery of the various functions + supported by the network devices, as a function of the services to be + + + +Boucadair & Jacquenet Informational [Page 12] + +RFC 7149 On SDN March 2014 + + + 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. + + + +Boucadair & Jacquenet Informational [Page 13] + +RFC 7149 On SDN March 2014 + + + 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. + +4.3. Operating an SDN + + From an Operations and Management (OAM) standpoint [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)? + + + + + +Boucadair & Jacquenet Informational [Page 14] + +RFC 7149 On SDN March 2014 + + + 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. + +4.4. The Intelligence Resides in the PDP + + The proposed SDN definition in 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. + + + + + + +Boucadair & Jacquenet Informational [Page 15] + +RFC 7149 On SDN March 2014 + + + 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. + +4.5. Simplicity and Adaptability vs. Complexity + + The functional metadomains introduced in 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. + +4.6. Performance and Scalability + + The combination of flexibility with software inevitably raises + performance and scalability issues as a function of the number and + the nature of the services to be delivered and their associated + dynamics. + + + + +Boucadair & Jacquenet Informational [Page 16] + +RFC 7149 On SDN March 2014 + + + 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. + +4.7. Risk Assessment + + Various risks are to be assessed such as: + + o Evaluating the risk of depending on a controller technology rather + than a device technology. + + o Evaluating the risk of operating frozen architectures because of + potential interoperability issues between a controller and a + controlled device. + + o Assessing whether SDN-labeled solutions are likely to obsolete + existing technologies because of hardware limitations. From a + technical standpoint, the ability to dynamically provision + resources as a function of the services to be delivered may be + incompatible with legacy routing systems because of their hardware + limitations, for example. Likewise, from an economical + standpoint, the use of SDN solutions for the sake of flexibility + and automation may dramatically impact Capital Expenditure (CAPEX) + and Operational Expenditure (OPEX) budgets. + +5. Security Considerations + + Security is an important aspect of any SDN design because it + conditions the robustness and reliability of the interactions between + network and applications people for efficient access control + procedures and optimized protection of SDN resources against any kind + of attack. In particular, SDN security policies [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 + + + + + +Boucadair & Jacquenet Informational [Page 17] + +RFC 7149 On SDN March 2014 + + + 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.). + +6. Acknowledgements + + Many thanks to R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S. + Farrell, W. George, J. Halpern, D. King, J. Hadi Salim, and T. Tsou + for their comments. Special thanks to P. Georgatos for the fruitful + discussions on SDN Interconnection (SDNI) in particular. + +7. Informative References + + [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. + + + + + + +Boucadair & Jacquenet Informational [Page 18] + +RFC 7149 On SDN March 2014 + + + [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. + + + + + +Boucadair & Jacquenet Informational [Page 19] + +RFC 7149 On SDN March 2014 + + + [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. + +Authors' Addresses + + Mohamed Boucadair + France Telecom + Rennes 35000 + France + + EMail: mohamed.boucadair@orange.com + + + Christian Jacquenet + France Telecom + Rennes + France + + EMail: christian.jacquenet@orange.com + + + + + + + + + + + + + + + + + + + + + + +Boucadair & Jacquenet Informational [Page 20] + |