[PPT] - Understanding OpenDaylight VTN and the Redirection Function PowerPoint Presentation

SLIDE 1

Understanding OpenDaylight VTN and the Redirection Function

Shreyansh Jain NEC Technologies India Pvt. Ltd. shreyansh.jain@{nectechnologies.in, gmail.com}

SLIDE 2

Next 45 Minutes …

A brief introduction to OpenDaylight VTN
OpenDaylight Platform: VTN Project Overview
Understanding VTN: Definition, Virtual Nodes and

2

SLIDE 3

Understanding OpenDaylight VTN Project

3

SLIDE 4

OpenDaylight Platform: VTN Project Overview

VTN Project constitutes of VTN Coordinator and VTN Manager plugins

4

Image from: http://www.opendaylight.org/project/technical-overview

VTN Coordinator is responsible for interfacing between multiple controller environment, and providing RESTful APIs for Northbound Applications VTN Manager is available as AD- SAL bundle for OpenDaylight

Controller. Responsible for:
OpenFlow PACKET_IN and

PACKET_OUT handling

Providing RESTful API for

basic VTN Semantics

Setting Flow Entries on

OpenFlow Switches (FLOW_MOD)

SLIDE 5

OpenDaylight Platform: VTN Project Overview

Deploying VTN across multiple Controller (DC) environment

5

Image from: http://www.opendaylight.org/project/technical-overview

Northbound Applications

RESTful APIs Coordination RESTful APIs <<Java API>> <<Java API>> Coordination

SLIDE 6

Understanding VTN: Definition

VTN or Virtual Tenant Network
Abstracting the physical network to create multiple Logical Networks layered over

same physical plane

User would define a L2/L3 network without worrying about the physical topology
VTN Manager Plugin detects the topology, maps the logical representations and installs

necessary flows on network elements (OpenFlow Switches – OFS)

6 VLAN100 VLAN200 VLAN300 VLAN100 VLAN100 VLAN200

Physical Network

V V V

Virtual Network

V

V V vRouter vBridge Virtual Interface OpenFlow Switch

SLIDE 7

Understanding VTN Topology: Virtual Nodes

Various nodes used for defining a network
vBridge
Works like a Layer 2 Switching element, with support for MAC learning
Unknown MAC destination are flooded to all interfaces (except incoming interface)
Pair of source MAC and incoming interfaces are learned and aged out
Also used for specifying a mapping with the physical layer (VLAN Mapping)
vRouter (Implemented by VTN Coordinator APIs)
Works like a Layer 3 Routing element (Without advanced features like OSPF, BGP)
Table of discovered hosts is maintained based on ARP requests and responses
Forwarded packet modification is performed based on dynamic or static routes
Virtual Interfaces
Represents a port on a vBridge or vRouter (L2 or L3) virtual device
Also used for specifying a mapping with the physical layer (Port Mapping)
This mapping is used by VTN to define flow actions to be performed for an incoming frame
vLink
A logical representation of connections between various network elements
A VTN is like a single large switch encompassing all OpenFlow enabled ports on

the underlying physical network

7 Some other semantics also exist; vTerminal, vTep, vTunnel, vBypass – designed for defining networks linking multiple controlled domains (network stretching across multiple DCs)

SLIDE 8

Understanding VTN Topology: Network Creation

Creating a network by connecting together the virtual nodes:
A VTN can have many L2 devices (vBridge) and one L3 device (vRouter)
Multiple vBridge can exists in a VTN, with or without inter-connections
Two vBridge cannot connect to each other directly. For interlinking, a vRouter is used
Virtual Interfaces are used for:
Connecting vBridge and vRouter
Until vLink between two nodes is created, they remain disconnected on physical plane
Mapping with Physical network
Flow-filters (traffic segregation) and functions like Redirection are applied on these

8

Defining VTN Semantics for one

r more Virtual

Networks Creating a Physical Topology; One in which one

r more edge-to-edge path

exist Linking together the Virtual and Physical network using mapping functions

Physical network having multiple paths would allow VTN to reroute traffic in case of link failures Define multiple VTNs for all unrelated logical networks Mapping, represented by flow entries, provides entry/exit point for traffic on virtual network

SLIDE 9

Physical  Virtual Mapping for a VTN

Eventually, a VTN needs to be linked to the physical network
This work is done by specifying a map with physical layer
Each incoming packet is mapped to one of the defined VTNs, or dropped in case of no

