1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx

1. Software-Defined Networks (SDN) is a new paradigm in
network management that adds another layer (i.e., Network
Operating System) to the architecture. Answer the following
questions in the context of SDN with your reasoning.
(a) Is it scalable? Why?
(b) Is it less responsive? Why?
(c) Does it create a single point of failure? Why?
(d) Is it inherently less secure? Why?
(e) Is it incrementally deployable? Why?
2.RED randomly drops packets when it experience congestion.
The probability of drop increases as the average queue size
increases.
(a) Does it do a better job for uniform or bursty traffic? and
why?
(b) Does it drop packets from the head of the queue or from the
tail of the queue? and why?
(c) Does it make any difference; head/tail drop? and why?
3. Carefully read the short article OpenFlow: A Radical New
Idea in Networking
(http://queue.acm.org/detail.cfm?id=2305856), and answer the
following questions.
The author argues that the deployment of SDN in general and
OpenFlow in specific towards network democratization is a
crazy idea. Do you agree? If yes, how come SDN has been
supported and being deployed by many networking vendors. If
not, give one scenario that SDN could cause disruptions.
NET WORKS
1

OpenFlow:
A Radical New Idea in Networking
An open standard that enables software-defined networking
Thomas A. Limoncelli
Computer networks have historically evolved box by box, with
individual network elements
occupying specific ecological niches as routers, switches, load
balancers, NATs (network address
translations), or firewalls. Software-defined networking
proposes to overturn that ecology, turning
the network as a whole into a platform and the individual
network elements into programmable
entities. The apps running on the network platform can optimize
traffic flows to take the shortest
path, just as the current distributed protocols do, but they can
also optimize the network to
maximize link utilization, create different reachability domains
for different users, or make device
mobility seamless.
OpenFlow, an open standard that enables software-defined
networking in IP networks, is a new
network technology that will enable many new applications and
new ways of managing networks.
Here are three real, though somewhat fictionalized,
applications:
EXAMPLE 1: BANDWIDTH MANAGEMENT. A typical wide
area network has 30 percent utilization;
it must “reserve” bandwidth for “burst” times. Using OpenFlow,
however, a system was developed
in which internal application systems (consumers) that need

bulk data transfer could use the
spare bandwidth. Typical uses include daily replication of
datasets, database backups, and the
bulk transmission of logs. Consumers register the source,
destination, and quantity of data to
be transferred with a central service. The service does various
calculations and sends the results
to the routers so they know how to forward this bulk data when
links are otherwise unused.
Communication between the applications and the central service
is bidirectional: applications
inform the service of their needs, the service replies when the
bandwidth is available, and the
application informs the service when it is done. Meanwhile, the
routers feed realtime usage
information to the central service.
As a result, the network has 90-95 percent utilization. This is
unheard of in the industry. The CIO
is excited, but the CFO is the one who is really impressed. The
competition is paying three times
as much CAPEX (capital expenditure) and OPEX (operational
expenditure) for the same network
capacity.
This example is based on what Google is doing today, as
described by Urs Hoelzle, a Google
Fellow and senior vice president of technical infrastructure, in
his keynote address at the 2012 Open
Networking Summit.1
EXAMPLE 2: TENANTIZED NETWORKING. A large virtual-
machine hosting company has a
network management problem. Its service is “tenantized,”
meaning that each customer is isolated
from the others like tenants in a building. As a virtual machine

migrates from one physical host to
another, the VLAN (virtual LAN) segments must be
reconfigured. Inside the physical machine is a
software-emulated network that connects the virtual machines.
There must be careful coordination
between the physical VLANs and the software-emulated world.
The problem is that connections can
NET WORKS
2
be misconfigured by human error, and the boundaries between
tenants are... tenuous.
OpenFlow allows new features to be added to the VM
management system so that it
communicates with the network infrastructure as virtual and
physical machines are added and
changed. This application ensures that each tenant is isolated
from the others no matter how the
VMs migrate or where the physical machines are located. This
separation is programmed end-to-end
and verifiable.
This example is based on presentations such as the one
delivered at the 2012 Open Networking
Summit by Geng Lin, CTO, Networking Business, Dell Inc.3
EXAMPLE 3: GAME SERVER. Some graduate students set up a
Quake server running on a spare
laptop as part of a closed competition. Latency to this server is
important not only to gameplay,
but also to fairness. Because these are poor students, the server

runs on a spare laptop. During the
competition someone picks up the laptop and unplugs it from
the wired Ethernet. It joins the Wi-Fi
as expected. The person then walks with the laptop all the way
to the cafeteria and returns an hour
later. During this path the laptop changes IP address four times,
and bandwidth varies from 100
Mbps on wired Ethernet, to 11 Mbps on an 802.11b connection
in the computer science building, to
54 Mbps on the 802.11g connection in the cafeteria.
Nevertheless, the game competition continues
without interruption.
Using OpenFlow, the graduate students wrote an application so
that no matter what subnetwork
the laptop is moved to, its IP address will not change. Also, in
the event of network congestion,
traffic to and from the game server will receive higher priority:
the routers will try to drop other
traffic before the game-related traffic, thus ensuring smooth
gameplay for everyone. The software on
the laptop is unmodified; all the “smarts” are in the network.
The competition is a big success.
This example is loosely based on the recipients of the Best
Demo award at SIGCOMM (Special
Interest Group on Data Communications) 2008.4 More-serious
examples of wireless uses of
OpenFlow were detailed by Sachin Katti, assistant professor of
electrical engineering and computer
science at Stanford University, in a presentation at the 2012
Open Networking Summit.2
A NET WORK ROUTING SYSTEM THAT LETS YOU WRITE
APPS
OpenFlow is either the most innovative new idea in networking,

or it is a radical step backward—a
devolution. It is a new idea because it changes the fundamental
way we think about network-routing
architecture and paves the way for new opportunities and
applications. It is a devolution because it is
a radical simplification—the kind that results in previously
unheard of new possibilities.
To understand this paradox, some history is needed. Before the
iPhone, there was no app store
where nearly anyone could publish an app. If you had a phone
that could run applications at all,
each app was individually negotiated with each carrier. Vetting
was intense. What if an app were
to send the wrong bit out the antenna and take down the entire
phone system? (Why do we have
a phone system that one wrong bit could take down?) The
process was expensive, slow, and highly
political.
Some fictional (but not that fictional) examples:
• “We’re sorry but your tic-tac-toe game doesn’t fit the ‘c’est
la mode’ that we feel our company
represents.”
• “Yes, we would love to have your calorie tracker on our
phone, but we require a few critical
changes. Most importantly the colors must match our corporate
logo.”
NET WORKS
3

• “We regret to inform you that we are not interested in having
your game run on our smartphone.
First, we can’t imagine why people would want to play a game
on their phones. Our phones are
for serious people. Second, it would drain the battery if people
used their phones for anything
other than phone calls. Third, we find the idea of tossing birds
at pigs to be rather distasteful. Our
customers would never be interested.”
No apps exist for networks today. A niche idea is a distraction
from the vendor’s roadmap. It could
ruin the product’s ‘c’est la mode’. Routers are too critical.
Router protocols are difficult to design,
implementing them requires highly specialized programming
skills, and verification is expensive.
BUT WHAT IF IT BECAME EASY?
To understand why writing routing protocols is so difficult
requires knowledge of how routing works
in today’s networks. Networks are made of endpoints (your PC
and the server it is talking to) and the
intermediate devices that connect them. Between your PC and
www.google.com there may be 20 to
100 routers (technically, routers and switches, but for the sake
of simplicity all packet-passing devices
are called routers in this article). Each router has many
network-interface jacks, or ports. A packet
arrives at one port, the router examines it to determine where it
is trying to go, and sends it out the
port that will bring it one hop closer to its destination.
When your PC sends a packet, it does not know how to get to
the destination. It simply marks
the packet with the desired destination, gives it to the next hop,

and trusts that this router, and all
the following routers, will eventually get the packet to the
destination. The fact that this happens
trillions of times a second around the world and nearly every
packet reaches its destination is awe-
inspiring.
No “Internet map” exists for planning the route a packet must
take to reach its destination. Your
PC does not know ahead of time the entire path to the
destination. Neither does the first router, nor
the next. Every hop trusts that the next hop will be one step
closer and eventually the packet will
reach the destination.
How does each router know what the next hop should be? Every
router works independently
to figure it out for itself. The routers cooperate in an algorithm
that works like this: each one
periodically tells its neighbors which networks it connects to,
and each neighbor accumulates this
information and uses it to deduce the design of the entire
network. If a router could think out loud,
this is what you might hear: “My neighbor on port 37 told me
she is 10 hops away from network
172.11.11.0, but the neighbor on port 20 told me he is four hops
away. Aha! I’ll make a note that if I
receive a packet for network 172.11.11.0, I should send it out
port 20. Four hops is better than 10!”
Although they share topological information, routers do the
route calculations independently.
Even if the network topology means two nearby routers will
calculate similar results, they do not
share the results of the overlapping calculations. Since every
CPU cycle uses a certain amount of

power, this duplication of effort is not energy efficient.
Fortunately, routers need to be concerned with only their
particular organization’s network,
not the entire Internet. Generally, a router stores the complete
route table only for its part of the
Internet—the company, university, or ISP it is part of (its
autonomous domain). Packets destined
for outside that domain are sent to gateway routers, which
interconnect with other organizations.
Another algorithm determines how the first set of routers knows
where the gateway routers are. The
combination of these two algorithms requires less RAM and
CPU horsepower than if every router
NET WORKS
4
had to know the entire Internet. If not for this optimization,
every router would need enough RAM
and CPU horsepower to store an inventory of the entire Internet.
The cost would be staggering.
The routing algorithms are complicated by the fact that routers
are given clues and must infer
what they need to know. For example, the conclusion that “port
20 is the best place to send packets
destined for 172.11.11.0” is inferred from clues given by other
routers. A router has no way of sending
a question to another router. Imagine if automobiles had no
windows but you could talk to any
driver within 25 feet. Rather than knowing what is ahead, you
would have to infer a worldview

based on what everyone else was saying. If everyone were using
the same vocabulary and the same
system of cooperative logical reasoning, then every car could
get to where it was going without a
collision. That’s the Internet: no maps; close your eyes and
drive.
Every router is trying to infer an entire worldview based on
what it hears. Driving these
complicated algorithms requires a lot of CPU horsepower. Each
router is an expensive device doing
the same calculation as everyone else just to get the slightly
different result it needs. Larger networks
require more computation. As an enterprise’s network grows,
every router needs to be upgraded to
handle the additional computation. The number and types of
ports on the router haven’t changed,
but the engine no longer has enough capacity to run its
algorithms. Sometimes this means adding
RAM, but often it means swapping in a new and more expensive
CPU. It’s a good business model for
network vendors: as you buy more routers, you need to buy
upgrades for the routers you’ve already
purchased. These aren’t standard PCs that benefit from the
constant Dell-vs.-HP-vs.-everyone-else
price war; these are specialized, expensive CPUs that customers
can’t get anywhere else.
THE RADICAL SIMPLIFICATION OF OPENFLOW
The basic idea of OpenFlow is that things would be better if
routers were dumb and downloaded
their routing information from a big “route compiler in the sky,”
or RCITS. The CPU horsepower
needed by a router would be a function of the speed and
quantity of its ports. As the network grew,
the RCITS would need more horsepower, but the routers would

not. The RCITS would not have to
be vendor specific, and vendors would compete to make the best
RCITS software. You could change
software vendors if a better one came along. The computer
running the RCITS software could be
off-the-shelf commodity hardware that takes advantage of
Moore’s law, price wars, and all that good
stuff.
Obviously, it isn’t that simple. You have to consider other
issues such as redundancy, which
requires multiple RCITS and a failover mechanism. An
individual router needs to be smart enough
to know how to route data between it and the RCITS, which
may be several hops away. Also, the
communications channel between entities needs to be secure.
Lastly, we need a much better name
than RCITS.
The OpenFlow standard addresses these issues. It uses the term
controller or controller platform
(yawn) rather than RCITS. The controller takes in
configuration, network, and other information and
outputs a different blob of data for each router, which interprets
the blob as a decision table: packets
are selected by port, MAC address, IP address, and other means.
Once the packets are selected,
the table indicates what to do with them: drop, forward, or
mutate then forward. (This is a gross
oversimplification; the full details are in the specification,
technical white papers, and presentations
at http://www.OpenFlow.org/wp/learnmore.)
Traditional networks can choose a route based on something
other than the shortest path—

http://www.OpenFlow.org/wp/learnmore
NET WORKS
5
perhaps because it’s cheaper, has better latency, or has spare
capacity. Even with systems designed
for such traffic engineering, such as MPLS TE (Multiprotocol
Label Switching Traffic Engineering),
it’s difficult to manage effectively with any real granularity.
OpenFlow, in contrast, enables you to
program the network for fundamentally different optimizations
on a per-flow basis. That means
latency-sensitive traffic can take the fastest path, while bulk
flows can take the cheapest. Rather than
being based on particular endpoints, OpenFlow is granular down
to the type of traffic coming from
each endpoint.
OpenFlow doesn’t stop at traffic engineering, however, because
it is capable of doing more than
populating a forwarding table. Because an OpenFlow-capable
device can also rewrite the packets,
it can act as a NAT or AFTR (address family transition router);
and because it can drop packets, it
can act as a firewall. It can also implement ECMP (equal-cost
multi-path) or other load-balancing
algorithms. Routers don’t have to have the same role for every
flow going through them; they
can load-balance some, firewall others, and rewrite a few.
Individual network elements are thus
significantly more flexible in an OpenFlow environment, even
as they shed some responsibilities to
the centralized controller.

OpenFlow is designed to be used entirely within a single
organization. All the routers in an
OpenFlow domain act as one entity. The controller has godlike
power over all the routers it controls.
You wouldn’t let someone outside your sphere of trust have
such access. An ISP may use OpenFlow
to control its routers, but it would not extend that control to the
networks of customers. An
enterprise might use OpenFlow to manage the network inside a
large data center and have a different
OpenFlow domain to manage its WAN. ISPs may use OpenFlow
to run their patch of the Internet,
but it is not intended to take over the Internet. It is not a
replacement for inter-ISP systems such as
BGP (Border Gateway Protocol).
The switch to OpenFlow is not expected to happen suddenly
and, as with all new technologies,
may not happen at all.
Centralizing route planning has many benefits:
• TAKES ADVANTAGE OF MOORE’S LAW. Not only are
general-purpose computers cheaper and faster,
but there is more variety. In the Google presentation at the 2012
Open Networking Summit, Urs
Höelzle said that Google does its route computations using the
Google compute infrastructure.
• OFFERS DEEPER INTEGRATION. End-to-end
communication can occur directly from the
applications all the way to the router. Imagine if every Web-
based service in your enterprise could
forward bandwidth requirements to the controller, which could
then respond with whether

or not the request could be satisfied. This would be a radical
change over the “send and pray”
architectures in use today.
• TURNS NETWORK HARDWARE INTO A COMMODITY.
The CPU and RAM horsepower required
by the device is a function of the speeds and number of ports on
the device as shipped. Therefore,
it can be calculated during design, eliminating the need to factor
in slack. Also, designing and
manufacturing a device with a fixed configuration (not
upgradable) is less expensive.
• MAKES ALGORITHMS SIMPLER. Rather than making
decisions based on inference and relying on
cooperating algorithms, more-direct algorithms can be used. A
dictatorship is the most efficient
form of government. Suppose the VoIP phones of the campus
EMS team should always get the
bandwidth they need. It is easier to direct each router on
campus to give EMS phones priority than
it is to develop an algorithm whereby each router infers which
devices are EMS, verifies a trust
NET WORKS
6
model, confirms that trust, and allocates the bandwidth—and
hopes that the other routers are
doing the same thing.
• ENABLES APPS. The controller can have APIs that can be
used by applications. This democratizes

router features. Anyone (with proper authorization and access)
can create network features. No
open source ecosystem exists for applications that run within
the Cisco IOS operating system.
Creating one will be much easier in the OpenFlow world. Apps
will not control individual routers
(this is already possible) but the entire network as a single
entity.
• ALLOWS GLOBAL OPTIMIZATION AND PLANNING.
Current routing protocols require each router
to optimize independently, often resulting in a routing plan that
is optimal locally but not globally.
The OpenFlow controller can plan based on a global, mostly
omniscient, understanding of the
network.
• PROVIDES CENTRALIZED CONTROL. Not that today’s
routers don’t have any APIs, but the
applications would need to communicate with the API of every
router to get anything done, and
I don’t know any network engineer who is open to that. With
OpenFlow, apps can talk to the
controller where authentication, authorization, and vetting can
happen in one place rather than
on every router.
CONCLUSION
In the past, smartphone vendors carefully controlled which
applications ran on their phones and
had perfectly valid reasons for doing so: quality of apps,
preventing instability in the phone network,
and protection of their revenue streams. We can all see now that
the paradigm shift of permitting
the mass creation of apps did not result in a “wild west” of
chaos and lost revenue. Instead, it

inspired entirely new categories of applications and new
revenue streams that exceed the value of the
ones they replaced. Who would have imagined Angry Birds or
apps that monitor our sleep patterns
to calculate the optimal time to wake us up? Apps are crazy,
weird, and disruptive—and I can’t
imagine a world without them.
OpenFlow has the potential to be similarly disruptive. The
democratization of network-based apps
is a crazy idea and will result in weird applications, but
someday we will talk about the old days and
it will be difficult to imagine what it was once like.
REFERENCES
1. Hoelzle, U. 2012. Keynote speech at the Open Networking
Summit; http://www.youtube.com/
watch?v=VLHJUfgxEO4.
2. Katti, S. 2012. OpenRadio: virtualizing cellular wireless
infrastructure. Presented at the Open
Networking Summit;
http://opennetsummit.org/talks/ONS2012/katti-wed-
openradio.pdf.
3. Lin, G. 2012. Industry perspectives of SDN: technical
challenges and business use cases.
Presentation at the Open Networking Summit;
http://opennetsummit.org/talks/ONS2012/lin-tue-
usecases.pdf (slides 6-7).
4. SIGCOMM Demo. 2008;
http://www.openflow.org/wp/2008/10/video-of-sigcomm-demo/.
LOVE IT, HATE IT? LET US KNOW

[email protected]
http://www.youtube.com/watch?v=VLHJUfgxEO4
http://www.youtube.com/watch?v=VLHJUfgxEO4
http://opennetsummit.org/talks/ONS2012/katti-wed-
openradio.pdf
http://opennetsummit.org/talks/ONS2012/lin-tue-usecases.pdf
http://opennetsummit.org/talks/ONS2012/lin-tue-usecases.pdf
http://www.openflow.org/wp/2008/10/video-of-sigcomm-demo/
mailto:[email protected]
NET WORKS
7
THOMAS A. LIMONCELLI is an internationally recognized
author, speaker, and system administrator.
His best-known books include Time Management for System
Administrators (O’Reilly, 2005) and The Practice
of System and Network Administration, 2nd edition (Addison-
Wesley, 2007). In 2005 he received the SAGE
Outstanding Achievement Award. See his blog at
http://EverythingSysadmin.com.
© 2012 ACM 1542-7730/12/0600 $10.00
http://EverythingSysadmin.com
Software Defined
Networks
Acronyms
Introduction

Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualizing OpenFlow
References
5.1
Lecture 5
Software Defined Networks
(ST: Advances in Networks)
CS 6/75995
Summer 2014
H. Peyravi
Department of Computer Science
Kent State University
(CS 6/75995: ST: Advances in Networks) Software Defined
Networks Summer 2014 1 / 52

http://www.cs.kent.edu/~peyravi
http://www.cs.kent.edu
http://www.kent.edu
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.2
§5.0.0 Contents
Acronyms

1 Introduction
2 Today’s Networks
Today’s Networks
Limitations of Current Networks
Drawbacks of Existing Networks
3 Idea: An OS for Networks
Idea: An OS for Networks
4 SDN History
SDN History
5 SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
6 The Road to SDN
The Road to SDN
Some Basic Questions
7 OpenFlow
OpenFlow
Centralized vs. Distributed Control
OPenFlow Protocol Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Instructions and Action Set
Actions
Flow Table Entry
Flow Switching/Routing

Load Balancing
Dynamic Flow Modification
Flow Routing vs. Aggregation
Reactive vs. Proactive Entries
8 Virtualization
Virtualization
Server Virtualization
Network Virtualization
Models for Network Virtualization
Network Slice Model
9 Virtualizing OpenFlow
Trend
10 References
The contents of this lecture have been composed from various
resources including those listed at the reference section.
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks

SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.3
§5.0.0 Glossaries
API Application Programming Interface 18, 23, 26
BGP Boarder Gateway Protocol 6
DiffServ Differentiated Services 6
IETF Internet Engineering Task Force 21
MPLS Multiprotocol Label Switching 6, 46
NAT Network Address Translation 6
NIC Network Interface Controller 22
ONF Open Networking Foundation 21
OSPF Open Shortest Path First 6
SDK Software Development Kit 22
SDN Software Defined Networking 14, 18, 19, 22, 24
VLAN Virtual Local Area Network 46

VM Virtual Machine 8
VPN Virtual Private Network 46
VRF Virtual Routing and Forwarding 46
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References

5.4
Introduction Software Defined Networks
§5.1.1 Software Defined Networks
å Reading list: [3, 4, 5]
Control Control
Plane Plane
Open Interface
Plane
Control
Open Interface
Merchant Switching Chips
Specialized
Current
Single Vendor Ecosystem
Future
Open Network Ecosystem
Vertically integrated
Closed interfaces
Proprietary

Slow innovation
Rapid innovation
Open interfaces
Horizontal
Apps
Specialized
Hardware
PlaneControl
Specialized
Features
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Today’s Networks
Limitations of Current
Networks
Drawbacks of Existing
Networks

Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.5
Today’s Networks Today’s Networks
§5.2.1 Today’s Networks I
Today’s networks are statically provisioned
[1]
Software Defined
Networks

Acronyms
Introduction
Today’s Networks
Today’s Networks
Networks
Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.6
§5.2.1 Today’s Networks II

[1]
Many complex functions are baked into infrastructure
I Open Shortest Path First (OSPF), Boarder Gateway Protocol
(BGP),
Differentiated Services (DiffServ), Network Address
Translation (NAT),
firewalls, Multiprotocol Label Switching (MPLS) etc.
How to efficiently and effectively manage such a comples
system?
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Today’s Networks
Networks
Networks
Idea: An OS for
Networks

SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.7
§5.2.1 Today’s Networks III
A Box
. . .Features FeaturesFeatures
Operating System
Specialized Packet
Forwarding Hardware
Million lines of source code
5400 RFCs
Barrier to entry

Billions of gates
Bloated
Power hungry
Routing, management, access control etc.
Devices are managed at a box level
I Applications
I Operating systems
I Hardware
Kind of mainframe mentality
The box becomes a barrier to entry
Resources are often under-utilized
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Today’s Networks
Networks

Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.8
Today’s Networks Limitations of Current Networks
§5.2.2 Limitations of Current Networks I
1 Enterprise networks are difficult to manage
I We Cannot dynamically make changes according to network
conditions
2 No control plane abstraction for the whole network
I Like old days of computers when there were no operating
systems
3 New control requirements are needed for
I Greater scalability
I Migration of Virtual Machines (VMs)

• Migrating operating system instances across distinct physical
hosts in
K Clusters
K Data centers
• It allows a clean separation between hardware and software to
K facilitate fault management
K load balancing
4 No mix and match between various devices and interfaces
5 Lack of competition at each layer
6 Configuring such huge networks is very difficult if not
impossible
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Today’s Networks
Networks
Networks

Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.9
Today’s Networks Drawbacks of Existing Networks
§5.2.3 Drawbacks of Existing Networks
It is difficult to perform real world experiments on large scale
networks
I Research stagnation
• Costly equipment needed to be setup to conduct research
We have a closed system
I We are stuck with interfaces
I Vendors have proprietary software/hardware
Network equipment have been hardware centric Why?
I To increase network capacity
I Faster packet switching
The impact has been
I Slower innovation
I Reducing flexibility once chips are fabricated

• Firmware provides some programmability
Vendor specific software
I Custom built
K Better efficiency
K Increasing competitive edge
I Impact
K Closed software
K Non-standard interfaces
Proprietary networking devices with proprietary software and
hardware resulted
I Limiting innovation to vendor/ vendor partners
I Major barriers for new ideas in networking
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History

SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.10
Idea: An OS for Networks Idea: An OS for Networks
§5.3.1 Idea: An OS for Networks I
Closed Boxes
Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System

Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks

SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.11
§5.3.1 Idea: An OS for Networks II
Adding Network OS + Control Program
Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App

Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App
Operating System
Specialized Packet
Forwarding Hardware
App App App
Control Program
Network Operating System
Software Defined
Networks
Acronyms

Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.12
§5.3.1 Idea: An OS for Networks III
Separation of Control Panel from Data Panel: SDN [7]
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet

Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Open API
Control Program
Open Interface
to Hardware
(OpenFlow)
Routing Traffic Security AppApp. . .Engineering
Data Plane
Control Plane
It decouples topology, traffic and inter-layer dependencies
It offers dynamic multi-layer networking
Software Defined
Networks

Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.13
§5.3.1 Idea: An OS for Networks IV
NOX: Towards an Operating System for Networks [6]
Global Network View

Control Program
Protocols
Control via
forwarding interface
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization

References
5.14
SDN History SDN History
§5.4.1 SDN History I
Software Defined Networking (SDN) is part of a long history of
efforts
to make computer networks more programmable
Traditional node entity
Ethernet
Switch
Control Path (Software)
Data Path (Hardware)
SDN separated control panel from data panel
Software Defined
Networks
Acronyms
Introduction

Today’s Networks
Idea: An OS for
Networks
SDN History
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.15
§5.4.1 SDN History II
SDN Elements
Ethernet
Switch
App1 App2 App3
SDN Client
Data Path (Hardware)
SDN Controller (Server)Controller (Server)

SDN Protocol − Open Flow
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
References
5.16

§5.4.1 SDN History III
Networks have various kinds of equipment
I Hardware: Routers, switches, etc.
I Middleware: firewalls, network address translators, load
balancers,
intrusion detection systems
I Software: application protocols
Switches and routers run distributed control software that is
typically closed and proprietary
The software implements network protocols
I Tested for interoperability and standardization
Network administrators configure network devices using
configuration interfaces
I Vary across networks
I Vary across protocols
Software Defined
Networks
Acronyms
Introduction
Today’s Networks

Idea: An OS for
Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization
References
5.17
SDN Architecture SDN Architecture
§5.5.1 SDN Architecture I
SDN Applications
(e.g., OpenFlow)
Control & DataPlane Programmable Interface

SDN Controller
Programmable Open APIs
Business Applications
Cloud Orchestration
(e.g., OpenStack, CloudStack)L
a
y
e
r
L
a
y
e
r
L
a
y
e
r
In
fr
a
s
tr

u
c
tu
re
C
o
n
tr
o
l
A
p
p
li
c
a
ti
o
n
Network Device Network Device Network Device

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization
References
5.18

§5.5.1 SDN Architecture II
SDN has gained significant traction recently
I Many commercial switches support the OpenFlow Application
Programming Interface (API)
SDN enables innovation in how we design and manage networks
I Computer networks are complex and difficult to manage
SDN has changed network management in different ways
1 SDN separates the control plane from from the data plane
I Control plane ⇒ decides how to handle the traffic
I Data plane ⇒ forwards traffic according to the control plane’s
rules
2 SDN consolidates the control plane to control multiple data
plane
elements
I Controls routers, switches, and other middle boxes
I Using a well-defined API
K Brings network to applications
K OpenFlow [7] is an example of API developed at Stanford
Û An OpenFlow switch has one or more tables of packet-
handling rule
Û Each rule matches a subset of traffic and performs certain
actions on
the traffic
– e.g., Dropping, forwarding
Û An OpenFlow switch can behave like a router, switch,
firewall,

network address translator, etc.
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization

References
5.19
§5.5.1 SDN Architecture III
Many different controller platforms have emerged
These controlling platforms have been used to create many
applications
I Dynamic access control
I Server load balancing
I Network virtualization
I Energy-efficient networking
I Seamless virtual-machine migration and user mobility
Major companies (Google, HP, NEC, etc.) have joined SDN
industry
consortium
I Open Networking Foundation
I Open Daylight
SDN idea has its root in early telephone systems
I Separation of control and data planes to
• Simplify network management
• Deployment of new services
SDN also resembles past research on active networking
I Programmable networks

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization
References
5.20

SDN Architecture SDN Benefits
§5.5.2 SDN Benefits
1 It facilitates Innovations in Networks
2 It is a layered architecture with standard open interfaces
I Independent innovation can be developed at each layer
3 Experiment and research can be conducted without using
bulky,
expensive equipment
4 Offers more accessibility since software can be easily
developed by
more vendors
5 Speed-to-market
I There is no hardware fabrication cycles
6 Offers more flexibility with programmability
7 Ease of customization and integration with other software
applications
8 Fast upgrades
9 Programming a network vs configure a network
Software Defined
Networks

Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization
References
5.21
SDN Architecture SDN Standard Bodies
§5.5.3 SDN Standard Bodies

1 Open Networking Foundation (ONF)
I https://www.opennetworking.org/
2 OpenFlow Organization
I http://www.openflow.org/
3 Clean State at Stanford
I http://cleanslate.stanford.edu
4 Internet Engineering Task Force (IETF)
I http://tools.ietf.org/html/draft-nadeau-sdn-problem-statement-
00
I http://tools.ietf.org/html/draft-nadeau-sdn-framework-01
https://www.opennetworking.org/
http://www.openflow.org/
http://cleanslate.stanford.edu
http://tools.ietf.org/html/draft-nadeau-sdn-problem-statement-
00
http://tools.ietf.org/html/draft-nadeau-sdn-framework-01
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for

Networks
SDN History
SDN Architecture
SDN Architecture
SDN Benefits
SDN Standard Bodies
SDN Paradigm
The Road to SDN
OpenFlow
Virtualization
References
5.22
SDN Architecture SDN Paradigm
§5.5.4 SDN Paradigm
Software-Centric-Network
I Network devices provide Software Development Kits (SDKs)
I SDN facilitates third-party application development and
integration
I SDN allows software vendors to develop network applications
I SDN helps evolving standards for network applications

SDN Entities
1 A general purpose commodity-off-the-shelf hardware
2 A real time optimized operating system ⇒ mostly Linux based
3 Some high end power and multi-port Network Interface
Controller
(NIC) cards
4 Integration with other new trends in servers
I Virtualization
I Parallelization
I Modularity
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture

The Road to SDN
The Road to SDN
OpenFlow
Virtualization
References
5.23
The Road to SDN The Road to SDN
§5.6.1 The Road to SDN I
Making networks programmable enables
I Innovation in network management
I Lowers the barrier to deploying new services
Historically, we have 3 stages of evolutionary activities in
programmable networks
I Active networks (mid-1990s to the early 2000s)
• Introduced programmable functions in the network to enable
innovations
I Control and data plane separation (2001 to 2007)
• Developed open interfaces between the control and data planes
I OpenFlow API and network operating systems (2007 to 2010)
• Represented widespread adoption of an open interface
• Making control-data plane separation scalable and practical

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
The Road to SDN
OpenFlow
Virtualization
References
5.24

The Road to SDN The Road to SDN
§5.6.1 The Road to SDN II
Network virtualization played an important role through the
evolution
of SDN
I We will discuss network virtualization and its relationship to
SDN
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
The Road to SDN

OpenFlow
Virtualization
References
5.25
The Road to SDN Some Basic Questions
§5.6.2 Some Basic Questions
1 How to obtain global information?
2 What are the configurations?
3 How to implement?
4 How is the scalability?
5 How does it really work?
Software Defined
Networks
Acronyms
Introduction

Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Centralized vs. Distributed
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing

Flow Routing vs.
Aggregation
Reactive vs. Proactive
Entries
Virtualization
References
5.26
OpenFlow OpenFlow
§5.7.1 OpenFlow I
OpenFlow is an open API that provides a standard interface for
programming the data plane switches
I An standard way to control flow-tables in commercial
switches and routers
I Like an x86 instruction set for the network
It provides an open interface to a L2/L3 node (switches, routers)
and
make them visible to the network
(SW)Secure Channel
(HW)Flow Table
SSL
OpenFlow Protocol

Controller
How does it separate the control plane from the data plane?
I The data path consists of a Flow Table
• An action associated with each flow entry
I The control path consists of a controller
• It programs the flow entry in the flow table
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow

Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.27

OpenFlow OpenFlow
§5.7.1 OpenFlow II
OpenFlow is based on an Ethernet switch with
I an internal flow-table
I a standardized interface to add/remove flows
OpenFlow was intended to enable innovation in campus
networks
I Like hardware drivers
• Interface between switches and network
It has been deployed at Stanford ⇒ http://cleanslate.stanford.edu
Some Applications
Mobility management
Network-wide energy management
New naming/addressing schemes
Network access control
http://cleanslate.stanford.edu
Software Defined
Networks

Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry

Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.28
OpenFlow Centralized vs. Distributed Control
§5.7.2 Centralized vs. Distributed Control
Centralized
(SW)Secure Channel
(HW)Flow Table
(SW)Secure Channel
(HW)Flow Table
(SW)Secure Channel
(HW)Flow Table

Controller
Distributed
(SW)Secure Channel
(HW)Flow Table
(SW)Secure Channel
(HW)Flow Table
(SW)Secure Channel
(HW)Flow Table
Controller
Controller
Controller
One OpenFlow switch cannot be controlled by two controllers
with
out additional abstractions
Software Defined
Networks
Acronyms

Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry

Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.29
OpenFlow OPenFlow Protocol Messages
§5.7.3 OPenFlow Protocol Messages
Controller-to-Switch messages
I Initiated by the controller
I Used to directly manage or inspect the state of the switch
• Features, Config, Modify State, Read-State, Packet-Out,
Barrier
Asynchronous
I Asynchronous messages are sent without the controller
soliciting them
from a switch
• Packet-in, Flow Removed / Expiration, Port-status, Error,
Barrier

Symmetric
I Symmetric messages are sent without solicitation, in either
direction
• Hello, Echo, Experimenter / Vendor
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control

OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.30
OpenFlow Secure Channel (SC)

§5.7.4 Secure Channel (SC)
Secure Channel is the Interface that connects each OpenFlow
switch
to controller
A controller configures and manages the switch, receives events
from the switch, and send packets out the switch via this
interface
Secure Channel establishes and terminates the connection
between
OpenFlow Switch and the controller
I Using Connection Setup and Connection Interruption
procedures
The Secure Channel connection is a TLS connection
I Switch and controller mutually authenticate by exchanging
certificates
signed by a site-specific private key
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks

SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation

Entries
Virtualization
References
5.31
OpenFlow Packet Matching
§5.7.5 Packet Matching
Packet Arrival
fields
Extract headerPacket
arrives
Match in
any tables ?
Apply actions
Updata statistics
Encapsulate and
forward to controller
Yes

No
Table Match
Table n
Match in
Start at Flow Table n=0
Packet in
o Send the packet to controller
o Drop the packet
o Continue to the next table
o Update action set
Execute Instruction Set
Update Counters and
o Update packet/match set fields
o Update metadata
Execute Action Set
Table n++
Go to
Based on table configuration,
do one of the following

Yes
Yes
NoNo
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control

OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.32
OpenFlow Pipeline Processing

§5.7.6 Pipeline Processing
Steps at each stage
1 Find highest priority matching flow entry
2 Apply instructions
a Modify packet and update match fields
• Apply actions instruction
b Update action set
• Clear actions and/or write actions instruction
c Update metadata
3 Send match data and actions set to next table
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture

The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries

Virtualization
References
5.33
OpenFlow Instructions and Action Set
§5.7.7 Instructions and Action Set I
Each flow entry contains a set of instructions
I They are executed when a packet matches the entry
Instructions contain
I A set of actions to add to the action set
• A list of actions to apply immediately to the packet
I A set of actions to modify pipeline processing
An Action set is associated with each packet
I It is empty by default
Action set is carried between flow tables
A flow entry modifies action set using Write-Action or Clear-
Action
instruction
Processing stops when:
I The instruction does not contain Goto-Table
I The actions in the set are executed
Software Defined
Networks

Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.34
OpenFlow Instructions and Action Set
§5.7.7 Instructions and Action Set II
List of Instructions to modify action set
Apply Actions
I Apply the specified actions immediately
Clear Actions
I Clear all the actions in the set immediately
Write Actions
I Merge the specified actions to the current set
Write Metadata

I Write the meta data field with the specified value
Goto-Table
I Indicated the next table in the processing pipeline
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages

Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.35
OpenFlow Actions
§5.7.8 Actions

Required Actions
I Output ⇒ Forward a packet to the specified port
I Drop
I Group
Optional Actions
I Set-Queue
I Push/Pop Tag
I Set-Field
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow

Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.36

OpenFlow Flow Table Entry
§5.7.9 Flow Table Entry I
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages

Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.37
OpenFlow Flow Table Entry
§5.7.9 Flow Table Entry II
[2]

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching

Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.38
OpenFlow Flow Switching/Routing
§5.7.10 Flow Switching/Routing I

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing

Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.39
OpenFlow Flow Switching/Routing
§5.7.10 Flow Switching/Routing II
Software Defined
Networks
Acronyms

Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.40
OpenFlow Load Balancing
§5.7.11 Load Balancing
Current methods use uniform distribution of traffic
It is not based on network congestion and server load
More adaptive algorithms can be implemented by using
OpenFlow
I Monitoring the network traffic
I Program flows based on demand and server capacity
Dynamic load balancing using OpenFlow
Data Forwarding
OpenFlow Switch

Data Forwarding
OpenFlow Switch
Data Forwarding
OpenFlow Switch
Program Flow Entries Collect Statistics
Observed
Load patterns
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture

The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization

References
5.41
OpenFlow Dynamic Flow Modification
§5.7.12 Dynamic Flow Modification
A microflow rule matches on all fields
A wildcard rule can have ”dont care” bits in some fields
Rules can be installed with a timeout
I Delete the rule after a fixed time interval (a hard timeout)
I Specified period of inactivity (a soft timeout)
I The switch counts the number of bytes and packets matching
each rule,
and the controller can poll these counter values
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port Src Dst Type ID Src Dst Port S-port D-port
IPSrc: 192.168.*/24
IPDst: 200.12.*/24
IPDst: 300.12.*/24
Incoming Request
Server 2
Server 1

Balancing Switch
R1
R2
R1
R2
200.12.*/24
300.12.*/24
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN

OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing
Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization

References
5.42
OpenFlow Flow Routing vs. Aggregation
§5.7.13 Flow Routing vs. Aggregation
Both models are possible with OpenFlow
Flow-Based
Every flow is individually set up
by a controller
Exact match for flow entries
Flow table contains one entry
per flow
Good for fine grain control, e.g.
campus networks
Aggregation-Based
One flow entry covers large
groups of flows
Wildcard match for flow entries
Flow table contains one entry
per category of flows
Good for large number of flows,
e.g. backbone

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
OpenFlow
Control
OPenFlow Protocol
Messages
Secure Channel (SC)
Packet Matching
Pipeline Processing

Actions
Flow Table Entry
Load Balancing
Flow Routing vs.
Aggregation
Entries
Virtualization
References
5.43
OpenFlow Reactive vs. Proactive Entries
§5.7.14 Reactive vs. Proactive Entries
Both models are possible with OpenFlow
Reactive
First packet of flow triggers
controller to insert flow entries

Efficient use of flow table
Every flow incurs small
additional flow setup time
If control connection lost, switch
has limited utility
Proactive
Controller pre-populates flow
table in switch
Zero additional flow setup time
Loss of control connection does
not disrupt traffic
Essentially requires aggregated
(wildcard) rules
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks

SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization
Models for Network
Virtualization
Network Slice Model
References
5.44
Virtualization Virtualization
§5.8.1 Virtualization
Abstraction between the physical resources and their logical
representation
Virtualization can be implemented in various layers of a
computer
system or network

1 Storage Virtualization ⇒ OS virtual memory
2 Server Virtualization
3 Network Virtualization
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization

Models for Network
Virtualization
Network Slice Model
References
5.45
Virtualization Server Virtualization
§5.8.2 Server Virtualization
Server virtualization refers to the partitioning of the resources
of a
single physical machine into multiple execution environments
I Each of which can host a different server
Server virtualization methods
1 Partitioning
• Each virtual machine is a subset of the physical resources
Application
Guest OS
Virtual Hardware
Application
Guest OS
Virtual Hardware
Application

Guest OS
Virtual Hardware
Hypervisor or VMM
Virtual Machines (CPU, Memory, NIC, Disk)
2 Aggregation
• Concatenation of physical resources
Virtual Machine
Hypervisor or VMM Hypervisor or VMM Hypervisor or VMM
Hypervisor or VMM
OS
Application
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for

Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization
Models for Network
Virtualization
Network Slice Model
References
5.46
Virtualization Network Virtualization
§5.8.3 Network Virtualization I
Network virtualization allows heterogeneous virtual networks
that are
isolated, independently managed to coexist over a shared
physical

network infrastructure
Network virtualization is not a new concept
I It is available in parts
• MPLS L2/L3 Virtual Private Network (VPN), Virtual Local
Area Network (VLAN),
Virtual Routing and Forwarding (VRF), etc.
Network virtualization can slice particular hardware resources
and
logically isolate them
I MPLS can virtualize forwarding tables
I VLANs slice the link layer
Currently there is no single technology (or clear abstraction)
that will
virtualize the network as a whole
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History

SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization
Models for Network
Virtualization
Network Slice Model
References
5.47
Virtualization Network Virtualization
§5.8.3 Network Virtualization II
Switch Based Virtualization

Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization
Models for Network
Virtualization
Network Slice Model
References

5.48
Virtualization Models for Network Virtualization
§5.8.4 Models for Network Virtualization I
1 Network Slicing Model
I Logically isolated network partitions are created over a shared
physical
network infrastructure
2 HyperVisor Model
I The model combines logical computer network resources into
a single
platform appearing as a single network
• HyperVisor, Vswitch
3 Hybrid Model
I Combination of the above two models
Software Defined
Networks
Acronyms
Introduction
Today’s Networks

Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Virtualization
Models for Network
Virtualization
Network Slice Model
References
5.49
Virtualization Network Slice Model
§5.8.5 Network Slice Model
Virtual Network 1
Physical Network

Virtual Network2
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Trend
References
5.50

Virtualizing OpenFlow Trend
§5.9.1 Trend I
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN
OpenFlow
Virtualization
Trend
References

5.51
Virtualizing OpenFlow Trend
§5.9.1 Trend II
App App App App
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
App App App App
Network
Operating
System 1
Operating
Network
System 2
Network
Operating
System 3
Network
Operating
System 4
Open Interface to Hardware

Open Interface to Hardware
Virtualization or Slicing Layer
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Software Defined
Networks
Acronyms
Introduction
Today’s Networks
Idea: An OS for
Networks
SDN History
SDN Architecture
The Road to SDN

OpenFlow
Virtualization
References
5.52
References
§5.10.0 References
[1] http://www.excitingip.com/743/network-convergence/.
[2] http://www.ipinfusion.com/.
[3] Astuto A. Bruno, Marc Mendonca Nunes, Xuan-Nam
Nguyen, Katia Obraczka, and Thierry Turletti.
A survey of software-defined networking: Past, present, and
future of programmable networks.
IEEE Communications Surveys and Tutorials, 14:1–17, 2012.
[PDF].
[4] Nick Feamster, Jennifer Rexford, and Ellen Zegura.
The road to SDN.
ACM Queue: Tomorrow’s Computing Today, 11(12):??–??,
December 2013.
[PDF].
[5] Nick Feamster, Jennifer Rexford, and Ellen Zegura.
The road to sdn: An intellectual history of programmable
networks.
SIGCOMM Comput. Commun. Rev., 44(2):87–98, April 2014.
[PDF].

[6] Natasha Gude, Teemu Koponen, Justin Pettit, Ben Pfaff,
Martı́n Casado, Nick McKeown, and Scott
Shenker.
Nox: Towards an operating system for networks.
SIGCOMM Comput. Commun. Rev., 38(3):105–110, July 2008.
[7] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru
Parulkar, Larry Peterson, Jennifer Rexford,
Scott Shenker, and Jonathan Turner.
Openflow: Enabling innovation in campus networks.
SIGCOMM Comput. Commun. Rev., 38(2):69–74, March 2008.
http://www.excitingip.com/743/network-convergence/
http://www.ipinfusion.com/IntroductionSoftware Defined
NetworksToday's NetworksToday's NetworksLimitations of
Current NetworksDrawbacks of Existing NetworksIdea: An OS
for NetworksIdea: An OS for NetworksSDN HistorySDN
HistorySDN ArchitectureSDN ArchitectureSDN BenefitsSDN
Standard BodiesSDN ParadigmThe Road to SDNThe Road to
SDNSome Basic QuestionsOpenFlowOpenFlowCentralized vs.
Distributed ControlOPenFlow Protocol MessagesSecure
Channel (SC)Packet MatchingPipeline ProcessingInstructions
and Action SetActionsFlow Table EntryFlow
Switching/RoutingLoad BalancingDynamic Flow
ModificationFlow Routing vs. AggregationReactive vs.
Proactive EntriesVirtualizationVirtualizationServer
VirtualizationNetwork VirtualizationModels for Network
VirtualizationNetwork Slice ModelVirtualizing
OpenFlowTrendReferences

Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.1
Lecture 6
Active Queue Management
(ST: Advances in Networks)
CS 6/75995
Summer 2014
H. Peyravi

Department of Computer Science
Kent State University
(CS 6/75995: ST: Advances in Networks) Active Queue
Management Summer 2014 1 / 39
http://www.cs.kent.edu/~peyravi
http://www.cs.kent.edu
http://www.kent.edu
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm

References
6.2
§6.0.0 Contents
Acronyms
1 Introduction
Introduction
The Role of AQM
2 Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
Implicit vs. Explicit feedback
TCP Congestion Control
3 AQM
AQM
AQM Goals
Random Early Detection (RED)
How about non-responsive sources?
4 AQM Classifications
Classification Based on Congestion Control
Classification By Mechanisms
5 Bufferbloat in the Internet
Bufferbloat in the Internet
6 Understanding Queues
Understanding Queues
7 Controlled Delay Management
Controlled Delay Management

8 CoDel Algorithm
CoDel Algorithm
9 References
The contents of this lecture have been composed from various
resources including those listed at the reference section.
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management

CoDel Algorithm
References
6.3
§6.0.0 Glossaries
ABR Available Bir Rate 10
AQM Active Queue Management 4–6, 15, 20, 29, 31, 35
ATM Asynchronous Transfer Mode 10
BDP Bandwidth × delay 30
CC Congestion Control 5, 6
CSFQ Core Stateless Fair Queuing 21
DiffServ Differentiated Services 4, 6
E2E End-to-End 16
ECN Explicit Congestion Notification 10
EWMA Exponentially Eeighted Moving Average 16, 18
FQ Fair Queuing 21
FRED Fair Random Early Detection 21
FWQ Weighted Fair Queuing 21
IETF Internet Engineering Task Force 29
IntServ Integrated Services 4
IP Internet Protocol 5, 6
MPLS Multiprotocol Label Switching 9
QoS Quality of Service 4, 6
RED Random Early Detection 5, 20, 21, 29, 35
SFQ Stochastic Fair Queuing 21
SLA Service Level Agreement 6
TCP Transport Control Protocol 5, 14

TD Tail-Drope 15
UDP User Data Protocol 21
Active Queue
Management
Acronyms
Introduction
Introduction
The Role of AQM
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References

6.4
Introduction Introduction
§6.1.1 Introduction
å Reading list: [1], [3]
Since 1993, there has been a steady stream of research in Active
Queue Management (AQM) 1
Issues
I What are the major attributes of AQM schemes?
I What are the design approaches taken by AQM schemes?
• Heuristic techniques
• Control-theoretic techniques
• Deterministic optimization
I What is the role of AQM w.r.t. Quality of Service (QoS)
provisioning in
• Differentiated Services (DiffServ)?
• Integrated Services (IntServ)?
• Wireless domain?
•
.
.
.
1
We used the words ”buffer” and ”queue” interchangeably

Active Queue
Management
Acronyms
Introduction
Introduction
The Role of AQM
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.5
Introduction The Role of AQM
§6.1.2 The Role of AQM I

The Role of AQM in Internet Protocol (IP) is to complement the
work
of end-system protocols such as the Transport Control Protocol
(TCP) in Congestion Control (CC) so as to increase:
I Network utilization
I Limit packet loss
I Limit delay
The first proposal for AQM was Random Early Detection (RED)
[2] in
1993.
I Followed by a number of new/augmented/improved proposals
• Some with rigorous analysis
K Some highlighted RED’s drawbacks
The design of RED and many of its variants were heuristic
I As a result, parameter-tuning has been the main limitations
Some researchers have used control theory techniques to
overcome
these limitations
I Classical control
I Modern control
I Optimal control
I Nonlinear control
Others use optimization techniques in the context of Congestion
Control (CC)
Active Queue
Management

Acronyms
Introduction
Introduction
The Role of AQM
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.6
Introduction The Role of AQM
§6.1.2 The Role of AQM II
The focus has been shifted from CC to QoS provisioning Why?
I Rapid deployment of data, voice, video and mobility
• Supported by common IP, and

• Growing heterogeneous set of communication technologies
I Diverse requirements of the different types of traffic flows
The role of AQM has become a mechanism to support DiffServ
through
I Traffic conditioning
I Packet scheduling
I Controlling
• End-to-end delay
• Delay variation (jitter)
• Packet loss
• Bandwidth
According to mutually agreed Service Level Agreements
(SLAs).
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control

AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.7
Traffic Engineering Traffic Engineering
§6.2.1 Traffic Engineering
Measurement
I To do reality check
Experiment
I To test implementation Issues
Analysis
To bring fundamental understanding of the systems
I May loose important facts because of simplification
Simulation

I Complementary to analysis
• To test correctness
• To explore complicate model
I May share similar model to analysis
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet

Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.8
Traffic Engineering What is Congestion
§6.2.2 What is Congestion
Question 6.1 (What is congestion?)
Answer: The aggregate demand for bandwidth exceeds the
available capacity
of a link
Question 6.2 (What are the consequences when congestion
occurs?)
Answer: Performance degradation
Multiple packet losses
Low link utilization (low Throughput)
High queuing delay
Congestion collapse

Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm

References
6.9
Traffic Engineering Congestion Control
§6.2.3 Congestion Control
1 Open-loop control
I No feed-back mechanisms
I Mainly used in circuit switched network Generalized
Multiprotocol Label
Switching (MPLS)
2 Closed-loop control
I Uses feedback information ⇒ global & local
I Mainly used in packet switched network
a Implicit feedback control
• End-to-end congestion control
• Examples: TCP Tahoe, TCP Reno, TCP Vegas, etc.
b Explicit feedback control
• Network-assisted congestion control
• IBM SNA, DECbit, ATM ABR, ICMP source quench, RED,
ECN
Two Basic Approaches
1 Congestion Control (Reactive)
I Play after the network experienced congestion
2 Congestion Avoidance (Proactive)
I Play before he network becomes congested

Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management

CoDel Algorithm
References
6.10
Traffic Engineering Implicit vs. Explicit feedback
§6.2.4 Implicit vs. Explicit feedback
1 Implicit feedback Congestion Control
I Network drops packets when congestion occurs
I Source infers congestion implicitly
• It times out
K Duplicated Acks, etc.
Û Duplicated Acks arrive when the time-out is shorter than RTT
I Example: end-to-end TCP congestion Control
I It is a simple to implement but inaccurate ⇓ Why?
• It is implemented only at the transport layer ( L4, e.g., TCP)
2 Explicit feedback Congestion Control
I Router (L3) provides congestion indication explicitly to
sources
• Normally through packet marking
I Examples
• DECbit
• Explicit Congestion Notification (ECN)
• Asynchronous Transfer Mode (ATM) Available Bir Rate
(ABR)
I It provides more accurate information to sources ⇑
I It is more complicate to implement

• Need cooperation between source and network
• Need to change both source and network algorithms
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues

Controlled Delay
Management
CoDel Algorithm
References
6.11
Traffic Engineering TCP Congestion Control
§6.2.5 TCP Congestion Control I
Slow Start
cwnd
W
1
4
2
RTTRTTRTT
time
h
Wh
W
/2

c
W +1c
Congestion
Avoidance
Exponential growth
Slow Start has two phases
1 Exponential growth phase
• Start with Wc = 1
• For each Ack, Wc := Wc + 1 segment
• For each RTT, Wc := 2 × Wc ⇒ exponential growth
• Until it reaches the threshold Wh , i.e., Wc ≥ Wh
• Wc = Wc/2, then enters Congestion Avoidance phase
2 Congestion avoidance phase (linear growth)
• For each successful ACK Wc := Wc + 1/Wc How?
• For each RTT Wc := Wc + 1
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering

What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.12
§6.2.5 TCP Congestion Control II
Does it do the job?
TCP Tahoe
Uses Slow Start + Fast Retransmission
Reduces the time a sender waits before retransmitting a lost

segment
I Triple duplicate Acks are treated the same as a timeout How?
• An indication of segment lost
I The sender retransmits the packet before waiting for its
timeout
Fast retransmit ⇒ an enhancement
I Set Wh = Wc/2
I Set Wc = 1 segment and Slow Start
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications

Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.13
§6.2.5 TCP Congestion Control III
TCP Reno
Uses Tahoe + Fast Recovery
Upon receiving triple duplicate Acks, i.e. packet must have
been lost
and not received after 3 RTTTs
I Sets Wc = Wc/2
I Retransmits the missing segments
I Sets Wc = Wh + 3
Upon receiving next Ack,
I Sets Wc = Wh
It allows the window size grow fast to keep the pipeline full

Active Queue
Management
Acronyms
Introduction
Traffic Engineering
Traffic Engineering
What is Congestion
Congestion Control
AQM
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References

6.14
§6.2.5 TCP Congestion Control IV
Additive Increase/Multiplicative Decrease
Additive-increase/multiplicative-decrease (AIMD) algorithm is
a
feedback mechanism used in TCP
I AIMD combines linear growth of the congestion window with
an
exponential reduction when a congestion takes place
Multiple flows using AIMD congestion control will eventually
converge
to use equal amounts of a contended link
Let Wc(t) be the sending rate during time slot t, then
Wc(t + 1) =
{
Wc(t) + a If congestion is not detected
Wc(t)× d If congestion is detected
a > 0, 0 < b < 1 (1)

Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM
AQM Goals
Random Early Detection
(RED)
How about non-responsive
sources?
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.15

AQM AQM
§6.3.1 AQM
TCP performance degradation due
I Multiple packet loss
I Low link utilization
I Congestion collapse
The role of the router becomes important
I Control congestion effectively inside the network How?
I Allocate bandwidth fairly How?
One option is to use FIFO Tail-Drope (TD) queue management
I Two problems with TD
• Lock-out: a small number of flows monopolize the queue
• Full-queue: the buffer is always full ⇒ high queuing delay
One possible solution is AQM
I A group of FIFO based queue management mechanisms to
support
end-to-end congestion control in the Internet
Active Queue
Management
Acronyms
Introduction

Traffic Engineering
AQM
AQM
AQM Goals
(RED)
sources?
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.16
AQM Goals AQM Goals
§6.3.2 AQM Goals
Reducing the average queue length
I That decreases the End-to-End (E2E) delay

Reducing packet losses How?
I More efficient resource allocation
Method
Drop some packets before buffer becomes full How?
I Some random algorithms
Use Exponentially Eeighted Moving Average (EWMA) of the
queue
length as an congestion indicator Why?
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM
AQM Goals
(RED)
sources?

AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.17
AQM Goals Random Early Detection (RED)
§6.3.3 Random Early Detection (RED) I
TCP (Tahoe, Reno, Vegas) detect congestion after a buffer at an
intermediate router is full
RED provides a warning to sources ⇒
I It detects incipient congestion
Congestion measure ⇒ Average queue length
Q(t + 1) = [Q(t) + λ(t)−µ(t)]+
RED objectives
1 Congestion avoidance ⇒ proactive rather than reactive
I Detect the onset of congestion, rather than react to it
I Maintain the optimal region of high throughput and low delay

2 Avoid bias against bursty traffic
I Probabilistic drop/mark
3 Preventing global synchronization or traffic oscillation
4 Bounded average queue length
5 Accommodating an equitable distribution of packet loss
I Fairness
6 Providing a lower delay or a lower jitter (delay variation)
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM
AQM Goals
(RED)

sources?
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.18
§6.3.3 Random Early Detection (RED) II
1 Uses EWMA Why?
Q =
(1 − Wq)× Q + Wq × Q if Q 6= 0
(1 − Wq)m × Q otherwise,
(2)
I Wq determines how rapidly Q w.r.t. Q,

I m accounts for the periods when the queue has been empty
• m estimates the number of packets that could have been
transmitted during an
idle period.
2 Probabilistically drops/marks packets
I Marking require ECN bit (RFC 2481)
It uses two thresholds Th and T` to control the growth of the
queue
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM
AQM Goals
(RED)
sources?

AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.19
§6.3.3 Random Early Detection (RED) III
Q
QmaxThTℓ
p
1
0
Pmax
If Q < T` accept the packet
If Q ≥ Th mark/drop the packet
If T` ≤ Q < Th mark/drop probabilistically with, Pa

(3)
Q is calculated at the packet arrival times
I Rather than at a fixed time interval Why?
Within the region [T`, Th), the probability of packet discard
depends
on the proximity of Q to Th and it is bounded by Pmax
When T` ≤ Q < Th, Pb increases linearly from zero to Pmax
Pb = Pmax ×
(Q − T`)
(Th − T`)
(4)
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM
AQM Goals

(RED)
sources?
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.20
§6.3.3 Random Early Detection (RED) IV
To mitigate any bias against bursty traffic, RED uses c,
I The number of consecutive packets that have escaped discard,
into the
probability of discard
As c increases, the probability of discard also increases
I This avoids penalizing bursty traffic by spacing the discards
quite evenly

rather than in a cluster
Pa modifies Pb by 11−c×Pb ,
Pa = Pb ×
1
1 − c × Pb
(5)
Performance
I Desynchronization works well ⇑
I Very sensitive to parameter setting ⇓
I Fails to prevent buffer overflow as the number of sources
increases ⇓
Over 100 AQM have been developed since RED ⇒ see [1]
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM

AQM Goals
(RED)
sources?
AQM Classifications
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.21
AQM Goals How about non-responsive sources?
§6.3.4 How about non-responsive sources?
Generally, User Data Protocol (UDP) is non-responsive
What routers want to do
I Isolate non-responsive flows
I Provide Quality of Service to all users
Two ways to do that
1 Scheduling algorithms
• Fair Queuing (FQ)

• Weighted Fair Queuing (FWQ)
• Core Stateless Fair Queuing (CSFQ)
• Stochastic Fair Queuing (SFQ)
2 Queue management algorithms
• RED
• Fair Random Early Detection (FRED)
• vdots
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Classification Based on
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet
Understanding

Queues
Controlled Delay
Management
CoDel Algorithm
References
6.22
AQM Classifications Classification Based on Congestion
Control
§6.4.1 Classification Based on Congestion Control
LocalGloba
Responsive
Persistent
(global)
Implicit
feed−back
(global)
Explicit
feed−back
Closed loop control
Source control Destination control
Open loop control

AQM Schemes
Open-loop flow/congestion control
I No feedback mechanism between the receiver and the
transmitter
• Maximizing the utilization of network resources
I It has two controls
• Controller
• Regulator ⇒ alters the input variable in response to the signal
from the controller
Closed-loop flow/congestion control
I The network/node can report pending network congestion back
to the
transmitter
I It has some basic control elements
• Sensor, controller, regulator, and transmitter
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM

AQM Classifications
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.23
AQM Classifications Classification By Mechanisms
§6.4.2 Classification By Mechanisms I
Based on Congestion Indicator
Congestion
Indicator
Queue-based

Enqueue events only ⇒ RED, GRED,CHOKEe,DRED
Enqueue & Dequeue events ⇒ FRED
Rate-based
Arrival rate ⇒ LUBA,SFED,RARED
Congestion window size ⇒ SHRED
Load-based
Flow count ⇒ GREEN, BLACK, SFED
Traffic composition ⇒ RED Worcester
Packet Loss
Loss volume ⇒ LRED
# of buffer over/under flow events ⇒ BLUE
Mixture
{

⇒ Load/Delay controllers, Yellow
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm

References
6.24
§6.4.2 Classification By Mechanisms II
Based on Parameter Tuning
Parameter
Tuning
Static
{
⇒ RED, GRED
Dynamic
Network Load ⇒ GREEN
Bandwidth × Distance ⇒ - - -
Round-Trip-Time ⇒ GREEN
Link Capacity ⇒ GREEN
Mixture
{

⇒ ARED, A-RIO, PSAND
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm

References
6.25
§6.4.2 Classification By Mechanisms III
Based on Flow Differentiation
Flow
Differentiation
None
{
⇒ RED, GRED
Flow
aggregates
Two-class system: (Non)Responsive⇒ Stochastic Fair BLUE,
RIO-C
Two-class system: Web vs. FTP⇒ SHRED
Multiple-class system⇒ RIO-DC, WRED,Rb-RIO, D-CBT,
SFED
Individual

flows
{
⇒ FRED, BRED, BLACK
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet
Understanding
Queues
Controlled Delay
Management

CoDel Algorithm
References
6.26
§6.4.2 Classification By Mechanisms IV
Based on Control Function
Control
Function
Heuristic
Equation-based ⇒ RED, GRED,Hyperbola RED, DSDRED
Non-equation-based ⇒ MRED
Control-Theoretic
Classic and Modern Control ⇒ PI, PD, GPC, PI-PD, PD-PD, ...
Fuzzy Control ⇒ Fuzzy control RED, Adaptive Fuzzy RED, ...

Optimization
Deterministic ⇒ REM, AVQ, SVB
Stochastic ⇒ - - -
Neural Networks ⇒ Neural Network-based PID controller
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Congestion Control
Classification By
Mechanisms
Bufferbloat in the
Internet

Understanding
Queues
Controlled Delay
Management
CoDel Algorithm
References
6.27
§6.4.2 Classification By Mechanisms V
Based on Feedback Signal
Feedback
Signal
Packet dropping
Random ⇒ RED, GRED, CHOKe, REM, SVB
Deterministic ⇒ AVQ
ECN Marking

Random ⇒ RED, REM, G
Deterministic ⇒ AVQ
Active Queue
Management
Acronyms
Introduction
Traffic Engineering
AQM
AQM Classifications
Bufferbloat in the
Internet
Bufferbloat in the Internet
Understanding
Queues
Controlled Delay
Management
CoDel Algorithm

References
6.28
Bufferbloat in the Internet Bufferbloat in the Internet
§6.5.1 Bufferbloat in the Internet I
Bufferbloat is the existence of excessively large and frequently
full
buffers inside the network [4], [3]
Bufferbloat is due to
1 More available and cheap memory
• Resulted in buffer proliferation
2 At the edge buffers become extremely oversized due to
• Dynamically varying path characteristics
• Link rates and path delays fall below nominal values
Unmanaged large buffers are more critical these days
I Delay-sensitive applications are more prevalent
I Streaming
Packet networks require buffers to absorb short-term arrival rate
fluctuations
Buffers tend to fill up and remain full at congested links
I Results in excessive traffic delay and packet loss
I Missing their intended function to absorb bursts
Active Queue
Management

1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx

1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx

Recommended

Recommended

More Related Content

Similar to 1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx

Similar to 1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx (13)

More from jackiewalcutt

More from jackiewalcutt (20)

Recently uploaded

Recently uploaded (20)

1. Software-Defined Networks (SDN) is a new paradigm in network ma.docx