-
8/18/2019 jin-sosr-15
1/7
Telekinesis: Controlling Legacy Switch Routing withOpenFlow in
Hybrid Networks
Cheng Jin∗∗, Cristian Lumezanu†, Qiang Xu†, Zhi-Li Zhang∗,
Guofei Jiang†∗University of Minnesota,
{cheng,zhzhang}@cs.umn.edu
†NEC Laboratories America, {lume,qiangxu,gfj}@nec-labs.com
ABSTRACT
Hybrid networks contain both legacy and programmable
network switches and allow operators to reap the benefits of
Software-definednetworking (SDN) without upgrading the entire
network. Previousresearch shows that adding SDN capabilities to
switches at strate-gic places in a network and ensuring that each
flow traverses atleast one such switch is sufficient to achieve
many SDN controlparadigms, such as routing or access control.
However, the controlpoints are still limited to the SDN-enabled
devices and operatorscannot enforce fine-grained policies on the
legacy paths betweenSDN switches.
We present Telekinesis, a network controller that enables
finer-grained routing control over legacy paths in hybrid networks
usingOpenFlow. To update routing entries in legacy switches, we
intro-duce a new flow control primitive, LegacyFlowMod .
LegacyFlow- Mod uses OpenFlow’s
PacketOut function to send a special packeton a
specific interface of a legacy switch and remotely manipu-late the
forwarding entry associated with the source of the packet.Using
simulations on random network topologies with varying de-grees of
OpenFlow deployment, we show that Telekinesis can pro-vide more
diverse path control than an OpenFlow-only controller:even when
only 20% of switches are OpenFlow-enabled, we can
update 70% of the paths.
Categories and Subject Descriptors
C.2.1 [Computer-Communication Networks]: Network Archi-tecture
and Design; C.2.3 [Computer-Communication Networks]:Network
Operations
General Terms
Design, Management
Keywords
Telekinesis; Hybrid SDN
∗Most of this work was conducted while the first author was
anintern at NEC Laboratories America.
Permission to make digital or hard copies of all or part of this
work forpersonal or classroomuse is granted without fee provided
that copiesare notmade or distributed for profit or commercial
advantage and that copies bearthis notice and the full citation on
the first page. Copyrights for componentsof this work owned by
others than ACM must be honored. Abstracting withcredit is
permitted. To copy otherwise, or republish, to post on servers or
toredistribute to lists, requires prior specific permission and/or
a fee. Requestpermissions from
[email protected], June 17 - 18, 2015, Santa Clara,
CA, USA.Copyright 2015 ACM. ISBN 978-1-4503-3451-8/15/06$15.00.DOI:
http://dx.doi.org/10.1145/2774993.2775013.
1. INTRODUCTIONSDN provides a logically-centralized interface to
control and in-
teract with network devices. Operators perform network
manage-ment tasks such as traffic engineering or access control
throughsoftware programs executed from a centralized controller.
The flex-ible control and expanded visibility offered by
SDN [7] can reducethe cost of operating a network by half
[2]. However, fully ben-efiting from SDN requires a considerable
initial investment: net-
work providers must upgrade or replace all legacy devices with
pro-grammable ones (e.g., whose forwarding tables are
programmableremotely from a logically-centralized controller using
a specializedprotocol such as OpenFlow)1.
Recent work, both in academia and industry, attempts to
reducethe capital expenditure of SDN while maintaining most of its
ben-efits, by upgrading only a few, strategically chosen devices in
anetwork. We refer to such networks as hybrid networks.
Panopti-con develops an optimization framework to determine the
locationof partial SDN deployment and enforces that every network
flowtraverse at least one SDN-enabled switch [5]. HybNET provides
acommon configuration mechanism for an existing hybrid
network and automatically translates legacy to SDN
configurations and viceversa[6]. VMWare’s NSX forgoes physical
programmable switches
altogether and implements SDN in hypervisors at the edge of
thelegacy network [4].
Although effective at controlling paths through SDN-enabled
de-vices, neither Panopticon nor NSX can dynamically affect the
con-figuration of legacy switches and, consequently, the paths
throughthe legacy nework. Legacy network paths between two SDN
switchesarecoarsely controlled using VLANs or tunnels [5, 4] or
simply leftto the latitude of Layer 2 routing protocols such as STP
or ECMP.HybNET proposes a netconf-based mechanism to change
legacyswitch routing but its speed (more than 10s to configure a
switch)makes it incompatible with real world networks.
In this paper, we explore the following question: can we
extend the main capability of an SDN switch (that of allowing
remote pro-
gramming of its forwarding tables) to legacy devices in the
same
hybrid network? In other words, can we control
paths throughlegacy switches with the same network controller used
to manage
the SDN devices?
Towards answering this question, we introduce Telekinesis,
anetwork management framework that enables fine-grained
routingcontrol over legacy paths in hybrid SDN using OpenFlow. To
up-date routing entries in legacy switches, we propose a simple
primi-tive, LegacyFlowMod . When
calling LegacyFlowMod with respect
1Throughout the paper, we interchangeably use the terms
pro-grammable, SDN(-enabled), or OpenFlow(-enabled)
to refer toswitches whose forwarding entries can be updated
from a remotecontroller using OpenFlow.
-
8/18/2019 jin-sosr-15
2/7
to an OpenFlow switch A, a legacy switch B, a port on the
legacyswitch p, and a MAC address m, Telekinesis
instructs the Open-Flow switch to send a special packet (with m as
the source MAC)to port p on the legacy switch. Assuming that
B runs MAC learn-ing, it will update its forwarding entry for
m. This mechanismallows us to remotely manipulate a
forwarding entry on a legacyswitch using OpenFlow and MAC
learning.
Telekinesis is similar conceptually to Fibbing, a mechanism
pro-
posed by Vissicchio et al.to improve the flexibility and
diversity of Layer 3 routing [9]. Indeed, Telekinesis and
Fibbing share the samephilosophy: that we can indirectly affect
network routing by inject-ing fake and harmless information into
the network. However, theirscope and goals are different.
Telekinesis works at layer 2 in hybridSDN networks consisting of
legacy and OpenFlow switches, withthe goal of improving path
diversity by providing more fine-grainedlegacy path control.
Fibbing works in layer 3 legacy networks con-sisting of only legacy
routers. It injects fake network topologiesinto link-state routing
to improve routing flexibility, while ensuringloop-free paths.
Not all network paths can be enforced by Telekinesis. Updatinga
forwarding entry for MAC m to port p
requires that the switchbe accessible on port p. For this,
p must be directly connected toan OpenFlow switch or be
part of the layer 2 underlay that controlsMAC-level routing (e.g.,
spanning tree). Given a path to update,Telekinesis first checks
whether the update is possible for everyswitch on the path and then
attempts to enact it. Using experimentson random network topologies
with varying degrees of OpenFlowdeployment, we are able to update
70% of the paths, when only20% switches in the network are
OpenFlow-enabled.
When there is no data traffic traversing theoriginal path,
Telekine-sis can update the configuration to a new path using a
constant over-head, proportional to the number of legacy switches
on the newpath but not on the old one. Data traffic on the original
path mayoverride the path updates if not all switches on the new
path areupdated quickly enough. To ensure that an update is
eventually ap-plied, Telekinesis adapts to the rate of underlying
data traffic andadjusts the rate of special packets
accordingly.
We make the following contributions. First, we present an
Open-Flow based primitive, LegacyFlowMod , to remotely
configure for-warding entries for legacy switch interfaces
reachable from an SDNswitch in the same hybrid network. Second,
based on LegacyFlow- Mod , we design Telekinesis, a
hybrid network controller that achievesbetter path diversity and
more fine-grained path control than regularOpenFlow controllers
deployed in a hybrid network.
The rest of the paper is structured as follows. In
Section 2, wediscuss the motivation for deploying hybrid
networks and presenta short overview of path enforcement in layer 2
legacy and Open-Flow networks. Section 3 describes how
to remotely manipulatelegacy switch forwarding tables using
OpenFlow and sketches thedesign for Telekinesis, our hybrid network
controller. We presenta preliminary evaluation in Section 4,
followed by conclusions and
an introspection into planned future work in Section 5.
2. BACKGROUND AND MOTIVATIONIn this section, we introduce hybrid
layer 2 networks and discuss
mechanisms to enforce a given path in either legacy networks
orsoftware-defined networks.
2.1 Hybrid NetworksHybrid networks (also called transitional
networks by Levin et al.[5])
contain both OpenFlow and legacy switches. They provide a
trade-off to network providers between the cost to deploy and the
benefitderived from having a software-defined network. Because
providers
do not need to upgrade the entire network, they can take
advantageof the increased control and visibility provided by SDN at
a frac-tion of the cost [5, 4, 6]. However, the increased
control is stilllimited to the SDN-enabled devices. Neither of the
existing hybridnetworks provide a way to dynamically manage the
configurationof legacy devices. Thus, legacy paths between SDN
switches mustbe manually set up (e.g., with VLANs) or left in the
care of layer 2protocols such as STP. Next we present a short
overview of path en-
forcement in both legacy networks and software-defined
networks.2.2 Path Enforcement
Legacy networks. Standard layer 2 Ethernet switches
performtwo main functions: learning (the next-hop switch towards a
desti-nation MAC address) and forwarding (a packet according to
learnedinformation). To learn the next-hop switch for a packet,
layer 2switches broadcast the packet on all ports except the one on
whichthe packet arrived. To prevent loops they restrict the
underlyingtopology to a spanning tree by turning off (e.g., using
STP) or ag-gregating (e.g., using link aggregation) multiple links.
To learn theport on which to forward a packet with a specific MAC
address,switches use MAC learning: if a packet with source address
m ar-rives on port p they assume that any future packet with
destinationaddressm can be delivered through p. The path of a
packet is staticand changes only if there are topology or
configuration changes inthe network. To increase path diversity,
operators can slice the net-work into multiple VLANs, each with its
own spanning tree and setof forwarding entries.
Figure 1a shows how to set up a path in a legacy
network. Thenetwork builds a spanning tree to prevent broadcast
loops. As a re-sult, the traffic between S and D will be re-routed
on the spanningtree. This limits path selection flexibility,
as feasible paths mustcontain spanning tree links, and
network performance, as pathsmay be much longer than necessary.
Software-defined networks. Software-defined networking
al-lows operators or software programs to remotely modify their
for-warding entries from a logically-centralized controller using a
spe-cialized protocol such as OpenFlow [7]. Thus, switches
learn about
unknown destinations and routing policies without requiring
ex-pensive broadcast or complex configurations. Unlike legacy
net-works, SDNprovides explicit and fast path control across the
wholetopology. If all switches in Figure 1a are OpenFlow
switches, ex-plicit rules can be added in the switches to easily
set up any pathbetween S and D, thereby improving both path
selection flexibilityand network performance.
Hybrid networks. Hybrid networks retain some of the
advan-tages of SDN with respect to path selection and network
perfor-mance. When replacing a legacy switch with an OpenFlow
switch,we add yet another point of control into the network, which
mayenable setting up new and better paths (see Figures
1a and 1b).
Fully controlling paths in hybrid networks requires control
of both the OpenFlow switches and the legacy switches on the
paths.
Although some switch vendors enable remote configuration
(e.g.,using netconf ), this is usually slow and not
amenable to the speedof real world networks. In the next section,
we present a simplemechanism that allows us to use OpenFlow and the
learning func-tion in legacy switches to remotely configure
forwarding entries onlegacy switches.
3. DESIGNAt the heart of this paper lies a simple question:
can we use
OpenFlow to control and update forwarding entries on legacy
net-
work switches? In this section, we describe a simple
mechanismthat realizes such control on specific switches. We then
introduce
-
8/18/2019 jin-sosr-15
3/7
(a) A legacy network with six switches. The spanning tree
createdby SPT (depicted by the blue links) dictates network
paths.
(b) A hybrid SDN network. All the links in the spanning tree
andadjacent to the OpenFlow switch can be used.
Figure 1: Path setup in legacy and hybrid networks.
the preliminary design of Telekinesis, a controller for hybrid
SDN
networks that provides fine-grained control over both SDN
andlegacy paths.
3.1 Goal and AssumptionsAssumptions: We consider a layer 2
hybrid network with both
programmable and legacy switches. We control the
programmableswitches with OpenFlow, but we cannot directly update
the legacyswitch forwarding entries. While technically feasible,
remote con-figuration for legacy switches (e.g., using
netconf ) is slow and un-reliable [6]. A forwarding
entry consists of a destination MAC ad-dress m and an action
(e.g., “send to port”, “drop”) to be appliedto packets
whose destination MAC is m. We also assume that eachlegacy switch
runs MAC learning and that the legacy network isconfigured, either
manually or automatically, to avoid routing loops
(e.g., with STP). We call the collection of legacy links that
resultsafter this configuration the network underlay. The
underlay is aalways a tree or a collection of trees.
Goal: Given a configured path (i.e., a sequence of
switches) P between two hosts A andB attached to a
hybrid network and a newpath P ′, we want to
enforce P ′ in the network, i.e., change the
pathbetween A and B from P to P ′.
Figure 2: An example of P and
P ′. (1,6,2) and (4,7,5) are thesubpaths needed to be
updated.
3.2 IdeaOur insight is to use OpenFlow switches to send special
packets
to the legacy switches on the new path. These packets take
advan-tage of MAC learning to manipulate legacy switches
into updatinga single forwarding entry in their routing tables. For
example, if we want to modify the action of a routing entry
for MAC m from“send to port p1” to “send to port p2”,
we create a packet whose
source address is m and make sure it arrives at the switch on
port
p2. The MAC learning algorithm sees the packet arriving
on p2 andassumes its source addressm is reachable on p2,
therefore updatingthe corresponding forwarding entry.
Updating P to P ′ requires updating
all switches on P ′ but not onP and all
switches where the two paths diverge and converge 2
. Forexample, in Figure 2, we must update all
switches except switch 3.We refer to an update
subpath as a sequence of adjacent switchesthat must be updated
during a path change. In Figure 2, (1,6,2) and(4,7,5)
form subpaths.
All special packets that we use to remotely manipulate a
legacyswitch’s forwarding table must arrive at the switch on a link
that ispart of the path we want to install. This leads to the two
conditionsthat a path P ′ needs to satisfy before it can
be enforced:
Condition 1: All legacy links on path P ′
(i.e., links that have
at least one legacy switch as endpoint) must be either part of
thelegacy layer 2 network underlay (e.g., the spanning tree) or
adjacentto an OpenFlow switch. This guarantees that each legacy
link onP ′ is reachable from an OpenFlow switch.
Condition 2: Every update subpath of P ′
must contain at leastone OpenFlow switch. Otherwise, no OpenFlow
switch in the net-work can send a special packet that reaches a
switch on the updatesubpath through a link part
of P ′, even if the update subpath is partof the
layer 2 underlay.
3.3 TelekinesisWe now present the preliminary design of
Telekinesis, a hy-
brid network controller that can modify forwarding tables on
bothOpenFlow and legacy switches. Telekinesis mirrors the design
of
a general OpenFlow network controller and adds two
components: path verification and path update.
Given a network configuration(i.e., forwarding tables on all
switches and the network underlay)and a new path P ′ to
enforce between two endpoints attached tothe network, Telekinesis
first checks whether the path P ′ is feasi-ble and then
proceeds to update each switch on the subpaths. Wepresent the two
components in detail below.
3.3.1 Path Verification
Given a path P ′ and the current network
configuration, path ver-ification determines whether P ′
is feasible in the network. First, it
2We assume the reverse paths are updated as well.
-
8/18/2019 jin-sosr-15
4/7
(a) Enforce the path between S1 and D1 in the initial stage
where notraffic between end-hosts.
(b) Change the path between S1 and D1 to a new one:(LE 2,
LE 3, OF 6, LE 5), while the connection is still
alive.
Figure 3: An example of path update in a hybrid network.
verifies if all legacy links on path P ′ are part of
the legacy layer
2 network underlay or adjacent to an OpenFlow switch,
followingCondition 1. Second, for every update subpath
of P ′, Telekinesisverifies whether at least one
switch is OpenFlow enabled, followingCondition 2. If both
conditions hold, Telekinesis updates the for-warding entries in one
or more OpenFlow switches (for subpathsstarting or ending with at
least one OpenFlow switch) or uses oneOpenFlow switch to send a
LegacyFlowMod message (for legacylinks part of the
underlay). Algorithm 1 presents the steps takenwhen
verifying the feasibility of a path.
Algorithm 1 : Path Verification Algorithm
1: for xkP
′−P yk do
2: for each legacy link eLEi
do
3: if eLEi
not in the underlay and eLEi
contains only legacy
switches then4: return P ′ is infeasible5:
end if 6: end for7: tag ← 08:
for each switch ni do9:
if ni is OpenFlow enabled then
10: tag ← 111: break12: end
if 13: end for14: if tag =
0 then15: return P ′ is infeasible16: end
if 17: end for18: return P ′ is feasible
3.3.2 Path Update
To support forwarding entry updates on legacy switches, we
in-troduce a new primitive, called LegacyFlowMod . We
use Lega-cyFlowMod to generate and send special
packets to the switch wewant to control. The only requirement we
enforce on the headerof these packets is that their source MAC
address should be thesame as the MAC associated with the forwarding
entry we want tochange. Special packets may have any time. However,
to limit theside-effects to the network, we send ARP packets, as
they updateonly ARP caches in hosts and switches. To send a special
packet,we use OpenFlow’s PacketOut functionality,
which allows us to use
any OpenFlow switch we control to put a packet on the data
plane.
We must be careful to call PacketOut with
respect to an OpenFlowswitch that can reach the intended legacy
switch using a link that ison the new path we want to enforce.
Algorithm 2 presents the pathupdate process.
Figure 3 shows an example of path update. Initially,
the pathbetween S and D is (LE 2,
OF 6, LE 5) and we want to update
itto (LE 2, LE 3, OF 6, LE 5). This
requires changing the forward-ing entries on LE 2 (to
forward packets for D to LE 3 rather thanOF 6)
and on LE 3 (to forward packets for D to OF 6
rather thanLE 2). Telekinesis calls
LegacyFlowMod to send special pack-ets from
OF 6 to LE 3. The packets contain the
address of D astheir source MAC address and
trigger the learning algorithms onswitches LE 2 and
LE 3 to update their forwarding tables accord-ing to the
incoming interfaces. When updating a path, Telekinesisautomatically
updates the reverse path as well. For brevity, we omitthe
description of reverse path change but reflect it in Figure
3. Inthis example, as the subpath (LE 2,
LE 3, OF 6) starts or ends withone OpenFlow
switch, i.e.OF 6, we can also simply update the
for-warding entry in OF 6 to redirect traffic
from D to S on the
link (OF 6, LE 3). In this way, LE 2 will
change the forwarding entryto forward future packets for D
to LE 3 after it receives one datapacket
from LE 3.
Algorithm 2 : Path Update Algorithm
1: for xkP
′−P yk do
2: tag ← 03: for each switch ni
do4: if ni is OpenFlow
enabled then5: add forwarding rules in ni
for P ′
6: if tag = 0 then7:
call LegacyFlowMod to send special packets8:
tag ← 19: end if
10: end if 11: end for12: end for
3.4 DiscussionThe key to our path enforcement is to make legacy
switches re-
act to fake packets sent along the path we want to set up.
Whensetting up a new path, we change the state of the legacy
switches at
-
8/18/2019 jin-sosr-15
5/7
(a) (b) (c)
(d) (e) (f)
Figure 4: An example of path flapping. LE1 and LE2 are legacy
switches, and OF3 is an OpenFlow switch. Assume the connection
betweenS and D has been set up, and traffic is going on the
path (LE 1, LE 2). We want to change the path to
(LE 1, OF 3, LE 2).
LegacyFlowMod only injects special packets towards
S.
the intersection between the old (existing) path and the new
path.However, the state may revert if data packets on the reverse
origi-nal path arrive at a switch after our special packets. The
late packet,which has the same source MAC as our special packet but
arriveson a different port, modifies the forwarding table on the
switch to
the original entry. We call this phenomenon path flapping.
Next wepresent an example of path flapping and discuss a
solution.In Figure 4, the original path between
S and D is (LE 1, LE 2)
and the new path to be setup is (LE 1, OF 3,
LE 2). Changing thepath requires updates to both legacy
switches. During the pathchange process,
S and D communicate to each other
(Figure 4a).However, after Telekinesis updates switch
LE 1 to forward trafficfor D to
OF 3 instead of LE 2 (Figure 4b), a
late reply from LE 2arrives at LE 1 on the
original path. This changes the forwardingentry associated with
D back to “send to LE 2” and
nullifies theoutcome of LegacyFlowMod
(Figure 4c). To guarantee the pathchange, Telekinesis must
send another special packet. Note thatthe problem would persist
even if we sent special packets to bothlegacy switches which
updated their configuration at the same time:there is a small
probability that a packet between D and S is on thewire
between LE 2 and LE 1 when the updates are
applied.
To overcome path flapping, we propose that Telekinesis
contin-ually injects special packets until legacy switches reach a
stablestate. This happens when data packets start traversing the
new pathin both directions. The controller can detect such events
by deploy-ing a matching rule on an OpenFlow switch that lies on
the newpath but not on the old one. How often Telekinesis injects
spe-cial packets depends on the rate of data packets traversing the
oldpath. Ideally, we would inject special packets to at least match
therate of the data packets. However, we also must be careful to
limitthe network overhead, as a high rate of special packets can
limitthe OpenFlow switch functionality and in extreme cases
introduce
congestion in the network.In this paper, we assume that path
updates in Telekinesis are not
atomic and that a path can flap back and forth before
stabilizing.Recent work in software-defined networking studied how
to per-form consistent network updates, such that all packets
follow either
the old or the new path [8, 3]. Such work is orthogonal to
the goalsof this paper but is part of one of the directions we
consider forfuture work.
4. PRELIMINARY EVALUATIONWe built a proof-of-concept prototype
for Telekinesis based on
the Pox OpenFlow controller to which we add the path
verificationand path update components. Our preliminary evaluation
focuseson two key questions: 1) can Telekinesis significantly
increase thedegree of control that we have over the network?, and
2) what isthe cost of such increased control in terms of
network overhead?
We use Mininet [1] to simulate a hybrid network.
To mimiclegacy switches, we set OVS into standalone mode
and disconnectthem from the controller. All other switches in the
network run
as normal OpenFlow switches. We configure VLANs on switchesto
construct the static network underlay. We also add a “default”rule
with low priority in all OpenFlow switches to drop all pack-ets, in
order to avoid forwarding any packets received from legacyswitches
which are used to conduct MAC learning. When we wantto enable a
path going through an OpenFlow switch, we add ex-plicit forwarding
rules with higher priority. We use Tcpdump tocapture all packets in
the network in order to measure the overheadof path update.
4.1 FeasibilityWe show that Telekinesis provides more diverse
path control
-
8/18/2019 jin-sosr-15
6/7
0
0.2
0.4
0.6
0.8
1
0.2 0.4 0.6 0.8 1
F r a c t i o n
o f S u c
c e s s f u l P a t h U p d a t e
Fraction of OpenFlow Switches
100 Switches500 Switches
1000 Switches
Figure 5: Succeed ratio of path updates with Telekinesis as a
func-tion of the fraction of OF switches.
compared to a controller that manages only the OpenFlow
devices.Using randomly generated network topologies with hundreds
tothousands of switches and at various degrees of OpenFlow
deploy-
ment, we compute the fraction of successful path updates. For
eachfraction of OpenFlow switch deployment, we run a hundred
ex-periments on random topologies with 100, 500, 1000 switches
re-spectively. We randomly generate a pair of old and new paths
be-tween two hosts, and verify whether the new path can be
updatedby Telekinesis. Our results present average across all
runs.
Figure 5 presents the success ratio of path updates
with Telekine-sis, while varying the OpenFlow switch coverage and
the network size. Even when only 20% of the switches are
OpenFlow-enabled,Telekinesis can update 70% of the paths.
Increasing the OpenFlowcoverage increases the percentage of
successful path updates. Thefigure also shows that the size of the
network has little effect onthe additional diversity unraveled by
Telekinesis: when the totalnumber of switches increases from 100 to
1000, the fraction of
successful path updates does not change much. This indicates
thatTelekinesis can serve large-scale networks.
4.2 OverheadEnforcing a new path introduces network overhead due
to the
special packets we send from OpenFlow switches. If there is
nopath flapping, it suffices to send a single packet for every
switchwhose configuration we want to update. With path flapping,
thenumber of packets we send depends on the rate of the data
trafficin the network.
Using the same setup as above, we randomly generate a pair
of old and new paths between two hosts, such that updating to
thenew path essentially requires updating at least the two switches
atthe intersection between the old path and the new path3. As
men-
tioned earlier in Section 3.3.1, if one of the
intersection switch isOpenFlow enabled, we can simply update a
forwarding entry in theOpenFlow switch to redirect traffic on the
link in the new path. Us-ing LegacyFlowMod to
send special packets accelerates the pathupdate but it is not
mandatory. Otherwise, Telekinesis must
call LegacyFlowMod to send special packets towards
the intersectionswitches. We experiment in the more general case
where both in-tersection switches are legacy to measure the network
overhead of path update. We continually send ICMP traffic
between the hosts.
3The fewest number of switches needed to be updated is two,and
it is more likely that these two intersection switches are
notOpenFlow-enabled.
0
0.2
0.4
0.6
0.8
1
0 1 2 3 4 6
F r a c t i o n o f S
u c c e s s f u l P a t h
U p d a t e
n Special Packets
1x (Faster) Data Interval-Single1.4x (Fast) Data
Interval-Single1.8x (Slow) Data Interval-Single
2x (Slower) Data Interval-Both
Figure 6: Cost to enforce a path update with Telekinesis as a
func-tion of the number of special packets.
We define the interval between data packets as the data
interval.We also inject special packets from an OpenFlow switch on
the newpath. The time between consecutive special packets is
the controlinterval. We vary the size of the control interval
among 1, 1.4, 1.8,and 2 times that of the data interval.
Figure 6 shows the cumulative distribution of the
number of spe-cial packets needed to apply an update on a switch
according tothe ratio between the data and control intervals. As
expected, thenumber of special packets needed to apply an update
increases withthe interval between special packets. Injecting
special packets withthe source MAC of both hosts, rather than a
single one, can changethe path faster (green line on
Figure 6), albeit at twice as much net-work overhead. This is
because switches do not need to wait untilthe direct path is
changed to update their forwarding entries for thereverse path.
5. DISCUSSION AND CONCLUSIONSWe presented a preliminary design
for Telekinesis, a hybrid net-work controller that manages
forwarding entries on both legacy andOpenFlow-enabled switches. The
main idea behind Telekinesis isthat we can use OpenFlow to send
special packets on selective in-terfaces of legacy switches to
influence the internal MAC learningof these switches. This allows
us to remotely manipulate the for-warding entries on these
switches.
This paper is only a first step towards enabling routing
controlover legacy paths in hybrid networks using OpenFlow. There
arestill many interesting issues to be addressed. First, we want to
im-prove the path enforcement mechanism adjusting to the
dynamicnetwork factors, such as data interval and latency. Second,
we willexplore the benefits of the strategic OpenFlow switch
placement.
Although Telekinesis can improve path control with random
Open-Flow switch locations, we believe a more careful deployment
canincrease the path diversity significantly.
6. ACKNOWLEDGMENTSWe thank the anonymous reviews for their
valuable feedback.
The bulk of this work was conducted while the first author wasan
intern at NEC Laboratories America. This research was sup-ported in
part by NSF grants CNS-1017092, CNS-1117536 andCRI-1305237, a
Raytheon/NSF subcontract 9500012169/CNS-1346688,DTRA grant
HDTRA1-09-1-0050 and DoD ARO MURI AwardW911NF-12-1-0385.
-
8/18/2019 jin-sosr-15
7/7
7. REFERENCES[1] Mininet. http://mininet.org/.
[2] Software Defined Networks
Study.http://www.currentanalysis.com/news/2014/
pr-SDN-NFV-Deployment.asp .
[3] KATTA, N. P., REXFORD, J., A ND WALKER, D.
Incrementalconsistent updates.
In HotSDN (2013).
[4] KOPONEN , T., AND ET AL. Network virtualization in
multi-tenant datacenters. In USENIX
NSDI (2014).[5] LEVIN, D., CANINI, M., SCHMID, S.,
SCHAFFERT, F., AND
FELDMANN, A. Panopticon: Reaping the Benefits
of Incremental SDN Deployment in Enterprise Networks. InUSENIX
Annual Technical Conference (2014).
[6] LU, H., ARORA, N., ZHANG, H., LUMEZANU, C., RHEE ,J. ,
AND J IANG, G. HybNET: Network Manager for a
HybridNetwork Infrastructure. In Middleware (2013).
[7] MCKEOWN, N., ANDERSON, T., BALAKRISHNAN, H.,PARULKAR, G.,
PETERSON, L., REXFORD, J., SHENKER,S. , A ND T URNER,
J. OpenFlow: enabling innovation incampus networks. ACM
Sigcomm CCR 38 (2008), 69–74.
[8] REITBLATT, M., FOSTER, N., REXFORD, J.,SCHELSINGER, C.,
AND WALKER, D. Abstractions fornetwork update.
In ACM Sigcomm (2012).
[9] VISSICCHIO, S., VANBEVER, L., A ND R EXFORD, J.
Sweetlittle lies: Fake topologies for flexible routing. In
ACM HotNets (2014).
http://mininet.org/http://mininet.org/http://www.currentanalysis.com/news/2014/pr-SDN-NFV-Deployment.asphttp://www.currentanalysis.com/news/2014/pr-SDN-NFV-Deployment.asphttp://www.currentanalysis.com/news/2014/pr-SDN-NFV-Deployment.asphttp://www.currentanalysis.com/news/2014/pr-SDN-NFV-Deployment.asphttp://www.currentanalysis.com/news/2014/pr-SDN-NFV-Deployment.asphttp://mininet.org/