match

Mapping defines relation between Virtual and Physical network elements
Port Mapping
Linking a physical port (or vif of an OVS) of a particular OpenFlow Switch (OFS) to a vBridge
Can map a tagged (of a specified VLAN) or an untagged packet arriving on that port
Configured on a virtual interface associated with a vBridge
VLAN Mapping
Mapping the particular VLAN slice over all OFS on the physical plane
OR, reducing the scope by specifying a VLAN over a particular OFS
MAC Mapping
Supported from Helium onwards [1]; Creating a White-list of allowed MAC address for

untagged frames, for a particular vBridge

<Not much information available in Wiki, though source code seems to have this implemented

“manager/../MacMap.java and MacMapConfig.java”> 9

[1] From: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:Helium_Release_Notes

SLIDE 10

Dynamic Network Topology creation

VTN Manager forms a physical view of all connected OFSs using LLDP
LLDP Packets are pushed out of OFSs port and their reception is noted for forming a

physical plane graph

Once created, the graph is actively updated for learning new or failed paths
Flows are created based on this acquired topology

10

Image from Slide 23 of ODL-MiniSummit-Virt-Final_20150224.pdf from https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf extracted on 24/Feb/2015

SLIDE 11

Handling a new Packet

Incoming packets are mapped to appropriate VTN based on mapping
Once mapped to a VTN, L2 functions of flooding across virtual interfaces is performed

if ARP hasn’t yet been learned

Once ARP is learned, flow entries are pushed on the edge ports; Core flows are created
r updated based on the topology detected
ARP table is passively updated based on flow entry timeout or new ARP broadcasts

11

Image from Slide 24 of ODL-MiniSummit-Virt-Final_20150224.pdf from https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf extracted on 24/Feb/2015

SLIDE 12

Using VTN Manager REST APIs

Creating a VTN named BLUE
RESTful and Java APIs have been exposed by the bundles [2][3]
For both, VTN Manager and VTN Coordinator, JSON and XML are supported data format
Creating VTN Configuration(s) using VTN Manager RESTful APIs

12 POST /controller/nb/v2/vtn/default/vtns/BLUE

JSON: {"description": “BLUE Colored Virtual Network", "idleTimeout": "0","hardTimeout":

"0"}

Name of the new VTN

Creating a VTN

[2] VTN Manager REST APIs: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Manager:RestApi [3] VTN Manager Java APIs: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Manager:JavaApi

Virtual Network

SLIDE 13

Using VTN Manager REST APIs

Creating another VTN named GREEN
Multiple VTNs can be created, each being functionally isolated from the other

13 POST /controller/nb/v2/vtn/default/vtns/GREEN

JSON: {"description": “GREEN Colored Virtual Network”, "idleTimeout": "0","hardTimeout":

"0"}

Name of the new VTN

Creating another VTN Virtual Networks

SLIDE 14

Using VTN Manager REST APIs

Adding a vBridge Br100 to the VTN BLUE
Multiple vBridge per VTN can be created, each representing a single broadcast domain

14 POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100

