RFC 7149

Software-Defined Networking: A Perspective from within a Service Provider Environment

📅 published March 2014, from ietf

RFC 7149 📜🎀 Software-Defined Networking: A Perspective from within a Service Provider Environment

okay bestie, the paperwork first 💅 This is RFC 7149, written by M. Boucadair and C. Jacquenet from France Telecom, published in March 2014. It's Informational, which means it's not a Standards Track spec 🦋 It's also an IETF product with IETF community consensus, approved by the IESG. The title block has no Obsoletes or Updates line, so it doesn't replace or change any other RFC. The ISSN is 2070-1721.

Abstract ✨

okay so SDN (Software-Defined Networking) has been the buzzword of the networking world for a couple of years 🙈 And nobody has really agreed on what it covers. This document tries to clean up the SDN landscape 🧹 It gives a service-provider view of the requirements, issues, and other things to think about.

It's not here to debate forever what SDN "truly" means 💅 Instead it proposes a functional taxonomy of the techniques that can sit under the SDN umbrella, and it digs into the pending issues that show up when those techniques get switched on together. A definition of SDN only shows up so everyone is on the same page, so it's giving clarity, not a philosophy debate 🌸

Status of This Memo 🧾

This document is not an Internet Standards Track specification 🫶 It's published for informational purposes.

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review before the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🔥

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7149 🌈

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, which you can find at http://trustee.ietf.org/license-info, as they stand on the publication date. Please read these carefully 🙈 They spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

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

1. Introduction 🌸

