Switching and Routing 2012-2013

projects description

Outline

•  Introduction to OpenFlow •  A case study •  The projects •  Additional information

What’s OpenFlow

•  An open standard, which defines: •  An abstraction of ethernet switches’ forwarding

plane, by means of flow tables description •  A protocol for interfacing with an external controller,

to add/remove flow entries and get statistics

•  A first step toward Software Defined Networking (SDN): abstraction of networks’ control plane

•  Development started at Stanford University, transferred to Open Networking Foundation (ONF) in March 2011

OpenFlow switching Controller

OpenFlow Ethernet Switch

Flow Table

Secure Channel

PC

hw

sw

OpenFlow Switch specification

•  Add/delete flow entries •  Encapsulated packets •  Controller discovery

N. McKeown, OpenFlow (Or: “Why can’t I innovate in my wiring closet?”), http://www.openflow.org/documents/OpenFlow.ppt

Forwarding Plane Abstraction Flow table entries

Switch  Port  

MAC  src  

MAC  dst  

Eth  type  

VLAN  ID  

IP  Src  

IP  Dst  

IP  Prot  

TCP  sport  

TCP  dport  

Rule   Ac=on   Stats  

1.  Forward  packet  to  port(s)  2.  Encapsulate  and  forward  to  controller  3.  Drop  packet  4.  Send  to  normal  processing  pipeline  5.  Modify  Fields  

+  mask  what  fields  to  match  

Packet  +  byte  counters  

OpenFlow protocol Support three message types: •  Controller-to-switch messages

•  Configuring the switch •  Exchanging switch capabilities •  Managing the Flow table

•  Symmetric messages •  Send in either direction •  Diagnose problems in switch controller connection

•  Asynchronous messages •  From switch to the controller •  Announce change in network state, switch state etc.

OpenFlow controller

Openflow controller is a centralized entity for the entire OpenFlow network

•  NOX is an (one of many) open source OpenFlow controller •  simplified platform for writing network control

software in C++/Python

M. Meulle, W. Daar, Introduction to OpenFlow, CORE-TPN-RIV, 23 Jul. 2010

OpenFlow for SR Projects: You will be mainly asked to: •  Program the behavior of very simple networks

•  Only the controller must be programmed •  The switch is given, and fixed

•  Work on software-emulated networks •  Hosts, Switches, controllers are all virtualized on

your PC •  Two emulation softwares: Mininet and Netkit

•  Perform acceptance tests (optionally performance tests) •  iperf, hping(3), wireshark, others…

Recommended references •  Open Networking Foundation: (new official site)

http://www.opennetworking.org/ •  OpenFlow official site: (old site, but has interesting material)

http://www.openflow.org/

•  OpenFlow white paper: (very introductive primer) http://www.openflow.org/documents/openflow-wp-latest.pdf

•  OpenFlow Tutorial with Mininet: (we suggest this to start learning OpenFlow) http://www.openflow.org/wk/index.php/OpenFlow_Tutorial

•  OpenFlow 1.0.0 technical specification: (you must refer to this version) http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf

•  Nox official site: (to write your OpenFlow controller software in C++) http://www.noxrepo.org/nox/about-nox/

•  Mininet official site: (a software to emulate a network in your PC) http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet

•  Netkit official site: (another software to emulate a network in your PC) http://wiki.netkit.org/

Outline

•  Introduction to OpenFlow •  A case study •  The projects •  Additional information

(Hybrid) Wireless-Optical Broadband Access Network (WOBAN)

MET

RO

/CO

RE

NET

WO

RK

OLT

Why WOBAN?

Gateway

OLT Gateway

ONU

ONU

Potential advantages over existing access networks: - Cost effectiveness (less deployment and maintainance costs) - Broadband access - Ubiquitous access (because of wireless front-end) - Redundant routes offered by wireless front-end - Redundant capacity offered by optical backhaul Energy saving?

How to pursue energy saving?

Gateway

OLT Gateway

ONU

ONU

When the traffic load is low, put some ONU (and corresponding Gateway) nodes in “sleep” state, i.e. they switch off their transceivers and enter a low power consumption state

Sleeping nodes become unreachable by the rest of the network, BUT full connectivity is still guaranteed, provided that: - Wireless mesh re-routes upstream traffic to active gateways - OLT re-routes downstream traffic to active ONUs

Simplified WOBAN case study

OLT

Gateway 1

ONU 1

Router 1 User 1

Gateway 2

ONU 2

Router 2 User 2

Gateway 1

Assumptions: - 2 bidirectional traffic flows (User 1 ↔ OLT; User 2 ↔ OLT) - Users cannot associate directly to Gateways - Static association between Users and their access Routers (no handovers) - Each ONU connects to exactly one Gateway - Ad-hoc dynamic routing for wireless mesh part - Static routing in the wired part

Equivalent test-bed

OLT

Gateway 1

ONU 1

Router 1 User 1

Gateway 2

ONU 2

Router 2 User 2

PC + WiFi card

Gateway 1

PC + WiFi card

PC + WiFi +Ethernet card

PC + WiFi +Ethernet card

PC + Ethernet card

- WiFi (IEEE 802.11g/n) in ad-hoc mode for wireless mesh part - Ethernet for wired part - Emulation of nodes by means of PCs with Linux OS

