OpenDaylight VTN and Waypoint by Redirection · •Adding another Interfaces to the vBridge Br100 on BLUE •Multiple virtual interfaces per vBridge can be created; Each is equivalent

Understanding OpenDaylight VTN and the Redirection Function

Shreyansh Jain

NEC Technologies India Pvt. Ltd.

shreyansh.jain@{nectechnologies.in, gmail.com}

Next 45 Minutes …

• A brief introduction to OpenDaylight VTN • OpenDaylight Platform: VTN Project Overview

• Understanding VTN: Definition, Virtual Nodes and Network Creation

• Physical Virtual Mapping of VTN

• Creating Network Topology and Packet Handling

• Using VTN Manager REST APIs

• Using VTN Flow-Filters and Redirection • Using Redirection for creating arbitrary flows

• Flow Matching in a VTN

• Various Use Cases

• Appendix

2

Understanding OpenDaylight VTN Project

3

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)

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





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






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

Ph

ysic

al N

etw

ork

V V

V

Vir

tual

Net

wo

rk

V V

V vRouter

vBridge

Virtual Interface

OpenFlow Switch

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)

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 or more Virtual Networks

Creating a Physical Topology; One in which one or 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

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

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

https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf









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 or 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










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

Vir

tual

Net

wo

rk


• 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

Vir

tual

Net

wo

rks


• 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"}

Vir

tual

Net

wo

rks

Name of the new vBridge for VLAN 100

V Br100

A vBridge on a VTN


• 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

Vir

tual

Net

wo

rks

V Br100

IF1


• 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


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

Another Interface on vBridge Br100

Vir

tual

Net

wo

rks

V Br100

IF1 IF2


• 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"}

Vir

tual

Net

wo

rks

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


• 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"}

Vir

tual

Net

wo

rks

V Br100

IF1 IF2


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

V Br300

IF1

V Br200

IF1

VLAN 200


• 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"}

}

Vir

tual

Net

wo

rks

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


• 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"}

}

Vir

tual

Net

wo

rks

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


• 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"}

}

Vir

tual

Net

wo

rks

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


• 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"},

}

Vir

tual

Net

wo

rks

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


• 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:


• 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

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


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 <Some of the APIs are still mentioned as ‘planned’ in the Wiki>

https://wiki.opendaylight.org/view/Release/Helium/VTN/Developer_Guide

https://wiki.opendaylight.org/view/Release/Helium/VTN/Developer_Guide

Using VTN Flow-Filters and Redirection for Service Chaining

26

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


• 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 out to another vBridge in

Client A Client B

Sever B Server A


• 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



• In fact, as arbitrary as making a chain of firewalls

30

V V VTN

V V

Client A Client B

Lab Firewall Org Firewall



• 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

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

https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:Flow_List_Entry_Functions

https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:Flow_List_Entry_Functions

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

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


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



35

Network A

Network B

Services A

Services B

V V V V

Network C

V


VTN Manager



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



36

Network A

Network B

Services A

Services B

V V V V

Network C

V


VTN Manager



OFS#1 OFS#2

OFS#3 OFS#4

Or, maybe drop all traffic originating from the Network C


• 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 VTNvBridgevirtual 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

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

http://yuba.stanford.edu/~nickm/papers/waypoint-cgo11.pdf




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

http://www.csl.sri.com/users/vinod/papers/fresco.pdf

http://www.csl.sri.com/users/vinod/papers/fresco.pdf

http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf

http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf

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

https://github.com/cosanti/OVSForest

https://github.com/cosanti/OVSForest

Thank you!

41

Appendix

42

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


Release Plan DONE Final Release Plan

M3 3/19/2015


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

• 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

https://wiki.opendaylight.org/view/Project_Proposals:Main

https://wiki.opendaylight.org/view/Project_Proposals:Main

https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining

https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining

https://wiki.opendaylight.org/images/8/89/Ericsson-Kumbhare_Joshi-OpenDaylight_Service_Function_Chaining.pdf






Documents

OpenDaylight VTN and Waypoint by Redirection · •Adding another Interfaces to the vBridge Br100 on BLUE •Multiple virtual interfaces per vBridge can be created; Each is equivalent