The Internet has become the federative network 🌐 that supports a huge range of service offerings. Delivering network services like IP VPNs needs a bunch of capabilities working together. That includes (but isn't limited to) forwarding and routing, like customer-specific addressing scheme management, dynamic path computation to reach a set of destination prefixes, and dynamic tunnel establishment. It also includes Quality of Service, like traffic classification, marking, conditioning, and scheduling. Then there's security, like filters that protect customer premises from network-originated attacks or stop malformed route announcements. And finally management, like fault detection and processing 🛡️

As these services get more varied and more complex, designing, delivering, and running them has turned into a complicated alchemy 🧪 that often needs several levels of expertise. It gets worse with the huge variety of network protocols and tools, plus the convergence trends driven by Any Time, Any Where, Any Device (ATAWAD) 📱 ATAWADs are meant to make sure an end user can reach every service they've subscribed to, whatever the access and device technologies, wherever they're connected, and even while they're moving 🚗

Here's the tea ☕ most of these services have been deployed for the past decade, mostly using service production procedures that are pretty static and more and more exposed to the risk of erroneous configuration commands 😭 On top of that, most of these services don't involve any specific negotiation between the customer and the service provider, or between service providers, beyond the usual financial terms.

At best, five-year master plans are used as the network planning policy the service provider enforces, based on expected business growth, manually computed traffic forecasts, and market coverage (fixed/mobile and residential/corporate) 📊 That planning policy can really affect how resources get allocated in a network. But it clearly can't keep up with highly dynamic customer requirements in an "always-on" fashion 💀 Better service delivery procedures are needed, including how long it takes to deliver a service once any negotiation phase is done. This matters even more for corporate customers 💼

Also, different tools get used for different management purposes, sometimes service-centric ones, but nobody coordinates them for event aggregation, correlation, and processing 🙈 That lack of coordination can add complexity and can hurt the customer's Quality-of-Experience 😩

So multi-service, multi-protocol, multi-technology-convergent, and dynamically adaptive networking environments of the near future have become one of the biggest challenges service providers face 🏋️‍♀️

This document is trying to clear up the SDN landscape 🧹 It does that by looking at the functional taxonomy of techniques that can be used in SDN, from inside a service provider environment 🦋

2. Introducing Software-Defined Networking 💖

2.1. A Tautology? 🤔

Separating the forwarding and control planes (setting implementation details aside) has basically become a gimmick used to sell flexibility as the big feature of the SDN approach 🙃 Honestly, most router implementations have assumed this separation for decades. Routing processes, like IGP and BGP route computation, have often been software-based, while forwarding is usually done in hardware 🔧

So at the time of writing, the current state of the art kind of confirms that separation, which is more of a tautology than a breakthrough 💅

But a somewhat centralized, "controller-embedded" control plane, used to optimize route computation before the Forwarding Information Base (FIB) gets populated, is a whole different story 👑

2.2. On Flexibility 🦋

SDN promoters say it gives extra flexibility in how the network gets operated 💖 And yeah, flexibility is undeniably one of the key goals service providers need to hit. Being able to quickly adapt to a wide range of customer requests for flexible service delivery is a serious competitive advantage ✨ But flexibility is way bigger than just splitting the control and forwarding planes so forwarding decisions are easier to make 🙈

For example, handling short-lived extra bandwidth needs, so end users can stream a video file to their 4G device, is the kind of flexibility several mobile operators are currently looking into 📱🎬

From this angle, being able to predict how the network behaves based on the services being delivered is super important for service providers 🔮 That lets them assess the impact of new services, extra network features, or new sets of policies, both financially and technically. This is a good reason to look into advanced network emulation engines, which could be fed with information derived from [LS-DISTRIB], for example 🧪

Since "flexibility" is such a broad term, here's the deal 💅

  • Current SDN-labeled solutions are claimed to be flexible, but the notion is barely defined 😬 Nobody has nailed down exactly what flexibility means yet. More work is needed to define flexibility precisely, looking at criteria like network evolution capabilities as the complexity added by SDN techniques grows, and seamless capabilities (meaning the ability to progressively introduce SDN-enabled devices without disrupting network and service operation, and so on) 🧩
  • Exposing programmable interfaces isn't a goal in itself 🎀 It's a means to make configuration procedures easier, which gives you better flexibility ✨

2.3. A Tentative Definition

okay bestie, here's the working definition 🎀. SDN is 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 the service that's delivered actually matches what was negotiated and contractually defined with the customer 💅.

So determinism basically means you can control how network services are structured, designed, and delivered, and where traffic gets forwarded in the network, all for optimized resource usage 🦋. Even though the following sections don't explicitly restate this, determinism sits underneath everything a service provider does once service parameter negotiation is done, from configuration tasks all the way through service delivery, fulfillment, and assurance (see Section 2.4 below) 🫶.

This definition also assumes a high level of automation in the overall service delivery and operation procedures ⭐.

And because networking is software driven by nature, this definition doesn't really emphasize the claimed "software-defined" properties of SDN-labeled solutions 🙈.

2.4. Functional Metadomains

SDN techniques can be sorted into the following functional metadomains 🧚:

  • 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.
  • 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].
  • Techniques used by service-requirement-derived dynamic resource allocation and policy enforcement schemes, so networks can be programmed accordingly. Decisions to dynamically allocate resources and enforce policies are typically the result of correlating 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.
  • 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 gotten awfully complex and seriously demanding when it comes to robustness, performance, scalability, flexibility, agility, etc. 😭 This means service providers and network operators have to deal with all that complexity and run networking infrastructures that can evolve easily, remain scalable, guarantee robustness and availability, and stay resilient to denial-of-service attacks.

Any new SDN-based networking features should obviously take this context into account, especially from a cost impact assessment perspective 💜.

3.1. Remember the Past

SDN techniques aren't the next big thing per se. They're more of a rebrand 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 are already implemented (e.g., Network Management System (NMS) and Path Computation Element (PCE) [RFC4655]) and have been supported by vendors for quite some time 💅.

Some of these features have also been standardized (e.g., DNS-based routing [RFC1383]), which 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 can 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 🧠.

Put it all together and 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. ⭐

3.2. Be Pragmatic

SDN approaches should be holistic, i.e., global and network wide 🌍. It's 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]) all the way to assurance and fulfillment 💖.

Because the complexity of activating SDN capabilities is largely hidden from the end user and is software handled, you need a clear understanding of the overall ecosystem 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 performance either (e.g., transit delays must not be impacted) 😬.

