vBrigade Meetup

September 18-19, 2017

1

Topics for Discussion

1. Season 1
1. Season 1 checkpoint
2. Current design
3. Demo??
4. How-to’s
2. Season 2
• Unfinished tasks from Season 1
• Testing (integration and systems)
• External Connectivity to allow communications between other networks
• Openstack integration to support network infrastructure
• Virtual network pausing and snapshotting
• Virtual Network embedding

2

Season 1 checkpoint�

3

See http://ovx.onlab.us/about/

Topology virtualization

• Decouple Virtual Network topology from physical network
• Provides tenants the flexibility to specify desired network topologies that best suit their needs
• Each virtual network topology is independent

4

Address virtualization

Control function virtualization

• Enables tenants to use their own network address space
• Each virtual network’s address space is independent

• Allows each virtual network to have its own NOS and applications that can program the virtual network switches
• All virtual network control functions are translated into physical operations

5

Current design�

1. The current design of the Virtualization subsystem (virtual core and virtual provider components) is detailed in pages 10 to 19 of YoonSeon’s ONS 2017 presentation ONS_2017_Yoonseon_final.pdf. Only certain sections will be expanded in these slides.
2. OFAgent will be discussed in detail during this session.

6

Virtual network model

7

VN model implementation

8

ONOS core and VN core service modules

9

Illustration of ONOS core services from https://wiki.onosproject.org/display/ONOS/System+Components

VN core services as depicted on slide 19 of ONS 2017 slides

​

Virtual network subsystem structure

10

VN subsystem structure from slide #14 (YoonSeon’s ONS 2017)

​

Virtual network components - FlowRule example

Using FlowRule as an example, we will examine some concrete classes that make up the main virtual network components:

• Virtual Manager
• Virtual Store
• Virtual Provider
• Virtual Provider Service

Similar components exist for Packet, Group, Meter, etc.

11

VN subsystem structure - FlowRule

12

Virtual Manager - FlowRule

13

Virtual Flow Rule Store & Flow Rule Store

14

Provider & Virtual Provider - FlowRule

15

Provider Service & Virtual Provider Service - FlowRule

​

16

OFAgent

Goal: allow tenant to use external SDN controllers through Openflow

Features

• On-platform ONOS app, tenant-aware
• ONOS CLI commands or REST API’s to create, start, stop and remove an ofagent - one ofagent per virtual network

​

​

17

OFAgent main components

18

* OSGI component

OFAgentManager

Administers inventory of OpenFlow agents using a distributed store

​

​

​

​

​

​

CLI commands and/or REST api are used to:

• Create and remove agents
• Start and stop agents
• Add and remove OF controllers to an agent
• Query a specific agent or all agents

​

​

19

​

20

OFSwitchManager

​

Manages all OpenFlow switches (for all virtual networks)

• Responsible for maintaining a local store of OpenFlow switches
• Listens for OFAgentEvent and VirtualNetworkEvent events, which trigger changes to the OF switches
• Uses VirtualNetworkService to retrieve virtual device, port and link information
• Interacts with the OFAgent manager to retrieve OFAgents of virtual networks

OSGI component

• on activation, virtual devices of virtual networks that have an OFAgent are used to instantiate OFSwitch objects. The OFSwitch objects will be stored in the manager’s local store, and connections are made between them and the external controllers.
• on deactivation, all the external controller connections to each OFSwitch is disconnected.

21

OFSwitchManager - Event triggers

22

DefaultOFSwitch

Represents an OpenFlow switch to an external controller.

• Keeps track of controller to switch connections, and also the role (master, equal, slave) that each controller has
• Handles controller’s Openflow messages (e.g. stats requests, flow mod requests, controller role change requests)
• Keeps controllers informed with asynchronous messages (e.g. port status, flow removed)

​

23

DefaultOFSwitch

24

Demo

