Networking devices have been successfully developed and deployed for

several decades. Repeaters and bridges, followed by routers and

switches, have been used in a plethora of environments, performing
their functions of filtering and forwarding packets throughout the
network toward their ultimate destinations. Despite the impressive
track record of these traditional technologies, the size and
complexity of many modern deployments leaves them lacking. The
reasons for this fact include the ever-increasing costs of owning and
operating networking equipment, the need to accelerate innovation in
networking, and, in particular, the increasing demands of the modern
data center. This chapter investigates these trends and describes how
they are nudging networking technology away from traditional methods
and protocols toward the more open and innovation-friendly paradigm
of SDN. 2.1 Evolution of Switches and Control Planes We begin with a
brief review of the evolution of switches and control planes that has
culminated in a fertile playing field for SDN. This complements the
material presented in Sections 1.4 and 1.5. The reader may find it
useful to employ Figure 2.1 as a visual guide through the following
sections; it provides a graphical summary of this evolution and
allows the reader to understand the approximate timeframes when
various switching components moved from software to hardware. 2.1.1
Simple Forwarding and Routing Using Software In Chapter 1 we
discussed the early days of computer networking, when almost
everything other than the physical layer (layer one) was implemented
in software. This was true for end-user systems as well as for
networking devices. Whether the devices were bridges, switches, or
routers, software was used extensively inside the devices in order to
perform even the simplest of tasks, such as MAC-level forwarding
decisions. This remained true even through the early days of the
commercialized Internet in the early 1990s. 2.1.2 Independence and
Autonomy in Early Devices Early network device developers and
standards creators wanted each device to perform in an autonomous and
independent manner to the greatest extent possible. This was because
networks were generally small and fixed, with large shared domains. A
goal also was to simplify rudimentary management tasks and make the
networks as plug and play as possible. Devices’ relatively static
configuration needs were performed manually. Developers went to great
lengths to implement this distributed environment with Software
Defined Networks. [Link]
4 © 2014 Elsevier Inc. All rights reserved. 21 22 CHAPTER 2 Why SDN?
Layer 2 Forwarding, Routing, QoS, ACLs, Control Physical Physical
Layer 2 Forwarding Routing, QoS, ACLs, Control Physical Layer 2
Forwarding Routing QoS, ACLs, Control Physical Layer 2 Forwarding
Routing Control QoS, ACLs Time Hardware Software ~1990 ~1995 ~2000
~2005 FIGURE 2.1 Networking functionality migrating to hardware.
intelligence resident in every device. Whenever coordination between
devices was required, collective decisions could be made through the
collaborative exchange of information between devices. Interestingly,
many of the goals of this distributed model, such as simplicity, ease
of use, and automatic recovery, are similar to the goals of SDN, but
as the scale and complexity of networks grew, the current distributed
model has become increasingly dysfunctional. Examples of this
distributed intelligence are the layer two (bridging) and layer three
(routing) protocols, which involved negotiation between the devices
in order to reach a consensus on the way forwarding and routing would
be performed. We introduced these protocols in Chapter 1 and provide
more SDN-specific details on them here. • Spanning Tree Protocol.
Basic layer two forwarding, also known as transparent bridging, can
be performed independently by each switch in the network. However,
certain topologies require an imposition of a hierarchy on the
network in order to prevent loops, which would cause broadcast
radiation. The Spanning Tree Protocol (STP) is an example of the
operation of autonomous devices participating in a distributed
decision-making process to create and enforce a hierarchy on the
network. The result is the correct operation of transparent bridging
throughout the domain at the expense of convergence latency and
possibly arbitrary configuration. This solution was a tradeoff
between cost and complexity. Multiple paths could have been supported
but at greater cost. STP was adequate when networks were of smaller
scale, but as networks grew the spanning tree solution became
problematic. These problems manifest themselves in a striking fashion
when networks reach the scale of the modern data center. For example,
IEEE 802.1D specifies the following default timers for STP: 15
seconds for listening, 15 seconds for learning, and 20 seconds for
max-age timeout. In older networks, convergence times of 30–50
seconds were common. Such delays are not acceptable in today’s data
centers. As the scale of the layer two network grows, the likelihood
of greater delays increases. The Rapid Spanning Tree 2.1 Evolution of
Switches and Control Planes 23 Protocol (RSTP) protocol, specified in
IEEE 802.1D-2004 [6], improves this latency significantly but
unfortunately is not deployed in many environments. • Shortest-Path
Bridging. STP allowed only one active path to a destination, suffered
from relatively slow convergence times and was restricted to small
network topologies. Although the newer implementations of STP have
improved the convergence times, the single active path shortcoming
has been addressed in a new layer two protocol, Shortest-Path
Bridging (SPB), introduced in Section 1.5.1. SPB is a mechanism for
allowing multiple concurrent paths through a layer two fabric via
collaborative and distributed calculation of shortest and most
efficient paths, then sharing that information among the
participating nodes in the meshed network. This characteristic is
called multipath. SPB accomplishes this goal by utilizing IS-IS to
construct a graph representing the layer two link-state topology.
Once this graph exists, shortest-path calculations are
straightforward, though more complex than with spanning tree. To
elaborate on what we mean by shortest-path calculations, in Figure
2.2 we depict a simple graph that can be used for calculating
shortest paths in a network with five switches. The costs assigned to
the various links may be assigned their values according to different
criteria. A simple criterion is to make the cost of a network link
inversely proportional to its bandwidth. Thus, the cost of transiting
a 10 Gbps link is one-tenth that of transiting a 1 Gbps link. When
the shortest-path calculation is complete, the node performing the
calculation knows the least-cost path to any of the other nodes in
the network. The least-cost path is considered the shortest path. For
the sake of clarity, we should point out that IS-IS is used in the
SPB context strictly for layer two path calculation. This differs
from its classical application in calculating layer three routes, as
described below. In the trivial Switch B Switch D Switch C Switch E
Switch A Switch F 1 Gbps link 10 Gbps link Cost:1 Cost:1 Cost:1
Cost:10 Cost:10 Cost:10 Cost:10 Cost:10 Cost:10 Cost:10 Shortest
Paths A-B:A,B (cost:10) A-C:A,C (cost:1) A-D:A,C, D (cost 11) A-
E:A,C,E (cost:2) A-F:A,C,E,F (cost 3) FIGURE 2.2 Example graph of a
network for shortest-path calculation. 24 CHAPTER 2 Why SDN? example
of Figure 2.2, there is a single shortest path from node A to every
other node. In reallife networks it is common for there to be more
than one least-cost path between two nodes. The multipath
characteristic of SPB would allow the traffic to be distributed
across those multiple paths. • RIP, BGP, OSPF, and IS-IS. Routing at
layer three requires cooperation between devices in order to know
which routers are attaching which subnets to the network. In Chapter
1 we provided background on four routing protocols: RIP, BGP, OSPF,
and IS-IS. These routing protocols involve the sharing of local
routing information by each device, either at the edge of the network
or as an intermediate node. Their collective sharing of information
allows the routing state to converge as devices share their
information with each other. Each router remains autonomous in terms
of its ability to make routing decisions as packets arrive. This
process is one of peers sharing and negotiating among themselves,
without a centralized entity aiding in the decision.