One document matched: draft-sin-sdnrg-sdn-approach-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info" docName="draft-sin-sdnrg-sdn-approach-03"
ipr="trust200902" updates="">
<front>
<title abbrev="On SDN">Software-Defined Networking: A Service Provider's
Perspective</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<phone></phone>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date day="10" month="June" year="2013" />
<abstract>
<t>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 at contributing to the clarification
of the SDN landscape by discussing a service provider's perspective on
requirements, issues and other considerations about SDN.</t>
<t>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 a 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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
capabilities (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 capabilities (e.g.,
traffic classification and marking, traffic conditioning and
scheduling), security capabilities (e.g., filters to protect customer
premises from network-originated attacks, to avoid malformed route
announcements, etc.) and management capabilities (e.g., fault detection
and processing).</t>
<t>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 Any Time Any-Where Any Device (ATAWAD)-driven convergence
trends that are meant to make sure 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 this end-user is in motion or not.</t>
<t>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.</t>
<t>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 the market coverage (fixed/mobile, residential/corporate).
This so-called network planning policy may very well affect the way
resources are allocated in a network, but 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
possible negotiation phase is completed) is even more critical for
corporate customers.</t>
<t>In addition, various tools are used for different, sometimes
service-centric, management purposes but their usage is not necessarily
coordinated for the sake of event aggregation, correlation and
processing. At the cost of extra complexity and possible customer's
Quality of Experience degradation.</t>
<t>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.</t>
<t>This document aims at clarifying the SDN landscape.</t>
</section>
<section anchor="sdn" title="Introducing Software-Defined Networking">
<t></t>
<section title="A Tautology?">
<t>The separation of the forwarding and control planes (beyond
implementation considerations) have almost become a gimmick to promote
flexibility as a key feature of the SDN approach. Technically, most of
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
hardware-encoded.</t>
<t>As such, the current state-of-the-art tends to confirm the said
separation, which rather falls under a tautology.</t>
<t>But a somewhat centralized, "controller-embedded", control plane
for the sake of optimized route computation before FIB population is
certainly another story.</t>
</section>
<section title="On Flexibility">
<t>This "flexibility argument" that has been put forward by SDN
promoters 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's requests for the sake
of 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.</t>
<t>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 that flexibility that
several mobile operators are currently investigating.</t>
<t>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 a 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 <xref target="I-D.ietf-idr-ls-distribution"></xref>,
for example.</t>
<t>Given the rather broad scope that the flexibility wording suggests:
<list style="symbols">
<t>The exact characterization of what flexibility actually means
is still required.</t>
<t>The exposure of programmable interfaces is not a goal per se,
rather a means to facilitate configuration procedures for the sake
of improved flexibility.</t>
</list></t>
</section>
<section anchor="def" title="A Tentative Definition">
<t>We define Software-Defined Networking as the set of techniques used
to facilitate the design, the delivery and the operation of network
services in a deterministic, dynamic, and scalable manner.</t>
<t>Such a definition assumes the introduction of a high level of
automation in the overall service delivery and operation
procedures.</t>
<t>Because networking is software-driven by nature, the above
definition does not emphasize the claimed "Software-Defined"
properties of SDN-labeled solutions.</t>
</section>
<section title="Functional Meta-Domains">
<t>SDN techniques can be classified into the following functional
meta-domains:</t>
<t><list style="symbols">
<t>Techniques for the dynamic discovery of network topology,
devices and capabilities, along with relevant information models
that are meant to precisely document such topology, devices and
capabilities.</t>
<t>Techniques for exposing network services (and their
characteristics; e.g., <xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>)
and for dynamically negotiating the set of service parameters that
will be used to measure the level of quality associated to the
delivery of a given service or a combination thereof.</t>
<t>Techniques used by service requirements-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
and the possible need to trigger additional resource provisioning
cycles according to a typical multi-year master plan, etc.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="Scope" title="A Few Considerations">
<t>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 against denial-of-service
attacks.</t>
<t>The introduction of new SDN-based networking features should
obviously take into account this context, especially from a cost impact
assessment perspective.</t>
<section title="Remember The Past">
<t>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. As a matter of fact, some
of the claimed "new" SDN features have been already implemented (e.g.,
NMS (Network Management System), PCE (Path Computation Element, <xref
target="RFC4655"></xref>)), and supported by vendors for quite some
time (references can be added if needed).</t>
<t>Some of these features have also been standardized (e.g., DNS-based
routing <xref target="RFC1383"></xref> that can be seen as an
illustration of separated control and forwarding planes or ForCES
(<xref target="RFC5810"></xref><xref target="RFC5812"></xref>)).</t>
<t>Also, the Policy-Based Management framework<xref
target="RFC2753"></xref> 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).</t>
<t>The Policy Decision Point (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.</t>
<t>The Policy Enforcement Point (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.</t>
<t>SDN techniques as a whole are an instantiation of the policy-based
network 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) and triggers (e.g., dynamic notification of a link failure),
etc.</t>
</section>
<section title="Be Pragmatic">
<t>SDN approaches should be holistic, i.e., global, network-wise. It
is not a matter of configuring devices one by one to enforce a
specific forwarding policy. SDN techniques are about configuring and
operating a whole range of devices at the scale of the network for the
sake of automated service delivery (<xref
target="I-D.boucadair-network-automation-requirements"></xref>), from
service negotiation and creation (e.g., <xref
target="I-D.ietf-idr-sla-exchange"></xref>) to assurance and
fulfillment.</t>
<t>Because the complexity of activating SDN capabilities is largely
hidden to the end-user and 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.</t>
<t>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).</t>
<t>SDN techniques are not necessary to develop new network services
per se. The basic service remains (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.</t>
<t>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.</t>
</section>
<section title="Measure Experience Against Expectations">
<t>Because several software modules may be controlled by external
entities, means to ensure that what has been delivered complies with
what has been negotiated belong to the set of SDN techniques.</t>
<t>These typical policy-based techniques should interact with both
Service Structuring engines (that are meant to expose the service
characteristics and to 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 which may have been dynamically negotiated
with the customer (e.g., as captured in a CPP <xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>,
<xref
target="I-D.boucadair-connectivity-provisioning-protocol"></xref>).
This requirement applies to several regions of a network, including:
<list style="numbers">
<t>At the interface between two adjacent IP network providers.</t>
<t>At the access interface between a service provider and an IP
network provider.</t>
<t>At the interface between a customer and the IP network
provider.</t>
</list></t>
<t>Ideally, a fully automated service delivery procedure from
negotiation and ordering, through order processing, to delivery,
assurance and fulfillment, should be supported. This approach assumes
widely adopted standard data and information models, let alone
interfaces.</t>
</section>
<section title="Design Carefully">
<t>Exposing open and programmable interfaces has a cost, from both a
scalability and performance standpoints.</t>
<t>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, forwarding) without requiring any
in-between adaptation layer (generic objects to vendor-specific CLI
commands for instance).</t>
<t>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.</t>
<t>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.</t>
<t>One single SDN, network-wise deployment is therefore very unlikely.
Instead, multiple instantiations of SDN techniques will be
progressively deployed and adapted to various network and service
segments.</t>
</section>
<section title="There Is Life Beyond OpenFlow">
<t>Empowering networking with in-band controllable modules does not
necessarily mean the use of the OpenFlow protocol, which is just
another protocol that helps devices populate their forwarding tables
according to a set of instructions.</t>
<t>OpenFlow is clearly not the "next big thing": there are many, many
other candidate protocols that can be used for the same or even
broader purposes (e.g., resource reservation purposes). The forwarding
of the configuration information can indeed rely upon a variety of
protocols that include (but is not necessarily limited to) PCEP <xref
target="RFC5440"></xref>, NETCONF <xref target="RFC6241"></xref>,
COPS-PR <xref target="RFC3084"></xref>, Routing Policy Specification
Language (RPSL, <xref target="RFC2622"></xref>), etc.</t>
<t>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.</t>
</section>
<section title="Non Goals">
<t>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.</t>
<t>In particular, the following considerations cannot justify the
deployment of SDN techniques: <list style="symbols">
<t>Fully flexible software implementations, because the claimed
flexibility will be limited by respective software and hardware
limitations, anyway.</t>
<t>Fully modular implementations are difficult to achieve (because
of the implicit complexity) and may introduce extra effort for
testing, validation and troubleshooting.</t>
<t>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).</t>
</list></t>
</section>
</section>
<section anchor="issues" title="Discussion">
<t></t>
<section title="Implications Of Full Automation">
<t>The path towards full automation is paved with numerous challenges
and requirements, including:<list style="symbols">
<t>Make sure automation is well implemented so as to facilitate
testing (including validation checks) and troubleshooting. <list
style="symbols">
<t>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, so as to avoid a
typical "mad robot" syndrome whose consequences can be
serious, from a control and QoS standpoints among others.</t>
<t>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, input) to complete.</t>
</list></t>
<t>Simplify and foster service delivery, assurance and
fulfillment, as well as network failure detection, diagnosis and
root cause analysis, for the sake of cost optimization: <list
style="symbols">
<t>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.</t>
<t>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 as well as operational procedures.</t>
<t>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, based
upon a complete set of standardized data and information
models.</t>
<t>These information models and data need to be carefully
structured for the sakes of efficiency and flexibility. This
probably suggests a set of simplified pseudoblocks that can be
assembled as per the nature of the service to be
delivered.</t>
</list></t>
<t>Need for abstraction layers: clear interfaces between business
actors, between layers, let alone cross-layer considerations,
etc.<list style="symbols">
<t>For the sake of various service structuring and
packaging.</t>
<t>Need for IP connectivity service exposure to customers,
peers, applications, content/service providers, etc. (e.g.,
<xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>).</t>
<t>Need for solutions that accommodate IP connectivity service
requirements with network engineering objectives.</t>
<t>Need for 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.</t>
</list></t>
<t>Better accommodate technologically heterogeneous networking
environments: <list style="symbols">
<t>Need for vendor-independent configuration procedures, based
upon the enforcement of vendor-agnostic generic policies
instead of vendor-specific languages.</t>
<t>Need for tools to aid manageability and orchestrate
resources.</t>
<t>Avoid proxies and privilege direct interaction with engines
(e.g., routing, forwarding).</t>
</list></t>
</list></t>
</section>
<section anchor="pdp" title="The Intelligence Resides In The PDP">
<t>The proposed SDN definition in <xref target="def"></xref> 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), which is one of the key functional
components of the Policy-Based Management framework <xref
target="RFC2753"></xref>.</t>
<t>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.</t>
<t>The design and the operation of such PDP-based intelligence in a
scalable manner remains of the major areas that needs to be
investigated.</t>
<t>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 the sake of global PDP coordination and
correlation.</t>
<t>Inter-domain PDP exchanges may also be needed for specific usages.
Examples of such exchanges are: (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. (2) Various PDPs can collaborate together in
order to compute inter-domain paths which satisfy a set of traffic
performance guarantees.</t>
</section>
<section title="Simplicity And Adaptability Vs. Complexity">
<t>The meta functional domains 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
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.</t>
<t>The need for simplicity and adaptability thanks to automated
procedures generally assumes some complexity that lies beneath
automation.</t>
</section>
<section title="Performance And Scalability">
<t>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.</t>
<t>For example: while the deployment of a network solely composed of
OpenFlow switches within a data center environment is unlikely to
raise FIB scalability issues given the current state-of-the-art, data
center networking that relies upon complex, possibly IP-based,
QoS-inferred, interconnect design schemes meant to dynamically manage
the mobility of Virtual Machines between sites is certainly of another
scale.</t>
<t>The claimed flexibility of SDN networking in the latter context
will have to be carefully investigated by operators.</t>
</section>
<section title="Risk Assessement">
<t>Various risks are to be assessed such as:<list style="symbols">
<t>Evaluating the risk of depending on a controller technology
rather than a device technology.</t>
<t>Evaluating the risk of operating frozen architectures because
of potential interoperability issues between a controller and a
controlled device.</t>
<t>Assessing whether SDN-labeled solutions are likely to obsolete
existing technologies because of hardware limitations.</t>
<t>Etc.</t>
</list></t>
</section>
<section title="On Security">
<t>Security has to be a first-class part of any SDN design, thus
giving both network and applications people the control to ensure that
the other has access to the info and controls that they need (but no
more), and to ensure that they are properly safeguarded against taking
actions that will adversely affect the network or application as a
whole <xref target="I-D.hartman-sdnsec-requirements"></xref>.</t>
<t>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.),
and (3) 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.).</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not define any protocol nor architecture.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to W. George, J. Halpern, D. King, J. H. Salim, and T.
Tsou for their comments. </t>
<t>Special thanks to P. Georgatos for the interesting discussion;
particularly the discussion on SDNi (SDN Interconnection).</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.1383'?>
<?rfc include='reference.RFC.2753'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-profile'?>
<?rfc include='reference.I-D.boucadair-network-automation-requirements'?>
<?rfc include='reference.I-D.ietf-idr-ls-distribution'?>
<?rfc include='reference.I-D.ietf-idr-sla-exchange'?>
<?rfc include='reference.RFC.3084'?>
<?rfc include='reference.RFC.5440'?>
<?rfc include='reference.RFC.4655'?>
<?rfc include='reference.RFC.2622'?>
<?rfc include='reference.RFC.5810'?>
<?rfc include='reference.RFC.5812'?>
<?rfc include='reference.I-D.hartman-sdnsec-requirements'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:05 |