Considerations for the use of SDN
in Semantic Routing Networks
Orange
Rennes
France
mohamed.boucadair@orange.com
Huawei
Munich
Germany
dirk.trossen@huawei.com
Old Dog Consulting
UK
adrian@olddog.co.uk
IRTF
IRTF
The forwarding of packets in today's networks has long evolved beyond
ensuring mere reachability of the receiving endpoint. Instead, other 'purposes'
of communication, e.g., ensuring quality of service of delivery, ensuring protection
against path failures through utilizing more than one, and others, are realized by
many extensions to the original reachability purpose of IP routing.
Semantic Routing defines an approach to realizing such extended purposes beyond
reachability by instead making routing and forwarding
decisions based, not only on the destination IP address, but on other
information carried in an IP packet. The intent is to facilitate
enhanced routing decisions based on this information in order to provide
differentiated forwarding paths for specific packet flows.
Software Defined Networking (SDN) places control of network elements
(including all or some of their forwarding decisions) within external
software components called controllers and orchestrators. This approach
differs from conventional approaches that solely rely upon distributed
routing protocols for the delivery of advanced connectivity services. By
doing so, SDN aims to enable network elements to be simplified while
still performing forwarding function.
This document examines the applicability of SDN techniques to
Semantic Routing and provides considerations for the development of
Semantic Routing solutions in the context of SDN.
Service differentiation in the network can be enforced by
manipulating a set of parameters that belong to distinct dimensions
(e.g., forwarding, routing, traffic classification, resource
partitioning). Through this, the resulting system may be able to
realize communication that goes beyond the mere reachability that original
IP routing (and forwarding) aimed at.
As pointed out in ,
this differentiation and its solutions have long found entry into many existing and
deployed Internet technologies.
Among the techniques to achieve such differentiation,
this document focuses on Semantic Routing, which refers to a process
that is meant to provide differentiated forwarding paths for specific
packet flows distinct from simple shortest path first routing and, thus,
satisfy specific service/application requirements.
More concretely, Semantic Routing is the process of making routing
and forwarding decisions based, not only on the destination IP address
of a packet, but also by taking into account other information that is
carried in the packet such as (but not limited to):
Other fields of the IP header, e.g., DSCP/Traffic Class.
The transport header, e.g., transport port numbers or subflows .
Specific transport encapsulation shims, e.g., .
Specific service headers, e.g., .
Metadata.
provides more details about Semantic
Routing.
Software Defined Networking (SDN) places (partial or full) control of
network elements and their forwarding decisions within dedicated
software components called controllers and orchestrators. This approach
differs from those that solely rely upon distributed routing protocols.
An ambition of SDN is to enable network elements to be simplified while
the network is optimized to deliver value-added connectivity services.
Refer to for an overview of SDN.
This document examines the applicability of SDN to Semantic Routing
though programbale forwarding (see and
provides considerations for the development of Semantic Routing solutions
in the context of SDN.
This document does not elaborate on specific SDN protocols: some SDN
protocol solutions may be more or less amenable to use for Semantic Routing,
but that discussion would need detailed analysis which is better suited
to a further and separate document.
SDN refers to an approach for network programmability: the
capacity to initialize, control, and manage network behavior dynamically
via open interfaces. Such programmability can facilitate the delivery
of services in a deterministic, dynamic, and scalable manner.
SDN emphasizes the role of software in operational networks by supporting
the separation between data and control planes. Even if such a
separation has been adopted by most routing processes for decades
(Section 2.1 of ), SDN focuses more on the
power of "central" controllers to optimize route computation within a
network before populating the Forwarding Information Base (FIB) of
the network elements.
The separation of the control and data planes allows faster
innovation in both planes, and it enables a dynamic and flexible approach
to implementing new network behaviors as well as to reacting to changes in network
state and traffic demands.
SDN has been discussed in many places during the last decade. For
example, within the IRTF, provides a
concise reference for the SDN research community to address the
questions of what SDN is, what the layer structure of an SDN
architecture is, and how layers interface with each other within that
architecture. (published in the IETF
stream) offers a service provider's perspective of the SDN landscape by
describing requirements, issues, and other considerations about SDN. In
particular, classifies SDN techniques
into the following functional domains:
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 capturing 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.
Techniques used by service-requirement-derived dynamic resource
allocation and policy enforcement schemes, so that networks can be
programmed accordingly.
Dynamic feedback mechanisms that are meant to assess how
efficiently a set of policies are enforced from a service
fulfillment and assurance perspective.
SDN can be deployed in a recursive model that involves
dedicated interfaces for both network and service optimization. Indeed,
differentiates the control functions
associated with transport (that is, the transfer capabilities offered by a
networking infrastructure) from those related to services in an approach
called Cooperating Layered Architecture for Software-Defined Networking
(CLAS).
To an SDN context, domain-specific controllers can be deployed with
specific interactions as discussed in Section 4 of .
As described in ,
Semantic Routing (or, more generally, Semantic Networking) is the process of
achieving enhanced routing and forwarding decisions based on semantics
added to IP packet headers to provide differentiated paths for different
packet flows distinct from simple shortest path first routing. The
additional information or "semantics" may be placed in existing header
fields (such as the IPv6 Traffic Class field or the destination address)
or may be carried by adding fields to the header. Further, the semantics
may be encoded in the payload or additional headers (such as in the port
number fields or in an IPv6 Extension Header).
The application of Semantic Routing allows packets from different
flows (even those between the same applications on the same devices) to be
marked for different treatment in the network. The packets may then be
routed onto different paths according to the capabilities and states of
the network links in order to meet the requirements of the flows. For
example, one flow may need low latency, while another may require ultra
low jitter, and a third may demand very high bandwidth.
Three elements are needed to achieve Semantic Routing:
The capabilities and state of the network must be discovered.
The packets must be marked (with semantic information) according
to their required delivery characteristics.
The routers must be programmed to forward the traffic according
to how the packets are marked.
All these elements can be matched to the SDN functional domains
listed in . From that standpoint, this
document provides more details on how SDN can be used to satisfy
specific Semantic Routing needs.
Programmable Forwarding is the term applied to the use of control
techniques to instruct network devices how to forward packets in a
programmatic way.
Modern networks are designed to carry traffic that belongs to a
variety of services/applications that have distinct traffic
performance requirements, reliability and robustness expectations, and
service-specific needs .
Such expectations, and other forwarding
requirements that can be captured in a Service Level Agreement (SLA)
, can be considered by providers when
designing their networks in order to be able to deliver differentiated
forwarding behaviors. However, conventional routing and forwarding
procedures do not always offer the required functionalities for such
differentiated service delivery. Thus, additional means have to be
enabled in these networks for the sake of innovative service delivery
while minimizing the induced complexity to operate such networks.
Also, these means should be tweaked to ensure consistent forwarding
behaviors network-wide.
The aforementioned means are not only extensions to routing
protocols, but include other mechanisms that affect the forwarding
behaviors within a network. A non-exhaustive list of sample
capabilities that can be offered by appropriate control of
forwarding elements is provided below:
A network may host dedicated
functions that implement resource pooling among many available
paths or that control which path is used to steer traffic as a
function of the observed round-trip time (RTT) (e.g., enable
Mutlipath TCP (MPTCP) converters in
specific network segments, including data centers as detailed
in Section 2.1 of ).
There is a need to interact with the underlying forwarding
elements to communicate a set forwarding policies that will
ensure that such service differentiation is provided to the
specific flows. These forwarding policies include, for example,
a set of rules that characterize the flows that are eligible to
the resource pooling service or the scheduling policies (maximize
link utilization, grab extra resources only when needed, etc.).
These polices are then enforced by programmable forwarders.
Some applications
may have strict traffic performance requirements (e.g., a low
one-way delay ), however, the
underlying network elements might not support a mechanism to
disseminate performance metrics associated with specific paths
and/or perform performance-based route selection (e.g., ).
As an alternative, an off-line Semantic Routing approach could
be used to collect measurement data to reach a given content
(e.g., one-way delay to reach specific data centers), perform
route selection based on this data, and then program the appropriate
forwarding elements accordingly.
An important effort was
made in the past to optimize the energy consumption of network
elements. However, such optimization is node-specific and no
standard means to optimize the energy consumption at the scale
of the network have been defined. For example, many nodes (also,
service cards) are deployed as backups.
A controller-based approach can be implemented so that the route
selection process optimizes the overall energy consumption of a
path. Such a process takes into account the current load, avoids
waking nodes/cards for handling "sparse" traffic (i.e., a minor
portion of the total traffic), considers node-specific data (e.g.,
), etc. This off-line Semantic Routing
approach will transition specific cards/nodes to "idle" and wake
them as appropriate, etc., without breaking service objectives.
Moreover, such an approach will have to maintain an up-to-date
topology even if a node is in an "idle" state (such nodes may be
removed from adjacency tables if they don't participate in
routing advertisements).
A network may need to
be partitioned in order to rationalize the delivery of
advanced connectivity services, and to address specific forwarding
requirements of groups of services/applications. Network slicing
can be
considered to deliver these services. However, an intelligence is
needed to decide the criteria to be used to partition the
available resources, filter them, decide whether network
extensions are needed, ensure whether/how resource preemption is
adequately implemented, etc.
These tasks are better achieved using a central intelligence that
has direct visibility into the intents of applications, underlying
network capabilities, local policies and guidelines, etc. As an
output of processing these various inputs, a set of node-specific
policies is generated, and then pushed using available SDN interface.
The programmability of SDN in the form
of forwarding actions defined on packet header fields allows for realizing
forwarding techniques beyond the typical longest-prefix match used for IP-based
reachability. Solutions, like those in ,
use a binary representation of links in a network to realize a path-based forwarding
action that acts purely on node-local state, independent of the nature of the path or the communications
traversing it. As discussed in , the limitation of
forwarding actions to apply only to defined (IP) packet header fields results
in issues that need special consideration when realizing such solutions in real-world
deployments.
The next subsection further details which elements are needed when
interacting with programmable forwarders in an SDN context.
SDN minimizes the required changes to legacy (interior) routing
protocols. More concretely, SDN can be used to provide the intended
Semantic Routing behavior, especially:
Identify the forwarding elements that can be safely involved in
providing the intended Semantic Routing features.
Maintain abstract topologies that involve these elements and
their capabilities.
Capture application-specific intents and derive the
corresponding forwarding requirements and, then, forwarding
policies.
Map these abstract topologies to (groups of) applications with
specific Semantic Routing needs.
Program a subset of nodes (called boundary nodes) with the
required classification and marking policies to bind flows to
their intended Semantic Routing behaviors.
In order to adequately process the application
flows that require specific differentiated forwarding, SDN
controllers maintain a table that allows to unambiguously identify
such flows. The content of that table is used to derive the
appropriate classification/match rules that are then communicated
by an SDN controller to a set of forwarding elements.
When volatile data (e.g., dynamic IP addresses)
are used to build such rules, it is the responsibility of the SDN
controllers to update the rules whenever a new identifier is used.
Failure to maintain "fresh" classification rules will lead to
service failure/degradation.
Supply intermediate nodes (that is, nodes that are not boundary
nodes) with the appropriate rules to locate and interpret the bits
within the packet to determine and execute forwarding actions as
established by Semantic Routing.
Automatically adjust, if possible, the network MTU to
accommodate any overhead that is introcuced by any extra bits used to
signal Semantic Routing behavior.
Instruct egress boundary nodes about the required actions such
as stripping or setting any Semantic Routing bits.
Interact with the underlying nodes to maintain, retrieve, and
disseminate the data that are used for assuring that Semantic Routing
policies are appropriately fulfilled.
Configure OAM policies to measure the network behavior and adjust the
forwarding processes.
Monitor the network and detect parts of the network where
policies are broken or suboptimal.
Automate the overall procedure .
At least three approaches can be considered by an SDN controller to
accomplish the above tasks:
Compute (centrally) the differentiated paths and install the
required forwarding rules in involved nodes. Strict or loose paths
may be installed. This approach has the merit of implementing new
path selection algorithms without requiring them to be supported
by every involved node.
Assign (centrally) differentiated link information and install the
required forwarding rules in the involved nodes. End-to-end paths are
constructed without involvement of the SDN controller, utilizing the
link information to establish path identifiers on which
installed forwarding rules can act upon without additional path-specific
knowledge being required. See for an example
of such an approach.
Rely upon a distributed routing protocol to customize the route
selection process (,
for example). In such cases, the SDN controller is responsible for
communicating the parameters to be used for the route selection
process, selecting the nodes that will participate in a given
topology, and configuring any tunnels to interconnect these
nodes.
A hierarchical SDN design can also be considered, where specific
controllers are enabled in each domain with dedicated interfaces to
share data (e.g., radio bottlenecks, expectations). These domains do
not need to support the same technological implementations. The
interaction between the SDN controllers eases the delivery of
consistent Semantic Routing behaviors without requiring common domain
configuration.
Policy is a term applied to the application of local or network-wide
operational choices made by the network manager. These may range from
decisions about what traffic to admit to the network, how network resources
should be used to support different traffic flows, how errors or security
violations are handled, and how packets are routed through the network.
Policies are usually made available to network operators as configuration
elements on network nodes. However, these configuration actions need to be
coordinated across the whole network if the policies are to be effective. Thus,
a mechanism is desired that allows an operator to set a network-wide policy in one
place and that results in that policy being pushed out to the network nodes that
need to act on the policy.
Semantic Routing is particularly amenable to a policy-based approach. That is,
an operator (or their software tools) can make decisions about how different traffic
flows should be handeled in the network. Those decisions can then be installed on
network nodes so that different traffic is handled differently and according to
the policies.
SDN is a powerly approach to implement a policy-based network management framework.
The operator need only select or configure the desired policies at the controller: the
controller will realize the policies and install the necessary instructions and
behaviors on the network nodes.
Critical to the correct functioning of any routing system is proper network-wide
coordination. In many cases, the coordination starts with the collection and dissemination
of network connectivity information (known as the network topology), the capabilities of
the network nodes and links, and the current state (up, down, degraded, busy, etc.) of those
nodes and links. But an even mode fundamental element of network-wide coordination is the
decision about which routing algorithms and procedures will be used because, if different
nodes or even different parts of the network) apply different routing approaches, it is
very possible that traffic will loop or be dropped. Thus, th first elements of coordination
are finding out what the network looks like and agreeing how to route traffic.
These essentials are no less relevant in Semantic Routing. All nodes that participate
in a Semantic Routing network need to have the same understanding of the additional
information carried in packets, and must make coordinated forwarding decisions based on
a coordinated routing algorithm.
A centralized approach, such as that achieved in an SDN system, is particularly useful
in this context because it allows the coordination to be applied through a central point
of control which may remove the complexity and "fragility" from the routing system. This
coordination may be considered in parallel with the aspects of policy-based routing
described in .
Given the focus of Semantic Routing is the use within IP networks, semantic information
that can be used in SDN-based Semantic Routing is limited to those fields specifically
defined for use with Semantic Routing (see for more information). This
document deliberately makes no comment on the specifications that may be produced to
define such fields, their meaning, and their encoding.
SDN aligns with the concept of Semantic Routing in that it allows the network
devices to be programmed for forwarding actions indicated by a wide range of
packet header fields beyond simply the IP destination addresses.
However, Semantic Routing solutions have also been proposed that "overwrite"
existing protocol fields in order for them to carry semantic information that
can be used to drive a forwarding action outside their original semantics.
and outline an example
of such approaches in which semantic information is used for a path-based
forwarding decision; while the absence of "path" information is foreseen as
an actionable packet header field in IPv6.
Here, the path is constructed by a Path Computation Element (PCE)
that matches a given service name against previously announced locations where
said service name is located. The path is represented as a concatenation of individual
link information, which in pushed by the SDN controller to the network nodes so that
they can perform local forwarding actions on packets that arrive. Given the binary
structure of the end-to-end path information, the forwarding operation can be implemented
in a standard-compliant manner with its realization described in
as an arbitrary wildcard matching operation.
However, the constraint of acting only on limited packet fields requires that the
path information be carried in one of those standard-defined packet header fields: thereby
overwriting (or overloading) any existing packet header field.
uses the IPv6 address fields for this purpose, representing the longest continuous binary
field in the IPv6 header (two addresses make up 256 bits in total) allows the support of
topologies with up to 256 links.
Given the approach chosen in , any IPv6 address information,
if needed, cannot be present in the packet header and so is provided in the encapsulated payload.
This leads to repeated encapsulation with the overhead of carrying two IP headers in a single
packet: one used for path-based forwarding and one for the operations in arriving endpoint.
Only newer SDN-based forwarding plane programming tools, such as P4, would allow for such overhead to
be removed by placing the path information into another packet header field (or even the
payload as an extended header of sort) to act upon.
The programmability of SDN provides a fertile ground for forwarding decision that go beyond the reachability information provided through
IPv4/v6 addresses, e.g., by using other packet header fields. This not only allows for extending the simple reachability-driven forwarding decision
with richer, e.g., policy-based, decisions (as discussed in ), it may also enable new forwarding paradigms per se, such as
those in , which in turn may realize forwarding behaviours like multicast at much lower cost points and higher efficiency
(see ).
However, SDN specifications have limited capabilities when it comes to the additional (i.e., new) packet header fields that may be used for forwarding actions.
As a consequence, "true" Semantic Routing on any semantic enhancement, which is included in the packet, is only possible in a manner limited to those
existing fields.
Solutions such as those in , using methods outlined in , attempt to break this limitation
albeit by overwriting standard-defined packet header fields, thereby changing the semantics of those fields within the scope (i.e., network domain)
where the "re-defined" semantics are known and understood.
This limits any solution to a limited domain . More importantly, the redefinition of packet fields poses
the danger of exposing this (non-standard compliant) semantic to elements outside the limited domain: semantic leakage may occur, or nodes outside
the domain may misinterpret overwritten fields, requiring methods, such as dedicated gateways, to preventi such leakage. This can be seen in
, where the boundaries to IP-compliant end devices and other domains alike are delimited by dedicated gateway elements.
Those gateways usually act at higher layers than the forwarding layer, thereby incurring complexity and often delay.
See also
for a discussion of issues and concerns that need to be examined when
applying a new routing or forwarding paradigm to a self-contained
network or Internet.
SDN-related considerations are discussed in Section 5 of .
This document makes no requests for IANA action.
Thanks to George Polyzos for helpful comments on this work.
This work is partially supported by the European Commission under Horizon 2020 grant agreement number 101015857
Secured autonomic traffic management for a Tera of SDN flows (Teraflow).
Stateless multicast switching in software defined networks
IP Over ICN: The Better IP?
Realizing IP-based Services over an Information-Centric Networking Transport Network