1. YoonSeon’s demo at his talk (ONOS-minisummit) at ONS 2017 shows that the virtualization subsystem (virtual core and provider components) is able to successfully handle flow rules and packets on virtual devices [https://youtu.be/D9yRPvnfyBo].�

25

How-to’s

1. Development environment setup
2. Ad-hoc testing with external controller (ONOS) setup - just 1 way - there can be a lot of other ways!
3. Tips for newcomers
4. Real world scenarios - Use cases <needs more work>

26

Development environment setup

• The development environment setup needed for virtualization is the same as for ONOS.
• Details are available at https://wiki.onosproject.org/display/ONOS/Development+Environment+Setup.
• Buck is used to build ONOS - which includes OFAgent code. In the past, maven was needed to build OFAgent, but not any more.

​

27

Mininet - How to Invoke

Using CLI (this must be run on the server that will be actually running mininet):

• sudo mn -topo linear,4 --mac --controller remote,ip=$ip,port=6633 (replace with topo of your choice, and ip of remote controller). Default port is 6633; have to specify port=6653 if using that port.
• ^D to terminate from mininet prompt will take down the network
• sudo mn -c # this will cleanup any leftover mininet processes/resources

Using stc (need to have cell setup):

• stc net-setup # this will setup mininet with default.py topology
• If another topology is needed, can run “topo <another_topo>” before running net-setup
• For a list of available topos, run “topos”
• stc net-teardown # this will take down mininet

​

​

28

Ad-hoc testing with external ONOS controller setup - 1

To perform ad-hoc testing with external controller, the following is needed:

1. 2 single instances of ONOS
1. 1 main controller that will be used to create virtual networks - this controller must have the OFAgent app activated. [In the example that follows: ip address of main controller is 192.168.2.14|localhost (laptop)]
2. 1 external controller that will see virtual devices as physical devices [Ip address of external controller is 192.168.56.101 (vm)]
2. Mininet that uses the main controller [in our example, mininet will be running on 192.168.56.101 (vm) and connecting to main controller at 192.168.2.14|localhost (laptop)]
3. Before doing the setup, ensure that you can ping from 1 ip to another

​

29

Ad-hoc testing with external ONOS controller setup - 2

​

Steps:

1. Get the main controller running and ensure OFAgent is activated.
1. onos-buck run onos-local -- clean debug
2. onos localhost apps -s -a | grep ofagent
3. onos localhost app activate org.onosproject.ofagent # run this if ofagent is not activated
2. Get mininet running, using the main controller’s ip
• sudo mn -topo <topology-of-your-choice> --mac --controller remote,ip=$ip,port=6633
3. Get the external controller running (e.g. on a vm using cell); OFAgent is not needed
• cell local
• stc setup # or “stc startup” if vm already has ONOS installed

​

30

Ad-hoc testing with external ONOS controller setup - 3

Steps (continued):

4. Open a browser and connect to the main controller - mininet devices should be present
1. http://localhost:8181/onos/ui/login.html#/topo
5. Create virtual network using cli on the main controller
• onos localhost vnet-add-tenant TestTenant
• onos localhost vnet-create TestTenant
• onos localhost vnet-create-device 1 of:1122334455660001
• onos localhost vnet-create-device 1 of:1122334455660002
• onos localhost vnet-create-port 1 of:1122334455660001 1 of:0000000000000003 1
• onos localhost vnet-create-port 1 of:1122334455660002 2 of:0000000000000001 1
• onos -f localhost vnet-create-link --bidirectional 1 of:1122334455660002 2 of:1122334455660001 1

​

​

31

Ad-hoc testing with external ONOS controller setup - 4

Steps (continued):

• Create and startup ofagent for the newly created virtual network. Ensure that the external controller is up before doing this.
• onos localhost ofagent-create 1 && onos localhost ofagent-controller-add 1 192.168.56.101:6633 && onos localhost ofagent-start 1
• Open another browser and connect to the external controller - topology of virtual devices should be visible
• http://192.168.56.101:8181/onos/ui/login.html#/topo

​

32

Tips for newcomers

​

Based on the feedback vBrigade members, newcomers are encouraged to develop a good understanding of:

33

Unfinished tasks from Season 1 - OFAgent

OFAgent tasks - needed to support external controllers through Openflow

​

​

34

Unfinished tasks from Season 1 - Virtual core/SB

35

Unfinished tasks from Season 1

1. Testing (unit test + functional testing)
2. Documentation (better to look at source code since doc may not be aligned with code in master branch)
3. ???

36

Testing

ONOS testing options:

1. Unit tests https://wiki.onosproject.org/display/ONOS/Unit+Test+Guidelines
2. Scenario test Coordinator (STC) https://wiki.onosproject.org/pages/viewpage.action?pageId=12421025
3. Mininet and onos.py workflow https://wiki.onosproject.org/display/ONOS/Mininet+and+onos.py+workflow
4. ONOS test environment: Vagrant, LXC and cell https://wiki.onosproject.org/display/ONOS/ONOS+test+environment%3A+Vagrant%2C+LXC+and+cell
5. System tests (TestON) https://wiki.onosproject.org/display/ONOS/System+Testing+Guide

Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing.

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.

1. Create system test plan

2. Define testcases and test data

3. Testing automation (TestON on Jenkins https://wiki.onosproject.org/display/ONOS/System+Test+Setup+Overview)

37

38

External Connectivity to allow communications between other networks

Goal: Support external connectivity to allow communications between other networks (I.e., Other virtual networks, Internet)

Doyoung Lee will be sharing his research and looking for feedback.

39

Openstack integration to support network infrastructure

Goal: Adapt the Neutron APIs to the Virtual Network API’s.

Hyunsun explained ONOS and OpenStack integration and its use cases: https://groups.google.com/a/onosproject.org/forum/#!topic/onos-discuss/NIS-m-mpp3E

40

Virtual network pausing and snapshotting

Goal: Support network pausing and snapshotting to enable backup and restore of a VN, and migration.

Ali: Snapshotting and pausing is not supported in ovx. Although it would be rather simple to implement. Snapshotting can be done by dumping the virtual flowstate to some storage, clearly there is a little more to this but that would be a good start. Pausing would involve changing output actions of all ingress forwarding rules from the dataplane such that traffic from one network is effectively stopped.

​

41

Virtual Network embedding

Allow user to define a general structure of a vnet without specifying how it maps to the underlying network. This floating structure then needs to be embedded/mapped onto the underlying network before the vnet can be realized. This can be done either manually or computationally based on the current structure/utilization of the underlying network.

42

Brigade Expectations

​

• ONOS Release cycle - Expectations of brigade https://wiki.onosproject.org/display/ONOS/Brigades#Brigades-Expectations
• We need to develop a high-level vision for the group’s efforts and document in brigade’s wiki
• We need to keep a public location updated with work items and status
• Brigade lead (or delegate) needs to participate in brigade review meeting
• Participate in release/sprint meetings
• Test Coverage

43

Brigade Expectations

• Scrum meetings
• Weekly - Mondays - 5:30am PST - is this still ok? Do we need to meet more often/less often
• Scrum summaries - currently sent by email weekly - how about if we maintain 1 document and update it instead?
• ONOS Release cycle - Expectations of brigade https://wiki.onosproject.org/display/ONOS/Brigades#Brigades-Expectations
• We need to develop a high-level vision for the group’s efforts and document in brigade’s wiki
• We need to keep a public location updated with work items and status
• Brigade lead (or delegate) needs to participate in brigade review meeting
• Participate in release/sprint meetings
• Test Coverage

44

Unused/discarded

45

Virtual Manager - AbstractVirtualListenerManager

46

Tips for newcomers

Based on the feedback vBrigade members, newcomers are encouraged to develop a good understanding of:

1. OpenFlow protocol and its stack (flowgrammable)
2. ONOS code flow (core and api) <- MUST! https://wiki.onosproject.org/display/ONOS/Architecture+and+Internals+Guide Virtual networks are built on top of ONOS abstractions so basic knowledge regarding ONOS concepts is prerequisite.
3. Apache Felix and OSGi https://wiki.onosproject.org/display/ONOS/Troubleshooting+ONOS+OSGi+components
4. Logging
5. <team input needed>

​

47