Managing and Securing Computer Networks Guy Leduc Chapter 2

1

2-1 2: Software-Defined Networks

Managing and Securing Computer Networks

Guy Leduc

Chapter 2: Software-Defined Networks (SDN)

Sections 4.4 and 5.5 from Computer Networking: A Top

Down Approach, 7th edition.

Jim Kurose, Keith Ross Addison-Wesley, April 2016.

Also Chapter 31 of Computer Networks and

Internets, 6th edition.

Douglas E. Comer Pearson Education, 2015.

©From Computer Networking, by Kurose&Ross


Chapter 2: goals ❒  The previous chapter introduced the topic of

network management, described the general idea of element management, and explained the widespread SNMP protocol and related concepts

❒  This chapter addresses a new promising technology for network management: SDN ❍ Motivation ❍ General approach ❍ Technology

2

2-3

2.1 Motivation for a new approach 2.2 Data Plane and Control Plane division 2.3 Generalized Forwarding and SDN 2.4 The SDN control plane 2.5 The Economics of SDN

Chapter 2: outline

2. Software-Defined Networks


Motivation for a new approach

❒ Why changing the network management paradigm?

❍ Generalize element management to network management

❍ Move from proprietary to open standards ❍ Automate and unify network-wide configuration ❍ Change from per-layer to cross-layer control ❍ Accommodate virtualization used in data center

3


Generalization to network management

❒ Traditional network management (e.g., SNMP) ❍  Deals with individual network elements

❍  A manager configures a router, measures a leased circuit, detects a failure of a switch, …

❒  Element management is arguably a low-level idea ❒  It should be replaced by a system that allows a manager

to issue commands that control the entire network ❍  All elements should not necessarily work exactly the same

❍  But they have to work together to achieve a high-level management policy


Move from proprietary to open standards

❒  Current devices include a vendor-specific management interface (e.g., specific CLI)

❒  Even when a vendor implements SNMP, it includes special extensions that only apply to the vendor’s hardware

❒  This perpetuates an approach in which individual elements are managed separately

❒  Goal: an open standard would allow the coordination of operations of multiple devices from multiple vendors

4


Automate and unify network-wide configuration

❒  Configuring individual elements by humans is an error-prone process!

❒  Configurations may have to be tailored to the location, the role, and the type of the device ❍  Internal device? Edge device?

❒  Network-wide consistency is needed but hard to ensure, especially at larger scales

❒  Idea: translate a general network-wide policy into appropriate configurations for each network element

2-8

Enable (easier) Traffic engineering (1)

Difficult Traffic Engineering Problem Q: what if network operator wants u-to-z traffic to flow

along uxyz, and u-to-w traffic to flow uvw? A: need to define link weights so traffic routing

algorithm computes routes accordingly (or need a new routing algorithm)!:

Link weights are only control “knobs”: wrong! 2: Software-Defined Networks

2 2

1 3

1

1 2

5 3

5

v w

u z

y x


5

2-9


Q: what if network operator wants to split u-to-z traffic along uvwz and uxyz (load balancing)?

A: can only do it if the costs of the 2 paths are equal and ECMP (Equal Cost MultiPath) is used (or need a new routing algorithm)

2: Software-Defined Networks

2 2

1 3

1

1 2

5 3

5

v w

u z

y x


2-10

y x

w v

z 2

2 1

3

1

1 2

5 3

5


u

v

x

w

y

z

Q: what if w wants to route blue and red traffic differently?

A: can’t do it (with destination based forwarding, and LS, DV routing) – Note: MPLS can do it!

2: Software-Defined Networks ©From Computer Networking, by Kurose&Ross

6


Change to cross-layer control

❒  Traditional network management divides responsibilities according to network layers: ❍  Layer-2 services: switches, VLANs, bridged networks ❍  Layer-3 services: IP address assignment, subnetting, IP routes ❍  MPLS (~ Layer 2.5)

❒  This misses larger cross-layer opportunities, e.g. ❍  Creating VLANs for certain types of IP traffic ❍  An appendix on VLANs is provided at the end of the chapter


Accommodate Data Center Virtualization