SDN techniques aren't necessary to develop new network services per se. The basic service remains (IP) connectivity, which 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 embedded software and hardware support. 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's 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 (which are meant to expose the service characteristics and possibly negotiate those characteristics) and the network, so they can continuously assess whether the experienced network behavior complies with the objectives set by the Service Structuring engine and with 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:

  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 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, using vendor-specific access means to some engines 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 won't 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 it can also use other protocols to exchange information between a control plane and a data plane 🔁.

Indeed, there are many other candidate protocols that can be used for the same purpose or even a broader one (e.g., resource reservation purposes). The forwarding of 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 for conveying specific configuration information towards devices. As such, OpenFlow is one possible component of the global SDN toolkit 🧰.

3.6. Non-goals 🙅‍♀️

Okay so, the current networking ecosystem and some SDN techniques are going to have trade-offs, and sometimes those might mean bringing in new technologies. Operators don't have to pick one or the other, bestie, because both environments are going to have to coexist 🫶

That said, there are some things that are NOT a good enough reason to deploy SDN techniques 💀

  • Fully flexible software implementations, because the flexibility you're promised is still limited by software and hardware limitations anyway. Not it 🙅‍♀️
  • Fully modular implementations, which are hard to achieve (because of the implicit complexity) and can mean extra effort for testing, validation, and troubleshooting 😩
  • Fully centralized control systems, which 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 are still a cornerstone of scalable networks 🧱 So SDN designs can lean on a logical representation of centralized features (an abstraction layer that would support inter-PDP communications, for example) ✨

4. Discussion 💬

4.1. Implications of Full Automation 🤖

The road to full automation is absolutely paved with challenges and requirements, and here's the tea 🍵

  • Making sure automation is well implemented so it's easy to test (including validation checks) and troubleshoot 🔍
    • This means you'll need simulation tools that accurately assess the impact of a high level of automation on the overall service delivery procedure, so you don't get a "mad robot" syndrome. Those consequences can be seriously bad from control and QoS standpoints, among others 😭
    • This also means managing human expertise carefully, so network operators can use robust, flexible means to automate repetitive or error-prone tasks. Then they can build on that automation, or string multiple actions together, to create increasingly complex tasks that need less human interaction (guidance and input) to finish 🧚
  • Simplifying and fostering service delivery, assurance, and fulfillment, plus network failure detection, diagnosis, and root cause analysis, all for cost optimization 💖
    • That cost optimization is about improved service delivery times, optimized human expertise (see above), and global, technology-agnostic service structuring and delivery procedures. Specifically, being able to inject new functions into existing devices should not assume you replace those devices, and should instead allow smart investment capitalization 🦋
    • This can happen thanks to automation, possibly based on a logically centralized view of the network infrastructure (or a portion of it). That brings the need for highly automated topology, device, and capabilities discovery means, plus operational procedures 🌸
    • The main intelligence lives in the PDP, so an important part of the SDN development effort should focus on a detailed specification of the PDP function. That includes algorithms and behavioral state machineries based on a complete set of standardized data and information models 👑
    • Those 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 depending on the nature of the service being delivered 🎀
  • The need for abstraction layers, which are clear interfaces between business actors and between layers (let alone cross-layer considerations, etc.) 🧩 These layers get invoked in the context of service structuring and packaging, and they're meant to help the following emerge:
    • 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 together with network engineering objectives 💅
    • Dynamically adaptive decision-making processes, which can properly operate on a set of input data and metrics, such as current resource usage and demand, traffic forecasts and matrices, etc. All of this is for the sake of highly responsive dynamic resource allocation and policy enforcement schemes ⭐
  • Better accommodation of technologically heterogeneous networking environments through the following:
    • Vendor-independent configuration procedures based on enforcing 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 🥾

Okay, the network needs ways to dynamically discover the functional capabilities of the devices that a PDP intelligence will steer for automated network service delivery. Why? Because learning what the network is actually capable of helps structure the PDP intelligence, so policy provisioning information can be derived to match 🧠✨