JSON: {"description": “vBridge for VLAN 100", "ageInterval": "600"}

Virtual Networks

Name of the new vBridge for VLAN 100

V

Br100

A vBridge on a VTN

SLIDE 15

Using VTN Manager REST APIs

Adding Interfaces to the vBridge Br100 on BLUE
Multiple virtual interfaces per vBridge can be created; Each is equivalent to a port on a

L2 switch

15 POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100/interfaces/IF1

JSON: {"description": “A Yellow Dot on Br100","enabled": true}

An Interface on vBridge Br100 Virtual Networks

V

Br100 IF1

SLIDE 16

Using VTN Manager REST APIs

Adding another Interfaces to the vBridge Br100 on BLUE
Multiple virtual interfaces per vBridge can be created; Each is equivalent to a port on a

L2 switch

16 POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100/interfaces/IF2

JSON: {"description": “Another Yellow Dot on Br100","enabled": true}

Another Interface on vBridge Br100 Virtual Networks

V

Br100 IF1 IF2

SLIDE 17

Using VTN Manager REST APIs

More such virtual nodes are created to give shape to a bigger Logical Network
Each virtual node created, until mapped, is only a logical existence with no frames

being received or sent

17 POST /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br300

JSON: {"description": “vBridge for VLAN 300 on GREEN", "ageInterval": "600"}

Virtual Networks

V

Br100 IF1 IF2

POST /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br300/interfaces/IF1

JSON: {"description": “An interface on Br300","enabled": true}

V

Br300 IF1

SLIDE 18

Using VTN Manager REST APIs

More such virtual nodes are created to give shape to a bigger Logical Network
Each virtual node created, until mapped, is only a logical existence with no frames

being received or sent

18 POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br200

JSON: {"description": “vBridge for VLAN 200 on BLUE", "ageInterval": "600"}

Virtual Networks

V

Br100 IF1 IF2

POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br200/interfaces/IF1

JSON: {"description": “More ports for BLUE", "enabled": true}

V

Br300 IF1

V

Br200 IF1

SLIDE 19

VLAN 200

Using VTN Manager REST APIs

Creating a VLAN Map for VTN BLUE
A VLAN Map spans the specified VLAN broadcast domain on the underlying physical

plane, until reduced in scope by specifying a particular switch

19 POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br200/vlanmaps

JSON: {

"vlan": “200", "node": {"type": "OF", "id": "00:00:00:00:00:00:00:02"} }

Virtual Networks

V

Br100 IF1 IF2

V

Br300 IF1

V

Br200 IF1 Some internal interface

Adding a VLAN Map to the Br200 of BLUE VLAN Map doesn’t require an interface on vBridge. For any physical plane node on which packet with specified VLAN comes, an internal interface would be created.

Only packets with VLAN 200 on this device would be considered part of this vBridge

00:00:00:00:00:00:00:02

SLIDE 20

Using VTN Manager REST APIs

Creating a Port Map for VTN BLUE
Mapping a Port of a Switch on the Physical Plane, with a optional VLAN ID, to a vBridge

20 PUT /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100/interface/IF1/portmap

JSON: {

"vlan": 100, "node": {"type": "OF", "id": "00:00:00:00:00:00:00:01"}, "port": {"type": "OF", "id": "2", "name": "s1-eth2"} }

Virtual Networks

V

Br100 IF1 IF2

V

Br300 IF1

V

Br200 IF1 Some internal interface

Adding a PORT Map to the Br100 of BLUE

VLAN 200

Specifying the Switch and its port

Port Map is to a specific port of a specific switch of the physical plane. Unlike VLAN Map, it requires an interface in vBridge to map onto.

00:00:00:00:00:00:00:01

SLIDE 21

Using VTN Manager REST APIs

More Port Mappings

21 PUT /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br300/interface/IF1/portmap

JSON: {

"vlan": 300, "node": {"type": "OF", "id": "00:00:00:00:00:00:00:01"}, "port": {"type": "OF", "id": "2", "name": "s1-eth1"} }

Virtual Networks

V

Br100 IF1 IF2

V

Br300 IF1

V

Br200 IF1 Some internal interface

VLAN 200

00:00:00:00:00:00:00:01 00:00:00:00:00:00:00:02

SLIDE 22

Using VTN Manager REST APIs

Another VLAN Mapping

22 PUT /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br300/vlanmaps

JSON: {

"vlan": 300, "node": {"type": "OF", "id": "00:00:00:00:00:00:00:02"}, }

Virtual Networks

V

Br100 IF1 IF2

V

Br300 IF1 Some internal interface

V

Br200 IF1 Some internal interface

VLAN 200

00:00:00:00:00:00:00:01 00:00:00:00:00:00:00:02

VLAN 300

SLIDE 23

Using VTN Manager REST APIs

Using GET and DELETE, retrieval and deletion of nodes can be done
For Getting information about VLAN maps on vBridge on VTN GREEN

23 GET /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/vlanmaps

Response JSON: {

"vlanmap": [ { "id": "OF-00:00:00:00:00:00:00:03.0", "vlan": "0", "node": { "type": "OF", "id": "00:00:00:00:00:00:00:03“ } }, ... # More vlanmap configuration for this bridge ] } DELETE /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/OF-00:00:00:00:00:00:00:03.0

For deleting a mapping, using the ID from the above GET call:

SLIDE 24

Using VTN Manager REST APIs

Using GET and DELETE, retrieval and deletion of nodes can be done
For Getting information about portmap on an interface of a vBridge on VTN GREEN

24 GET /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br100/interfaces/IF1/portmap

Response JSON: {

"vlanmap": [ { "id": "OF-00:00:00:00:00:00:00:03.0", "vlan": "0", "node": { "type": "OF", "id": "00:00:00:00:00:00:00:03“ } }, ... # More vlanmap configuration for this bridge ] } DELETE /controller/nb/v2/vtn/default/vtns/GREEN/vbridges/Br100/interfaces/IF1/portmap

For deleting a portmap:
As there can be only a single Portmap for an interface, it is an overwrite operation

(PUT) or delete operation without arguments

SLIDE 25

Using VTN Coordinator APIs

Much larger set of nodes are available with VTN Coordinator
VTN Coordinator is for coordinating on multi-site deployment of ODL

25

Image from https://wiki.opendaylight.org/view/Release/Helium/VTN/Developer_Guide dated 02/Apr/2015

Northbound Applications

RESTful APIs

GET /vtn-webapi/controllers.json POST /vtn-webapi/controllers.json DELETE /vtn-webapi/controllers.json

Create-Read-Delete of VTN Controllers (site)

GET /vtn-webapi/vtns.json ...

Create-Read-Delete of VTNs – across all controllers

GET /vtn-webapi/vtns.json ...

Create-Read-Delete of vBridge, specific to a Controller

. . .

VTN Coordinator support creation of L3 Network by defining a vRouter.
Multiple vBridge can be attached to a vRouter using virtual interfaces.
Functions like DHCP Relay, Static Routing can be configured

SLIDE 26

Using VTN Flow-Filters and Redirection for Service Chaining

26

SLIDE 27

Using Redirection for creating Arbitrary Flows

VTN is essentially composed of many virtual nodes and data flows
A Data Flow is composed of multiple related flow entries set on the edge ports and

tied together by some core flows

L2 switching or L3 routing is set of mod_* flows modifying the packet fields

27

V V

VTN

V V V

A single L3 VTN, having 3

flows. All flows are routed

through vRouter Flow color represent their equivalent part on then physical plane Client A Client B Sever B Server A

SLIDE 28

Using Redirection for creating Arbitrary Flows

VTN is essentially composed of many virtual nodes and data flows
A Data Flow is essentially composed of multiple related flow entries set on the edge

ports and tied together by some core flows.

L2 switching or L3 routing is set of mod_* flows modifying the packet fields
Just by using Flow match condition and redirect action, these action=mod_* can

be manipulated for creating almost arbitrary flows

28

V V

VTN

V V V

Making matched frames jump from one vBridge

ut to another vBridge

in Client A Client B Sever B Server A

SLIDE 29

Using Redirection for creating Arbitrary Flows

VTN is essentially composed of many virtual nodes and data flows
Or insert any L3+ service into the network, like a Firewall or a Load Balancer

29

V V

VTN

V V

Client A Client B Firewall Load Balancer

SLIDE 30

Using Redirection for creating Arbitrary Flows

VTN is essentially composed of many virtual nodes and data flows
Or insert any L3+ service into the network, like a Firewall or a Load Balancer
In fact, as arbitrary as making a chain of firewalls

30

V V

VTN

V V

Client A Client B Lab Firewall Org Firewall

SLIDE 31

Using Redirection for creating Arbitrary Flows

VTN is essentially composed of many virtual nodes and data flows
Or insert any L3+ service into the network, like a Firewall or a Load Balancer
In fact, as arbitrary as making a chain of firewalls
Or, a protocol based packet router made entirely using RESTful APIs of ODL

31

V V

VTN

V V

Client A HTTP Server ICMP Monitor

HTTP

Even though the figures above show “going into an interface”, redirection would be much simpler if packets are direction from “in” of a vBridge to “out” of another vBridge

SLIDE 32

Flow Matching in a VTN

A VTN supports filtering of traffic based on certain L2 and L3 fields
Valid fields include [4]
Ethernet: Source and Destination MAC address, VLAN ID, Ether Type, VLAN Priority
IP: Source and Destination IP Address, TCP/UDP Port, ICMP Type, Protocol, DSCP Field
Based on the above fields, a set of matching conditions can be created
Format allows for AND/OR pairing of conditions

32

[4] For Complete list of match conditions, see https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:Flow_List_Entry_Functions. Even though this for VTN Coordinator, same fields are also available for VTN Manager FlowCondition API

{ "name": "cond_1", "match": [ { "index": 1, "inetMatch": { "inet4": { "dst": "10.0.0.4" } } } ] }

API: /controller/nb/v2/vtn/default/flowconditions/{Name of Condition} Conditions are part of the Global scope of a VTN Controller Multiple such blocks, with unique index number, can be defined. Multiple conditions in each of them can be defined. All the blocks work as OR matches and all conditions in them work as AND matches

SLIDE 33

Flow Matching in a VTN

Flow Filters are applied on virtual interfaces using the Flow Conditions defined

33 PUT /controller/nb/v2/vtn/default/flowconditions/AllTCPonVLAN100 Request JSON: { "name": “AllTCP", "match": [ { "index": 1, “ethernet”: { “vlan”: “100” }, "inetMatch": { "inet4": { “proto": “6“ ... ... } Request JSON: { "index": 10, "condition": “AllTCPonVLAN100", "filterType": { "redirect": { "destination": { "bridge": “Br200", "interface": "IF1" }, "output": true ... } PUT /controller/nb/v2/vtn/default/vtns/BLUE/vbridge/Br100/interfaces/IF1/flowfilters/in/10

Flow Condition, global for a particular VTN controller, having a single matching condition, containing two match fields (ANDed) Ethernet: vlan==100 IP: Protocol==6 (TCP) In the VTN BLUE, applying the condition on all frames coming IN the vBridge Br100 and matching the condition AllTCPonVLAN100 Action being Redirection of the traffic onto vBridge Br200 interface IF1

SLIDE 34

Network A: {DPID: OFS#1, Port:04} ... Service A: {DPID:OFS#2, Port:0/4} Service B: {DPID:OFS#4, Port:0/5}

Use Cases: Policy Routing without a dedicated L3 Device

34 Network A Network B Services A Services B

V V V V

Network C

V Northbound Applications

VTN Manager OpenFlow OVS SB Plugin Service Location (Physical) and Properties (Access Lists)

OFS#1 OFS#2 OFS#3 OFS#4 Redirect all traffic originating from ‘Network A’, destined for ‘Services B’ to interface of Service A vBridge. Corresponding reverse rule on Services A vBridge

vBridgeA vBridgeB vBridgeC

SLIDE 35

Network A: {DPID: OFS#1, Port:04} ... Service A: {DPID:OFS#2, Port:0/4} Service B: {DPID:OFS#4, Port:0/5}

Use Cases: Policy Routing without a dedicated L3 Device

35 Network A Network B Services A Services B

V V V V

Network C

V Northbound Applications

VTN Manager OpenFlow OVS SB Plugin Service Location (Physical) and Properties (Access Lists)

OFS#1 OFS#2 OFS#3 OFS#4 Redirect all traffic originating from ‘Network B’, destined for ‘Services A’ to interface of Service B vBridge. Corresponding reverse rule on Services B vBridge

SLIDE 36

Network A: {DPID: OFS#1, Port:04} ... Service A: {DPID:OFS#2, Port:0/4} Service B: {DPID:OFS#4, Port:0/5}

Use Cases: Policy Routing without a dedicated L3 Device

36 Network A Network B Services A Services B

V V V V

Network C

V Northbound Applications

VTN Manager OpenFlow OVS SB Plugin Service Location (Physical) and Properties (Access Lists)

OFS#1 OFS#2 OFS#3 OFS#4 Or, maybe drop all traffic

riginating from the Network C

SLIDE 37

Use Cases: Policy Routing without a dedicated L3 Device

Without the use of a L3+ Routing, creating a Policy based router
Northbound application takes as input a configuration containing service location

(physical ~ virtual) and Application  Service path request

Converts it into an appropriate flow condition and VTNvBridgevirtual interface

flow filter

Traffic Redirected to destination service as per Service topology information
Reverse flow-filters inserted into the Service vBridge to handle the response flows
Destination MAC address information available from the Service topology
(Limitation): Requires MAC Addresses of Server and Client to compensate for ARP

learning

37

SLIDE 38

Use Cases: Implementing a Waypoint Router[5]

“Waypoints are the middle boxes deployed off the Normal path”[5]
Middle boxes represent various network services like Firewall, or Load-balancer which

are expected to added to an existing network

As suggested by this paper, rather than inserting services in the flow, directing the

flows to the service is much more scalable and robust way to inject new services

Waypoints in a VTN
Intermediary services (middle boxes) can be represented by pair (or more) of virtual

interfaces as part of one or more vBridge

Waypoint configurations can be input as policies from User, defining Services and their

locations

Services, with their locations, can be converted into flow matches with redirects

towards waypoint edges

38

[5] “Initial thoughts on custom network processing via waypoint services”, http://yuba.stanford.edu/~nickm/papers/waypoint- cgo11.pdf

SLIDE 39

Use Cases: Application engine for Fresco [6]

‘Fresco’ is a “OpenFlow Security Application Framework …”[6]
Provides a framework for creating policy driven security applications
‘Inspired’ by Click Router Programming framework
Click [7] proposes a router made up of simpler ‘elements’ which can be combined together to

form a strings of routing services

Waypoint functions of OpenDaylight VTN can be used to implement a limited set of Click

Router with push functions

Fresco application modules provides definition for elements having five configurable

functions: Input, Output, Parameter, Action and Event

Complex policy sets can be implemented by chaining together elements
Fresco Security Kernel, or the core packet parsing engine, can be used to perform

DROP, REDIRECT or QUARANTINE operation on a matching stream

One or more Fresco elements can be implemented using condition matching and

filtering (pass, drop, redirect)

39

[6] “Fresco: Modular Composable Security Services for Software-Defined Networks”, http://www.csl.sri.com/users/vinod/papers/fresco.pdf [7] “The Click Modular Router”, http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf

SLIDE 40

Use Cases: Various other possibilities

Various other user cases
Adding L3+ (Firewall, Load-balancers etc.) to the network without worrying about the

physical location

Having multiple deployments based on type of traffic to increase availability and simple

policy management

Having redundant configurations of services, which can be switched as easily as changes into

VTN configurations

Deep Packet inspection
Redirecting traffic to external devices which can store/dissect packets before re-injecting it

into the network

Based on network feedback (security device feedback loop) and creating appropriate flow

conditions, packet inspection scope can be dynamically altered

Combining Docker with OVS for creating composable application stack
Docker units can serve as application hosts or components, spanning across multiple

physical hosts with hierarchical OVS installations (network namespaces) [8]

Based on location of applications, VTNs can be created which in turn push rules to OVS
Using redirection, L3 network can be emulated

40

[8] “OVSForest: Mininet based testbed for emulating large scale networks”, https://github.com/cosanti/OVSForest

SLIDE 41

Thank you!

41

SLIDE 42

Appendix

42

SLIDE 43

Current Release Plan for Lithium

Key activity is to migrate VTN Manager from AD-SAL to MD-SAL

43

Milestone Offset 2 Date Deliverables M1 1/8/2015 Name Status Description Release Plan DONE Candidate Release Plan M2 2/5/2015 Name Status Description Release Plan DONE Final Release Plan M3 3/19/2015 Name Status Description Feature Freeze DONE M4 4/16/2015 Name Description API Freeze Migrating inventory handling to MD-SAL Completing to migrate the code related to inventory handling from AD-SAL to MD- SAL. M5 5/14/2015 Name Description Code Freeze Migrating flow handling to MD-SAL Completing to migrate the code related to flow handling from AD-SAL to MD-SAL. RC0 5/28/2015 RC1 6/4/2015 RC2 6/11/2015 Name Description Release Review Formal Release 6/25/2015

SLIDE 44

Service Function Chaining Project in OpenDaylight
Added as Incubation [9] in OpenDaylight for Helium Release

“...presents service chaining functionality to external user-centric applications via the ODL Northbound REST APIs. … network operators may create, update, and delete service chains, as well as specify the exchange of opaque metadata with network and service nodes in a service path…” [10]

SFC in OpenDaylight

44

[9] From: https://wiki.opendaylight.org/view/Project_Proposals:Main [10] From: https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining [11] From: https://wiki.opendaylight.org/images/8/89/Ericsson-Kumbhare_Joshi-OpenDaylight_Service_Function_Chaining.pdf; Page 17

Uses NSH (Network Service Header) as an encapsulation header for enabling

hop-by-hop service stitching.

Another, non-NSH encapsulation solution also being worked upon
Service hop based on MAC of previous hop [11]
Uses OpenFlow 1.3 compliant network