❒  Most data centers use virtualization technology (e.g., VMWare) ❍  A physical machine emulates multiple Virtual Machines (VMs) ❍  Each VM runs a copy of an OS, and needs its own IP

addresses ❍  VMs can migrate from one physical computer to another ❍  Migrations may occur frequently and in tens of msecs

❒  When a VM moves ❍  Network devices must be reconfigured for correct packet

delivery ❍  And conventional network management tools are inadequate

to handle frequent high-speed route changes

7

2-13


Chapter 2: outline


2-14

Software defined networking (SDN)

❒  Internet network layer: historically has been implemented via distributed, per-router approach ❍ monolithic router contains switching hardware, runs

proprietary implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF, BGP, PIM) in proprietary router OS (e.g., Cisco IOS)

❍  different “middleboxes” for different network layer functions: firewalls, load balancers, NAT boxes, …

❒  ~2005: renewed interest in rethinking network control plane


8

2-15

Recall: per-router control plane

Routing Algorithm

Individual routing algorithm components in each and every router interact with each other in control plane

to compute forwarding tables

data plane

control plane

4.1 • OVERVIEW OF NETWORK LAYER 309

tables. In this example, a routing algorithm runs in each and every router and both forwarding and routing functions are contained within a router. As we’ll see in Sec-tions 5.3 and 5.4, the routing algorithm function in one router communicates with the routing algorithm function in other routers to compute the values for its forward-ing table. How is this communication performed? By exchanging routing messages containing routing information according to a routing protocol! We’ll cover routing algorithms and protocols in Sections 5.2 through 5.4.

The distinct and different purposes of the forwarding and routing functions can be further illustrated by considering the hypothetical (and unrealistic, but technically feasible) case of a network in which all forwarding tables are configured directly by human network operators physically present at the routers. In this case, no routing protocols would be required! Of course, the human operators would need to interact with each other to ensure that the forwarding tables were configured in such a way that packets reached their intended destinations. It’s also likely that human configu-ration would be more error-prone and much slower to respond to changes in the net-work topology than a routing protocol. We’re thus fortunate that all networks have both a forwarding and a routing function!

Values in arrivingpacket’s header

1

23

Local forwardingtable

header

0100011001111001

1101

3221

output

Control plane

Data plane

Routing algorithm

Figure 4.2 ♦ Routing algorithms determine values in forward tables

M04_KURO4140_07_SE_C04.indd 309 11/02/16 3:14 PM



Control plane and data plane ❒  Network devices have internal architectures divided

into two parts: ❍  Control plane ❍  Data plane

❒  Control plane: ❍  Management functionality (configuration, monitoring, …) ❍  Control functionality (routing protocols, MPLS label

distribution, RSVP, …) ❍  In software, slower speed, infrequent, possible human

interaction ❒  Data plane:

❍  Packet processing, at line rates ❍  Usually in hardware, highly optimized

9

2-17

Classical division into control and data planes

a. data plane passes control packets up to control plane

b. control plane loads new configuration into the hardware

c. data packets are switched in the data plane, unless errors occur (possibly leading to error reports via ‘a’)


Packets arrive

Packets leave

Data plane (hardware)

Control plane (software)

a b

c


Multiple control modules and one common interface

❒ 3 popular external interfaces: ❍  Command Line Interface

(CLI), accessed using ssh ❍  WEB interface, accessed

via a browser (HTTPS) ❍  SNMP agent, accessed by

SNMP management applications

❒  Each control module invokes the common interface to perform operations

❒  The internal interface is only accessible by the modules sold by the vendor

Packets arrive

Packets leave

Data plane (hardware)

Common interface (internal)

CLI WEB SNMP …

10

2-19

data plane

control plane

Logically centralized control plane A distinct (typically remote) controller interacts with local control

agents (CAs) in routers to compute forwarding tables

Remote Controller

CA

CA CA CA CA



SDN model: external controller ❒  SDN moves all control plane

functions out of each network element and places them in an external controller (typically a PC running Linux)

❒  Light SDN functionality in the node

❒  Communication between SDN controller and network element: OpenFlow protocol