A typical example would be documenting a traffic engineering policy based on dynamically discovering the various functions that network devices support. That policy depends on the services being delivered, and it can set up different routes toward the same destination depending on the nature of the traffic, where the functions it needs to forward through are located, etc. 🛣️💜

That dynamic discovery can rely on exchanging specific information over 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 to network devices, asking them to describe their functional capabilities in return, and then derive network and service topologies from those answers 📡

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 that kind of environment still assumes support for the following capabilities 🙈

  • 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;
  • Dynamically connect the PDP to the participating nodes and avoid any forwarding loops;
  • 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;
  • 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);
  • Dynamically assess the reachability scope as a function of the service to be delivered;
  • Dynamically detect and diagnose failures, and proceed with corrective actions accordingly 🚨

Likewise, the network needs ways to dynamically acquire the descriptive information (including the base configuration) of any network device that may take part in delivering a given service. That way the PDP can structure the services it can deliver based on the available resources, their location, etc. 🗺️

In IGP-/BGP-free networking environments, a specific bootstrap protocol may be needed to support the capabilities above, so that PDP- and SDN-capable devices can operate properly. There may also be a need for a specific additional network that provides discovery and connectivity features 🪄

Now, SDN design and operation in IGP-/BGP-free environments should deliver performance similar to legacy environments that run an IGP and BGP. For example, the underlying network should stay operational even if the connection with the PDP has been lost 🛡️ Operators should also weigh the cost of introducing a new, specific bootstrap protocol against the cost of folding those capabilities into existing IGP/BGP protocol machineries 💸

SDN-related features can be grafted onto an existing network infrastructure, so from a bootstrapping perspective they may not all be turned on at once. A gradual approach can be used instead 🌱

A typical deployment example would be to use an SDN decision-making process as an emulation platform. That helps service providers and operators make appropriate technical choices before actually deploying in the network 🧪

Finally, finishing the discovery procedure doesn't necessarily mean the network is now fully operational. Operationality usually assumes a robust design built on resilience and high availability features 💖

4.3. Operating an SDN ✨

Okay so, from an Operations and Management (OAM) standpoint [RFC6291], running an SDN-capable network brings up a bunch of big questions 🧐 Here are the ones that matter most:

  • How do SDN service and network management blocks talk to each other? 🤔 For example, how does the dynamic negotiation of service parameters with a customer (or a group of them) over a period of time affect the PDP decision-making process? Think resource allocation, path computation, and so on 💅
  • What are the right OAM tools for running an SDN network? For example, how do you check PDP or PEP reachability? 🔍
  • How can performance be optimized (say, in terms of service delivery time) when an external entity, typically a PDP, controls when software modules get activated? ⚡
  • How much does an SDN implementation actually make the network easier to manage, including diagnosing services and the network itself? 🩺
  • Should the "control and data plane separation" principle apply to the whole network, or just a portion of it? Maybe it depends on the kind of services being delivered, or on the technology already deployed 🤷‍♀️
  • What does this mean for the service provider's testing procedures and methodologies, the ones used during validation and pre-deployment? Specifically: (1) how test cases get defined and run once customized modules can be activated, (2) what the methodology is for assessing how SDN-controlled devices behave, (3) how test regression will happen, and (4) etc. 🧪
  • How do SDN techniques affect service fulfillment and assurance? 🎀 How should the behavior of SDN devices (like whether configuration tasks finish) be assessed against what was dynamically negotiated with a customer? How do you measure how efficient dynamically enforced policies are, relative to the service that was delivered? How do you measure whether what was delivered actually matches what was negotiated? And what's the impact of SDN techniques on troubleshooting practice? 🛠️
  • Is there any risk in running frozen architectures, because of possible interoperability issues between a controlled device and an SDN controller? 🥶
  • How does bringing in SDN techniques affect the lifetime of legacy systems? Is there a risk of (rapidly) making existing technologies obsolete because of their hardware or software limitations? 📉

The answers to all of these are very likely to be service provider specific, since they depend on each provider's technological and business environment. No one-size-fits-all here, bestie 🫶

4.4. The Intelligence Resides in the PDP 🧠

