What is the SDN thing about anyway? - ieice

56 Pages·2012·2.64 MB·English

by  David Meyer

OpenFlow, Software Defined
Networking, and Where its All Going
David Meyer
World Telecommunications Congress 2012
March 04 – 07, 2012
Miyazaki, Japan
[email protected]
Agenda

• What is OpenFlow?
• A Bit on Current Next Gen OpenFlow Thinking
• Brief Overview of OF Standardization Efforts
• SDN History/SDN Controllers (if time)
• Where this is all Going: The Programmable Network
• Q&A
Before We Dive In Here…
• Plenty of reasons to be skeptical of OF/SDN, for example…

• The term SDN itself means everything to everybody

• Flow based networking
– All kinds of scalability/switch model questions
– All kinds of business questions
– Think about where flow based networking can be efficient

• Centralized Control, even if “logical”
– We have a lot of experience in building distributed control planes that scale well, are resilient, have baked in
code, …
– Again, think about where centralized control might be useful, and what scalability issues might arise in
controller based architectures

• How complex does the capability negotiation between the controller and target need to be?
– Does the controller need a “per-switch device driver”?

• OpenFlow is a network element level programming abstraction
– Is this the right programmatic level for “network programmability”?
– In particular, is programming at the forwarding plane level useful or a general purpose paradigm?

• My goal is for you leave this talk with more questions and maybe a few more answers about
OF/SDN than when you walked in
– And a clearer view about where SDN is all going
In the Beginning...

Ethane: Addressing the Protection Problem in
Enterprise Networks
Martin Casado
Michael Freedman
Glen Gibb
Lew Glendenning
Dan Boneh
Nick McKeown
Scott Shenker
Gregory Watson

Presented By: Martin Casado
PhD Student in Computer Science,
Stanford University
[email protected]
http://www.stanford.edu/~casado
A Little Later…OpenFlow
(again, with a cast of 2^10s)
Switch Model
OpenFlow Switch Model Version 1.0
Redirect to Controller
Encapsulate packet to controller
Apply actions
Flow Table Forward with
Packet
(TCAM) edits
Drop
OpenFlow Switch, v 1.0
Flow Table
Rule Action Stats
Packet + byte counters
1. Forward packet to port(s)
2. Encapsulate and forward to controller
3. Drop packet
4. Send to normal processing pipeline
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Port src dst type ID Src Dst Prot sport dport
+ mask
Header Fields for Matching (v.1.1)
OpenFlow Switch Specification Version 1.1.0 Implemented
t t
or or
e p p
d
o c st
c sr d
p
o P P
s P T T
s C C
a R
y cl A S S
Poegsstrr edaaatt hecsrr hedstr heepytr NALdi NALoptrrii PSLeball PSLcatrffi 4cvsr 4dvst oo4/pvtr STo4bvsti CDUPP// MPTepy CDUPP// MCPoed
n M Et Et Et V V M M P P P P T C T C
I I I I I I I
Table 3: Fields from packets used to match against flow entries.
4.4 M atching
Note that the ability to match over all of the header fields simultaneously essentially
“de-layers” the network stack
Packet In

Start at table 0
Why is this important: RYF-Complexity theory states that layering and
Yes
decentralization are fundamental to providing robust, scalable networks [AldersonDoyle2010]
Update counters
Match in Yes Execute instructions: Goto-
table n? • update action set Table n?
• update packet/match set fields
• update metadata
No No
Based on table configuration, do one: Execute action
• send to controller set
• drop
• continue to next table
Figure 3: Flowchart detailing packet flow through an OpenFlow switch.
On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3. The switch
starts by performing a table lookup in the first flow table, and, based on pipeline processing, may perform
table lookup in other flow tables (see 4.1.1). Match fields used for table lookups depend on the packet type
as in Figure 4.
A packet matches a flow table entry if the values in the match fields used for the lookup (as defined
in Figure 4) match those defined in the flow table. If a flow table field has a value of ANY, it matches all
possible values in the header.
To handle the various Ethernet framing types, matching the Ethernet type is handled based on the
packet frame content. In general, the Ethernet type matched by OpenFlow is the one describing what is
considered by OpenFlow as the payload of the packet. If the packet has VLAN tags, the Ethernet type
matched is the one found after all the VLAN tags. An exception to that rule is packets with MPLS tags
where OpenFlow can not determine the Ethernet type of the MPLS payload of the packet.
If the packet is an Ethernet II frame, the Ethernet type of the Ethernet header (after all VLAN
tags) is matched against the flow’s Ethernet type. If the packet is an 802.3 frame with a 802.2 LLC
header, a SNAP header and Organizationally Unique Identifier (OUI) of 0x000000, the SNAP protocol id is
matched against the flow’s Ethernet type. A flow entry that specifies an Ethernet type of 0x05FF, matches
all 802.3 frames without a SNAP header and those with SNAP headersthat do not have an OUI of 0x000000.
8
OpenFlow Version 1.X, X > 0
OpenFlow Switch Specification Version 1.1.0 Implemented
OpenFlow Switch
Packet +
Ingress
Packet ingress port + Packet
In port Table metadata Table ... Table Packet Execute Out
Action
0 1 n
Action
Set
Action Action
Set
Set = {} Set
(a) Packets are matched against multiple tables in the pipeline

{Any,Multi}cast (1.1) Find highest-priority m atching fl ow entry
ECMP (1.1)

Match fields: Match fields: Apply instructions:
Ingress port + MPLS I n g re s s p o r t + (1.1, n o t ie. Mpoudsifhy/ ppaockpe,t .&1 uqp)d ate match fi elds
metadata + Flow metadata +
IPv6 (1.2) (apply actions instruction)
pkt hdrs pkt hdrs
Table ii. Update action set (clear actions and/or
Action set Action set
write actions instructions)
iii. Update metadata
1.3 features being currently being considered
-- incremental features, PBB , …
Send m atch data and action set to
Configuration Protocol unde r c on-edxetv tealbolpement
(b) Per-table packet processing
Figure 2: Packet flow through the processing pipeline
The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing
always starts at the first flow table: the packet is first matched against entries of flow table 0. Other flow
tables may be used depending on the outcome of the match in the first table.
If the packet matches a flow entry in a flow table, the corresponding instruction set is executed (see
4.4). The instructions in the flow entry may explicitly direct the packet to another flow table (using the
Goto Instruction, see 4.6), where the same process is repeated again. A flow entry can only direct a packet
to a flow table number which is greater than its own flow table number, in other words pipeline processing
can only go forward and not backward. Obviously, the flow entries of the last table of the pipeline can
not include the Goto instruction. If the matching flow entry does not direct packets to another flow table,
pipeline processing stops at this table. W hen pipeline processing stops, the packet is processed with its
associated action set and usually forwarded (see 4.7).
If the packet does not match a flow entry in a flow table, this is a table miss. The behavior on ta-
ble miss depends on the table configuration; the default is to send packets to the controller over the control
channel via a packet-in message (see 5.1.2), another options is to drop the packet. A table can also specify
that on a table miss the packet processing should continue; in this case the packet is processed by the next
sequentially numbered table.
6
So What Is OpenFlow?
• A Switch Model
– Match-Action Tables (MAT)
– Per-flow counters
• An Application Layer Protocol
– Binary wire protocol, messages and state machine that allow
programming of the MAT
• A Transport Protocol
– TLS, TCP, ..

• Note that OF says nothing said about how a given target
implements the switch model  OF is an Abstract Switch
Model
– However, the model only deals with the forwarding plane