❒  Applicable to classical embedded control functions such as routing ❍  Centralized routing! Packets

arrive Packets

leave Data plane (hardware)

Common interface (internal)

CLI WEB SNMP SDN

External controller

11

2-21

2.1 Motivation for a new approach 2.2 Data Plane and Control Plane division 2.3 Generalized Forwarding and SDN

❍ Match + Action ❍ OpenFlow examples of match-plus-action in action ❍ Classification engines in switches (TCAM) ❍ Extended forms of forwarding

2.4 The SDN control plane 2.5 The Economics of SDN

Chapter 2: outline


2-22

Generalized Forwarding and SDN

2 3 0100 1101

values in arriving packet’s header

logically-centralized routing controller

1

control plane

data plane

Each router contains a flow table that is computed and distributed by a logically centralized routing controller

local flow table headers counters actions

2. Software-Defined Networks ©From Computer Networking, by Kurose&Ross

12

2-23

SDN data plane abstraction ❒  flow: defined by header fields ❒  generalized forwarding: simple packet-handling rules

❍  Pattern: match values in packet header fields ❍  Actions: for matched packet: drop, forward, modify matched

packet, or send matched packet to controller ❍  Priority: disambiguate overlapping patterns ❍  Counters: #bytes and #packets

Flow table in a router (computed and distributed by controller) define router’s match+action rules


2-24

SDN data plane abstraction ❒  flow: defined by header fields ❒  generalized forwarding: simple packet-handling rules

❍  Pattern: match values in packet header fields ❍  Actions: for matched packet: drop, forward, modify matched

packet, or send matched packet to controller ❍  Priority: disambiguate overlapping patterns ❍  Counters: #bytes and #packets

1.  src=1.2.*.*,dest=3.4.5.*!drop2.  src=*.*.*.*,dest=3.4.*.*!forward(2)3. src=10.1.2.3,dest=*.*.*.*!sendtocontroller

* : wildcard

13

2-25

SDN: Flow Table Entries

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDPsport

TCP/UDPdport

Rule AcNon Stats

1.  Forwardpackettoport(s)2.  Encapsulateandforwardtocontroller

3.  Droppacket4.  Sendtonormalprocessingpipeline

5.  ModifyFields

Packet+bytecounters

Linklayer Networklayer Transportlayer


2-26

Destination-based forwarding:

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDPsport

TCP/UDPdport

AcNon

* * * * * 51.6.0.8 * * * port6

Examples

IP datagrams destined for IP address 51.6.0.8 should be forwarded to router output port 6

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDPsport

TCP/UDPdport AcNon

* * * * * * * * 22 drop

Firewall:

do not forward (block) all datagrams destined for port 22

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDPsport

TCP/UDPdport AcNon

* * * * 128.19.1.1 * * * * drop

do not forward (block) all datagrams sent by host 128.19.1.1 ©From Computer Networking, by Kurose&Ross 2. Software-Defined Networks

14

2-27

Destination-based layer 2 (switch) forwarding:

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCP/UDPsport

TCP/UDPdport AcNon

* * * * * * * * port3

Examples

layer 2 frames destined for MAC address 22:A7:23:11:E1:02 should be forwarded to output port 3

22:A7:23:11:E1:02


2-28

IP Src = 10.3.*.* IP Dst = 10.2.*.* forward(3)

match action

ingress port = 2 IP Dst = 10.2.0.3 ingress port = 2 IP Dst = 10.2.0.4

forward(3)

match action

forward(4)

ingress port = 1 IP Src = 10.3.*.* IP Dst = 10.2.*.*

forward(4)

match action

Network example

Host h1 10.1.0.1

Host h2 10.1.0.2

Host h4 10.2.0.4

Host h3 10.2.0.3

Host h5 10.3.0.5

s1 s2

s3 1 2

3 4

1

2

3 4

1

2 3

4

Host h6 10.3.0.6

controller

Example: datagrams from hosts h5 and h6

should be sent to h3 or h4, via s1 and from

there to s2


15


Classification engines in switches ❒  SDN designed with Ethernet/IP switches in mind ❒  The data plane in a high-end switch consists of a piece of