Outline

•  Introduction to OpenFlow •  A case study •  The projects •  Additional information

Projects 12-1 & 12-2 – Test case

OLT

Gateway 1

ONU 1

Router 1 User 1

Gateway 2

ONU 2

Router 2 User 2

PC + WiFi card

Gateway 1

PC + WiFi card

PC + WiFi +Ethernet card

PC + WiFi +Ethernet card

PC + Ethernet card

- Traffic flows between each user and the OLT - ONU 2 and Gateway 2 enter “sleep” state → WiFi and Eth cards are disabled - Have traffic flows been properly re-routed?

Project 12-1: Test-bed in OpenFlow

1.  Implement the test-bed in an emulated network scenario: •  Network emulation via Mininet •  OpenFlow control (controller resides in the OLT) •  Proactive routing tables

2.  Once the test-bed is ready, let ONU 2 and Gateway 2 enter into “sleep” state and verify that re-routing is effective

3.  Perform tests: iperf, hping(3), video (optionally) 4.  Replicate scenario and tests in a real network @

Bonsai Lab

Project 12-2: Test-bed with Ad-hoc Routing

1.  Implement the test-bed in an emulated network scenario: •  Network emulation via Netkit •  Ad-hoc routing protocol (OLSR or AODV) in the

wireless mesh part, static in the wired part

2.  Once the test-bed is ready, let ONU 2 and Gateway 2 enter into “sleep” state and verify that re-routing is effective

3.  Perform tests: iperf, hping(3), video (optionally) 4.  Replicate scenario and tests in a real network @

Bonsai Lab

Project 12-3: Traffic Policing

1.  Measure the traffic amount (every T seconds) for each input flow in an OpenFlow controlled switch;

2.  Perform a simple traffic policing over each input flow, i.e.: •  if current traffic amount is lower than a threshold,

then forward the packet; •  otherwise drop the packet

3.  Perform tests: iperf, hping(3) 4.  Replicate scenario and tests in a real network

@ Bonsai Lab

Project 12-4: Traffic Re-routing

1.  Set up an OpenFlow controlled network composed by 5 elements

•  Same topology of the test-bed, all-wired •  Controller installed in the OLT

2.  Change the routing of user data traffic and verify it

•  Reactive update of routing tables •  Switch-Controller traffic should not be re-routed

3.  Perform tests: iperf, hping(3) 4.  Replicate scenario and tests in a real network

@ Bonsai Lab

Project 12-5: VLAN Implementation 1.  Implement a VLAN (IEEE 802.1Q) switch with

OpenFlow •  The switch ports are divided into port groups each

belonging to a single VLAN •  Configure a port as trunk port, over which all

tagged frames are sent and received

2.  Properly manage both incoming and outgoing tagged frames

3.  Perform tests: iperf, hping(3) (e.g. consider 2 switches connected by a single trunk link)

4.  Replicate scenario and tests in a real network @ Bonsai Lab

The CCNx project (www.ccnx.org) is defining a novel way of addressing Internet contents, which is based on the request of contents names, instead of server addresses.

The proposed project consists in: Set-up and testing a CCNx implementation in an

experimental network (at first an emulated network, then a real network @ Bonsai lab)

Performance measurements (end-to-end delay), for increasing number of nodes of a simple application

Project 12-6: Setup and Performance of a Content-Centric Network

Project 12-7: Elastic-rate Flexi-grid Core networks

1. Scenario •  Event-driven dynamic-

traffic simulator •  Core mesh network •  Flexible grid (no WDM)

2. Target(s) •  Insert multi-criteria resource

allocation (now only first-fit spectrum allocation)

•  different traffic distribution (e.g., bursty traffic)

f

WDM

100 Gbit/s txp à 50 GHz (including g.b.)

occupied (but unused!)

60 Gbit/s

f

Elastic Rate Flexi-grid

Adaptive-rate txp à 40 GHz (30+10 g.b.)

6 minigrids (5GHz each)

Project 12-8: Optical Metro rings with Flexi-grid

1.  Scenario •  Event-driven dynamic-traffic

simulator •  Optical metro ring •  Flexible grid (no WDM) •  Multi-criteria Routing and

Spectrum Allocation (RSA) 2.  Target(s) •  Insert different traffic

distribution (e.g., bursty traffic) •  Parametrization of the

simulator (nr of nodes/links, wavelengths, transponders used…)

Project 12-9: Lambda-switched shuffle-exchange

YZ

AWG Wavelength converter

Linecard

Multistage implementation

Folded implementation

Project 12-9: Lambda-switched shuffle-exchange

1.  Scenario •  Clock-driven frame-traffic simulator

•  (upgrading an existing simulation tool) •  Board-to-board interconnection •  Shuffle-exchange routing algortithms

2.  Target(s) •  Power consumption / delay measurements •  Multistage vs. folded implementation comparison

Additional information Final outcome of the projects: 1.  Write a report 2.  Create the project documentation (commented

code, etc.) 3.  Prepare a presentation We will organize a final project day in the Bonsai Lab to enjoy your presentations J Contacts:

Nicola Carapellese (tutor): carapellese@elet.polimi.it