One document matched: draft-sin-sdnrg-sdn-approach-00.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-00"
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="20" month="March" year="2013" />
<workgroup>SDNRG Working Group</workgroup>
<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.</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></t>
<section title="Context">
<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., detection and processing of faults).</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,
based solely on often static service production procedures that are
more and more exposed to the risk of malformed 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.</t>
<t>In addition, various tools are used for different, sometimes
service-driven, 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>
</section>
<section title="Scope">
<t>This document is a contribution to clarify the SDN landscape:<list
style="symbols">
<t><xref target="inout"></xref> clarifies items which are
considered as viable goals and exclude others from the scope.</t>
<t><xref target="sdn"></xref> provides a tentative definition from
a service provider perspective.</t>
<t><xref target="sdn"></xref> discusses several issues and
identifies some requirements.</t>
</list></t>
</section>
</section>
<section anchor="inout" title="What is In and What is Out?">
<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 cannot be seen as a brand new solution but rather as
some 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.</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).</t>
</section>
<section title="Be Pragmatic">
<t>SDN approaches should be holistic. This means that it must be
global, network-wise. It is not a matter of configuring devices one by
one to enforce a specific forwarding policy. It is 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 to assurance and fulfillment.</t>
<t>Because the complexity of activating SDN capabilities is hidden (to
the user) and pushed to software, 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.</t>
<t>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 techniques remain limited to what is supported
by embedded software and hardware. One cannot expect SDN techniques to
support unlimited customizable features.</t>
<t>Policy-based management framework<xref target="RFC2753"> </xref>
was designed to orchestrate available resources, by means of a typical
Polociy 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>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="Measure Experience Against Expectations">
<t>Because several software modules may be controlled by external
entities, means to ensure the experienced outcome complies with the
expected outcome belong to the set of SDN techniques.</t>
<t>These techniques, as an instantiation of Policy-Based Management,
should interact with Service Structuring engines 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. This
requirement applies to several regions of a network: <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 unlikely.</t>
<t>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 only a
protocol that helps devices populate their forwarding tables according
to a set of instructions.</t>
<t>As such, OpenFlow is clearly not the “next big thing”:
there are many, many other protocols that have been standardized
(think Routing Policy Specification Language (RPSL, <xref
target="RFC2622"></xref>), for one) - or not - and which have been
massively deployed.</t>
<t>The forwarding of the configuration information can currently 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>,
etc.</t>
<t>There is 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 between the current networking
ecosystem and the proposed SDN paradigm. Operators do not have to
choose between the two as both models may be needed.</t>
<t>In particular, the following considerations can be seen as a
non-goal to justify the deployment of SDN techniques: <list
style="symbols">
<t>Fully flexible software implementations, whereas 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 raise some scalability
issues. Distributed protocols and their ability to react to some
events (e.g., link failure) in a timely manner remains a key to
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="sdn" title="A Definition of 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
years if not 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 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. Note:<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.</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 by essence software-driven, the above
definition does not emphasize the claimed "Softwire-Defined" property
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 dynamic negotiation of the set of corresponding 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,</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="issues" title="Disscussion">
<t></t>
<section title="Full Automation: a Viable Objective?">
<t>The path towards full automation is paved with numerous challenges
and requirements, including:<list style="symbols">
<t>Simplify and foster service delivery, assurance and
fulfillment, as well as network failure detection, diagnosis and
root cause analysis: <list style="symbols">
<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
as well as operational procedures,</t>
<t>The main intelligence resides in the PDP, which suggests
that an important part of the investigation effort should
focus on a detailed specification of the PDP function,
including algorithms and behavioral details, based upon a
complete set of standardized data and information models.</t>
</list></t>
<t>Need for abstraction layers: clear interfaces between business
actors, clear interaction between layers, cross-layer
considerations, etc.<list style="symbols">
<t>Ability to build and package differentiated (network)
services,</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 a solution to map IP connectivity service
requirements with network engineering objectives,</t>
<t>Need for dynamically-adaptive objectives based on current
resource usage and demand, 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 privileged direct interaction with
engines (e.g., routing, forwarding).</t>
</list></t>
</list></t>
</section>
<section 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 management planes
(or both). This intelligence is typically represented by a Policy
Decision Point, which is one of the key functional components of
Policy-Based Management architectures <xref
target="RFC2753"></xref>.</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 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 within SDN environments.</t>
</section>
<section title="Simplicity and Adaptability vs. Complexity">
<t>The above meta functional domains assume the introduction of a high
level of automation, from service negotiation to delivery and
operation.</t>
<t>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 & 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>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 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>
<section anchor="IANA" title="IANA Considerations">
<t>This document 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 achitecture.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBC.</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.RFC.3084'?>
<?rfc include='reference.RFC.5440'?>
<?rfc include='reference.RFC.4655'?>
<?rfc include='reference.RFC.2622'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:36 |