hardware known as the classification engine ❍  Which decides how to forward arriving packets ❍  Pattern-matching system ❍  Set of patterns with associated actions ❍  Patterns can contain “don’t care” for some bits in header

(headers of) packet to be matched

pattern 1

pattern 2

pattern N (default that matches any packet)

action 1

action 2

action N


TCAM and High-Speed Classification ❒  Hardware-based classifiers can perform the

comparisons in one step ❒  TCAM = Ternary Content Addressable Memory

❍  Content addressable: TCAM does not merely store values, but each memory cell contains logic that can perform bit-wise comparison

❍  Ternary: three values: 0, 1, don’t care ❒  When a packet has been placed in the TCAM hardware,

all the pattern matchers receive a copy of the bits of the packet and they all act at the same time : complexity O(1)

❒  A match returns the associated action (an integer index) ❒  If multiple matches, choose one, typically the lowest

position in the list (smallest integer)

16


Classification across multiple layers ❒  A single classification pattern can check items from

multiple layers of the protocol stack at the same time ❒  Useful to express policies on flows ❒  Example: web traffic

❍  Layer 2 header specifies: “Frame type field = IP” ❍  Layer 3 header specifies: “IP protocol field = TCP” ❍  Layer 4 header specifies: “Destination port = 80” ❍  Could also check that HTTP header is present, etc.

❒  Efficient: Avoids the demultiplexing used in conventional protocol stacks

❒  However, options in headers make things complex ❍  Multiple patterns are needed to accommodate combinations

of options


Items OpenFlow can specify ❒  When an external controller sends an OpenFlow message with

values for specific fields, a switch creates a classification pattern

❒  Examples of layer 2 fields: ❍  Ingress port ❍  Source and destination MAC addresses ❍  Frame type ❍  VLAN id and priority ❍  ARP opcode

❒  Examples of layer 3 (+ layer 2.5) fields: ❍  IPv4 and IPv6 source and destination addresses, possibly prefixes ❍  IPv4 protocol type ❍  IPv6 next header ❍  IPv4 and IPv6 TOS byte ❍  MPLS label and 3-bit traffic class

❒  Examples of layer 4 fields: ❍  TCP/UDP/… source and destination port numbers ❍  ICMP type and code

17


Traditional and Extended IP forwarding

❒ OpenFlow can configure all the forms of IP forwarding, including multicast and broadcast

❒ Thanks to “don’t care” bits, a default route can also be specified

❒  But OpenFlow also allows new forms of forwarding ❍  based on source addresses ❍  based on layer-4 fields

❒  Comparable to MPLS traffic engineering capabilities


Other capabilities SDN/OpenFlow can offer

❒  OpenFlow can be used to create MPLS paths dynamically, and use classifiers to assign IP packets to MPLS paths (also adding label) at ingress (and remove it at egress)

❒  Knowing that IPv4 and IPv6 addresses may change over time, it is weak to define security policies based on source addresses ❍  Instead, using source MAC addresses is more robust ❍  This also ensures that IPv4 and IPv6 forwarding are

consistent ❍  VLAN ids may also be used

18

2-35

OpenFlow abstraction

❒  Router • match: longest

destination IP prefix

•  action: forward out a link

❒  Switch • match: destination

MAC address •  action: forward or

flood or drop

❒  Firewall • match: IP addresses

and TCP/UDP port numbers

•  action: permit or deny

❒  NAT • match: IP address

and port •  action: rewrite

address and port

match+action: unifies different kinds of devices


2-36

Data plane


A pipeline model for flow tables

❒  In addition to hardware-based classification mechanisms, OpenFlow includes functions that can be used with software-based classification

❒  This adds significant functionality ❒  Example: a pipeline of flow tables

❍  Each flow table specifies a set of classification rules and actions for each rule, e.g., •  IP datagram encapsulation in MPLS or in another outer IP datagram •  Extracting an inner packet from a previous encapsulation •  Packet inspection, packet encryption, etc.

❍  Once a packet has been processed by a flow table, it can be forwarded or passed to the next flow table in the pipeline

❒  OpenFlow also arranges to pass Metadata along with each packet ❍  This makes it possible for an early stage to gather data from a packet, look up information,