Okay, the proposed SDN definition in Section 2.3 assumes some intelligence that may live in the control plane, the management plane, 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.

So SDN networking relies on PDP functions that can process all sorts of input data 📥 Think traffic forecasts, outcomes of negotiations between customers and service providers, and resource status as shown in the appropriate information models instantiated in the PIB, and more. The PDP then uses all of that to make the right decisions 💜

Designing and operating this PDP-based intelligence in a scalable way is still one of the major areas that need investigating 🔬

To avoid centralized design schemes, inter-PDP communication is likely to be required, and the corresponding issues and solutions should be considered. This means several PDP instances may get activated in a given domain 🌸 Each of these instances may be responsible for enforcing a specific policy (for example, one PDP for QoS policy enforcement, another for security policy enforcement, and so on), so an inter-PDP communication scheme is required for global PDP coordination and correlation 🤝

Inter-domain PDP exchanges may also be needed for specific usages. Here are some examples: (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 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 a high level of automation, from service negotiation all the way through delivery and operation. Automation is the key to simplicity, but it must not be treated as a magic button that a network administrator hits whenever a customer request needs processing or extra resources need allocating 🙅‍♀️✨

Automation is not a magic button, bestie. Don't let anyone tell you otherwise 💀

The need for simplicity and adaptability, thanks to automated procedures, generally assumes some complexity lurking underneath the automation 🧩

4.6. Performance and Scalability 🚀

Combining flexibility with software inevitably raises performance and scalability issues, depending on how many services get delivered, what kind of services they are, and how dynamic they are 📈

For example, networks deployed in Data Centers (DCs) that rely on OpenFlow switches are unlikely to raise important FIB scalability issues 🙌 On the flip side, DC interconnect designs that aim to dynamically manage Virtual Machine (VM) mobility, possibly based on the dynamic enforcement of specific QoS policies, may raise scalability issues 😬

The claimed flexibility of SDN networking in that latter context will have to be carefully investigated by operators 🔎

4.7. Risk Assessment ⚠️

Okay, there are several risks to assess, such as:

  • Evaluating the risk of depending on a controller technology rather than a device technology 🎛️
  • Evaluating the risk of running frozen architectures because of possible interoperability issues between a controller and a controlled device 🧊
  • Assessing whether SDN-labeled solutions are likely to make existing technologies obsolete because of hardware limitations. From a technical standpoint, the ability to dynamically provision resources based on the services to be delivered may be incompatible with legacy routing systems because of their hardware limitations, for example. From an economic standpoint, using 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 determines how robust and reliable the interactions between the network and applications are 🛡️ It covers 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 ways to assess the behavior of software components under stress conditions, detect any exploitable vulnerability, reliably carry out software upgrades, and so on. These security guards should be activated during initial SDN node deployment and activation, but also during SDN operation that involves software upgrade procedures 🔒

Although these procedures may not be SDN-specific (operators are already familiar with firmware updates, with or without service disruption, for example), 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 that PDP; (2) a PEP is entitled to solicit a PDP for whatever reason (a request for additional configuration information, a notification about the results of a set of configuration tasks, and so on); (3) a PEP can accept decisions made by a PDP; and (4) communication between PDPs within a domain, or between domains, is properly secured (for example, make sure a pair of PDPs is entitled to communicate with each other, and make sure the confidentiality of the information exchanged between two PDPs can be preserved, and so on) 🫣

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 ✨

okay bestie, this is the reading list 📚🫶 these are the extra docs the spec leans on for background, and they're not required reading to implement it. quick heads up, a bunch are still "Work in Progress" drafts, so they're literally still cooking 🍳

  • [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. 🫶

Authors' Addresses 💖

Mohamed Boucadair, the first author, is at France Telecom in Rennes 35000, France. 🇫🇷 You can reach him at mohamed.boucadair@orange.com. 📬

Christian Jacquenet, the second author, is also at France Telecom in Rennes, France, and his address is christian.jacquenet@orange.com. 💌

periodt, that's the whole doc 🎀✨

📦 where this page comes from