and pass the information to successive stages ❍  E.g., the 1st stage chooses a next hop for the packet, the 2nd stage can encrypt the packet,

and the 3rd stage can forward the encrypted packet to the next hop without decrypting a copy to compute the next-hop address

Flow table 1 Flow table 2 Flow table 3

packets arrive

packets leave

19

2-37

2.1 Motivation for a new approach 2.2 Data Plane and Control Plane division 2.3 Generalized Forwarding and SDN 2.4 The SDN control plane

❍ SDN Controller and SDN Control Applications ❍ OpenFlow Protocol ❍ Data and Control Plane Interaction: An example ❍ SDN: Past and Future

2.5 The Economics of SDN

Chapter 2: outline


2-38


Why a logically centralized control plane? ❒  easier network management: avoid router

misconfigurations, greater flexibility of traffic flows

❒  table-based forwarding allows “programming” routers o  centralized “programming” is easier: compute tables

centrally and distribute o  distributed “programming” is more difficult: compute

tables as result of distributed algorithm (protocol) implemented in each and every router

❒  open (non proprietary) implementation of control plane


20

2-39

Vertically integrated Closed, proprietary

Slow innovation Small industry

Specialized Operating System

Specialized Hardware

App

App

App

App

App

App

App

App

App

App

AppSpecialized Applications

Horizontal Open interfaces Rapid innovation Huge industry

Microprocessor

Open Interface

LinuxMacOS

Windows(OS) or or

Open Interface

Analogy: mainframe to PC evolution

© N. McKeown 2: Software-Defined Networks

2-40


data plane

control plane

Remote Controller

CA

CA CA CA CA

1: generalized “flow-based” forwarding

(e.g., OpenFlow)

2. control, data plane separation

3. control plane functions

external to data-plane

switches

… 4. programmable control

applications routing access

control load

balance


21

2-41

SDN perspective: data plane switches

Data plane switches ❒  fast, simple, commodity switches

implementing generalized data-plane forwarding in hardware

❒  switch flow table computed, installed by controller

❒  API for table-based switch control (e.g., OpenFlow) ❍  defines what is controllable and

what is not ❒  protocol for communicating with

controller (e.g., OpenFlow) data plane

control plane

SDN Controller (network operating system)

… routing

access control

load balance

southbound API

northbound API

SDN-controlled switches

network-control applications


2-42

SDN perspective: SDN controller

SDN controller (network OS): "  maintain network state

information "  interacts with network control

applications “above” via northbound API

"  interacts with network switches “below” via southbound API

"  implemented as distributed system for performance, scalability, fault-tolerance, robustness

data plane

control plane


… routing

access control

load balance

southbound API

northbound API




22

2-43

SDN perspective: control applications

network-control apps: "  “brains” of control:

implement control functions using lower-level services, API provided by SDN controller

"  unbundled: can be provided by 3rd party: distinct from routing vendor, or SDN controller

data plane

control plane


… routing access control

load balance

southbound API

northbound API




2-44

Network-wide distributed, robust state management

Communication to/from controlled devices

Link-state info switch info host info

statistics flow tables …

… OpenFlow SNMP …

network graph intent

RESTful API …

Interface, abstractions for network control apps

SDN controller

routing access control

load balance

Components of SDN controller

Communication layer: communicate

between SDN controller and

controlled switches

Network-wide state management layer: state of network links, switches,

services: a distributed

database

Interface layer to network control

apps: abstractions API


23

2-45

OpenFlow protocol ❒  operates between controller,

switch ❒  the only SDN protocol with wide

acceptance in the industry ❒  initiated at Stanford, now

controlled by the Open Network Foundation

❒  TCP used to exchange messages ❍  optional encryption

❒  three classes of OpenFlow messages: ❍  controller-to-switch ❍  asynchronous (switch to

controller) ❍  symmetric (misc)

OpenFlow Controller


2-46

OpenFlow: controller-to-switch messages

Key controller-to-switch messages ❒  features: controller queries

switch features, switch replies ❒  configure: controller queries/

sets switch configuration parameters

❒  modify-state: add, delete, modify flow entries in the OpenFlow tables

❒  packet-out: controller can send this packet out of specific switch port

OpenFlow Controller


24

2-47

OpenFlow: switch-to-controller messages

Key switch-to-controller messages ❒  packet-in: transfer packet (and its

control) to controller. See packet-out message from controller

❒  flow-removed: flow table entry deleted at switch

❒  port status: inform controller of a change on a port

Fortunately, network operators don’t “program” switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction at controller

OpenFlow Controller



Dynamic rule creation and control of flows

❒  OpenFlow allows a controller to install or remove classification rules dynamically

❒  More important, new rules can be created when packets arrive ❒  If the default rule redirects the packets (matching no existing

rules) to the SDN controller, the software on the controller can ❍  decide how the packet should be processed ❍  install a new rule in the switch (and possibly in other switches) ❍  forward the packet back to the switch for processing

❒  Subsequent packets from the same “flow” will benefit from the new rule ❍  Per-flow routing system

❍  E.g., load balancing of new TCP connections over multiple paths depending on the current load of the paths (known by the controller)

25

2-49



…

OpenFlow SNMP …


RESTful API

…

1

2

3

4

6

5

Dijkstra’s link-state Routing

s1 s2

s3 s4

SDN: control/data plane interaction example

S1, experiencing link failure using OpenFlow port status message to

notify controller

1

SDN controller receives OpenFlow message,

updates link status info

2

Dijkstra’s routing algorithm application has previously registered to be called whenever link status changes. It is

called.

3

Dijkstra’s routing algorithm accesses

network graph info, link state info in controller,

computes new routes

4


2-50



…

OpenFlow SNMP …


RESTful API

…

1

2

3

4

6

5

Dijkstra’s link-state Routing

s1 s2

s3 s4

SDN: control/data plane interaction example

Link state routing app interacts with flow-table-computation component in SDN controller, which

computes new flow tables needed

5

Controller uses OpenFlow to install new tables in switches that

need updating

6


26

2-51

topology manager

Basic Network Service Functions

REST API

OpenFlow 1.0 … SNMP OVSDB

forwarding manager

switch manager

host manager

stats manager

Network service apps

Service Abstraction Layer (SAL)

Access Control

Traffic Engineering

…

OpenDaylight (ODL) controller

"  ODL Lithium controller

"  Network apps may be contained within, or be external to SDN controller

"  Service Abstraction Layer (SAL): interconnects internal, external applications and services


2-52

Network control apps

…

REST API

ONOS distributed

core

southbound abstractions,

protocols OpenFlow Netconf OVSDB

device link host flow packet

northbound abstractions,

protocols Intent

statistics devices

hosts

links

paths flow rules topology

ONOS controller

"  Control apps separate from controller

"  Intent framework: high-level specification of service: “what” rather than “how”

"  Considerable emphasis on distributed core: service reliability, replication performance scaling


27

2-53

SDN: selected challenges ❒  hardening the control plane: dependable,

reliable, performance-scalable, secure distributed system ❍  robustness to failures: leverage strong theory

of reliable distributed system for control plane ❍  dependability, security: “baked in” from day

one? ❒  networks, protocols meeting mission-

specific requirements ❍  e.g., real-time, ultra-reliable, ultra-secure

❒  Internet-scaling 2: Software-Defined Networks ©From Computer Networking, by Kurose&Ross

2-54


Chapter 2: outline


28


Shared controllers ❒  A controller has enough processing power to handle

multiple network elements ❍  Most network management applications are not CPU

intensive ❍  Multiple physical copies of a given device may easily be

configured or controlled by a single controller (e.g., a set of wireless APs)

❍  Sharing controllers is cost-effective! ❒  How many controllers in a network?

❍  Depends on many factors: •  Size of network •  Variety of network elements •  Replication factor of each network element •  Variety and load of management applications •  Physical clustering of equipments


SDN domain

❒  Arrangement of SDN controllers in a large intranet ❒  Controllers communicate to ensure consistency of

policies and of configurations ❒  C-to-C and C-to-E protocols must be standardized

❍  Application layer protocols (as in SNMP) over TCP/IP ❍  Management traffic over the managed network (as in SNMP)

Controller 1 Controller 3 Controller 2

SDN domain 1 SDN domain 3 SDN domain 2

Controller to controller Controller to controller

Controller to element Controller to element

29


SDN’s potential effect on network vendors ❒  In a broad sense, SDN removes control plane functionality from the

underlying network elements, leaving only a data plane technology ❒  But vendors used control plane functionality to differentiate their

equipment from competitors’ equipment ❍  Leading to homogeneous, easier to manage networks

❒  With SDN, no more motivation to purchase all the equipment from a single vendor

❒  Data plane hardware will become a commodity, only price and performance will matter

❒  Vendors accustomed to continual demand and high profit margins may find it difficult to compete in a commodity market

❒  SDN has the potential to undercut profits of current network vendors

❒  A new industry can arise to build and sell vendor-independent network management software

❒  Adoption of SDN will likely mean a move away from the current scheme of proprietary management software and vertical integration


SDN: summary ❒  Control plane removed from network elements and

placed in separate controllers ❒  One part of the SDN paradigm has been defined:

OpenFlow protocol ❒  Based on (pipelines of) flow tables ❒  TCAM-based packet matching ❒  New forms of forwarding possible ❒  Per-flow routing possible ❒  Potential changes in the networking industry

30


Chapter 2 – Appendix on VLANs

❒  Switches have been extended by adding virtualization (VLAN switch)

❒  A VLAN switch emulates multiple, independent switches

❒  We will review ❍  The motivation for VLANs ❍  Their technology ❍  VLANs spanning multiple physical switches ❍  The need for an extra field in the frame (VLAN tag)


VLANs: motivation

Consider: ❒  CS user moves office to EE,

but wants to connect to CS switch?

❒  single broadcast domain: ❍  all layer-2 broadcast traffic

(ARP, DHCP, unknown location of destination MAC address) must cross entire LAN

❍  security/privacy, efficiency issues

❒  each lowest level switch may have only few ports in use

Computer Science Electrical

Engineering Computer Engineering

31


VLANs Port-based VLAN: switch ports grouped (by switch management software) so that single physical switch …

Switch(es) supporting VLAN capabilities can be configured to define multiple virtual LANs over single physical LAN infrastructure

Virtual Local Area Network

1

8

9

16 10 2

7

…

Electrical Engineering (VLAN ports 1-8)

Computer Science (VLAN ports 9-15)

15

…


…

1

8 2

7 9

16 10

15

…


… operates as multiple virtual switches


Port-based VLAN

1

8

9

16 10 2

7

…



15

…

❒  traffic isolation: frames to/from ports 1-8 can only reach ports 1-8 ❍  can also define VLAN based on

MAC addresses of endpoints, rather than switch port

❒  dynamic membership: ports can be dynamically assigned among VLANs

router

❒  forwarding between VLANs: done via routing (just as with separate switches) ❍  in practice vendors sell combined

switches plus routers

32


VLANs spanning multiple switches

❒  trunk port: carries frames between VLANs defined over multiple physical switches ❍  frames forwarded within VLAN between switches can’t be

vanilla 802.1 frames (must carry VLAN ID info) ❍  802.1q protocol adds/removes additional header fields for

frames forwarded between trunk ports

1

8

9

10 2

7

…



15

…

2

7 3

Ports 2,3,5 belong to EE VLAN Ports 4,6,7,8 belong to CS VLAN

5

4 6 8 16

1


Type

2-byte Tag Protocol Identifier (value: 81-00)

Tag Control Information (12 bit VLAN ID field, 3 bit priority field like IP TOS)

Recomputed CRC

802.1Q VLAN frame format

802.1 frame

802.1Q frame

•  When the field following the 2 addresses is 0x8100 (> 1500), it’s a 802.1Q frame

•  3-bit priority field has nothing to do with VLANs, it’s used for QoS

•  When a frame has no tag on a trunk line, there is a default VLAN id which the frame is considered to be associated with

•  Tags can be stacked

Documents

Managing and Securing Computer Networks Guy Leduc Chapter 2