Planeamento

Aulas

Lecture 1

Class introduction. Learning goals. Syllabus. Planning. Evaluation. Bibliography. SDN contextualization. Legacy vs. SDN-based network. Three main features of SDN. SDN advantages and potential disadvantages. Network softwarization and its benefits for several network players. Starting with network virtualization and building a network topology via Linux shell commands. Introduction to the concepts of Linux NameSpaces, Linux Bridges, and network links.


Lecture 3

Origins of SDN. Three Features that Define SDN. Why we need SDN? Software Defined Anything (SDx). Centralized vs. Distributed. What SDN is Not? Separation vs. Centralization. Current SDN Debate. Next SDN Laboratory. Spanning Tree Protocol.


Lecture 5

Data Plane Devices. Configuration (Management) vs. Control. OF-Config and OpenFlow Comparison. Example of a configuration scenario. Example of a control scenario. Switch rule. Configuration vs. Control (both local). OpenvSwitch - Local Management. OpenvSwitch. Briefly explanation about the next laboratory session.


Lecture 7

Validating switch flow rules using the trace option of ovs-appctl command. Switch operates following flow rules stored in several flow tables. Next Laboratory.


Lecture 9

Data Plane Control based on flow rules. Routing packets using software-based switches. Next laboratory.


Lecture 11

OpenFlow Protocol. Ryu SDN controller. Writing a Ryu application. Mininet as a network emulator. Next laboratory.


Lecture 13

Message Types in OF1.0. Controller Discovers New Switch. Negotiation of OpenFlow Version. Controller Gets Switch Characteristics. Reactive Control. Proactive Control. Topology: Link Discovery. Monitoring of Topology Status. Next Laboratory.


Lecture 15

Evolution of OpenFlow protocol. NorthbBound API. Debugging python code. Next laboratory.


Lecture 17

The relevance of programming the aimed operation of a networking infrastructure. Future X Network - A new revolution on his way. Edge Micro Datacenter: Fog Datacenter. Fog Datacenter: System Architecture. Next Laboratory.


Lecture 19

SDN Control has a Centralized Design. Switch Actions to Address Communication Failure with the SDN Controller. Control Plane Actions to Address Failures. Multiple SDN controllers. Next Laboratory.


Lecture 21

OpenFlow Group Tables. Protocols for Network Monitoring. Current Proposal to enhance egresss rate. Python package NetworkX. Network Monitoring via OF & Group Table Reconfiguration. Mininet customized topologies. Iperf UDP/TCP data traffic generator/receiver. Next Laboratory.


Aulas

Lecture 2

Laboratory session to introduce the virtual machine (VM) that it will be used along the course. Using the previous VM: learn how to create an emulated host using the concept of Linux NameSpaces; learn how to add, configure and enable the network interfaces on each host; learn how to create a network link connecting two interfaces; learn how to create a Linux bridge (or switch) that will be connecting the two hosts of the current topology; learn how to add to the switch the associated interfaces of the two network links previously created; and learn how to test the current emulated (or virtualized) topology.


Lecture 4

The current laboratory acting as a continuation practical session of the last week laboratory, it has the next main learning goals: learn how to create and remove an emulated network topology, using script files; learn how to emulate more realistic network conditions, such as latency and jitter, using the Linux Traffic Control (tc) tool; and learn how the spanning tree protocol avoids loops within a local network.


Lecture 6

During the current laboratory lecture, the students are expected to learn about the next aspects: i) create an emulated host using the concept of Linux NameSpaces; ii) add, configure and enable the network interfaces on each host; iii) create a network link connecting two interfaces; iv) create a OpenvSwitch (OVS) that will be connecting the three hosts of the current topology; v) add to the switch the associated interfaces of the three network links previously created; vi) create the emulated topology by using a single script file; vii) specify on the switch traffic rules that match at distinct OSI layers; viii) test the current emulated topology; ix) remove from the system the visualized network infrastructure by using a second script file.


Lecture 8

During the current laboratory lecture, the students are expected to learn the next topics: create an emulated host using the concept of Linux NameSpaces; add, configure and enable the network interfaces on each host; create a network link connecting two interfaces; learn how to create a OpenvSwitch (OVS) that will be connecting the three hosts of the current topology;add to the switch the associated interfaces of the three network links previously created; create the emulated topology by using a single script file; flush the switch table where the switch stores the learned L2 MACs associated with corrresponding switch port; specify on the switch flow rules divided through diverse tables; test in several scenarios the current emulated topology, including the correctness of the flow rules installed in the tables of each switch.


Lecture 10

During the current laboratory lecture, the students are expected to learn how to deploy virtualized memory-based routers, using two methods: i) the first method uses two OVS switches configured with flow rules that use the local port of each switch, which is essential for incorporating the kernel routing table in the routing decision of each packet: ii) the second method instantiates a namespace container and configures it as a standalone router. Meanwhile, the students also learn how to deploy a NAT router.


Lecture 12

During the current laboratory lecture, the students are expected to fulfill the next goals: i) Learn how to create an emulated network using Mininet; ii) Understand how the given code of a python application, which uses some libraries of the Ryu SDN package, listens the initial request from an OVS switch, accepts that request, initializes the switch, and then controls the switch; iii) Analyze and experiment several (four) python applications that offer various SDN based functionalities over the same topology.


Lecture 14

The current laboratorial lecture taught how to deploy a SDN-based network formed by a SDN controller (i.e. Ryu) and several OpenvSwitch (OVS). The OVSs connected in a serial topology enable the interconnection between two hosts. The current lecture also taught how the OpenFlow (v1.0) protocol is used between the SDN controller and each OVS. In addition, it is studied how some important system functionalities, such as topology discovery and network monitoring, can be supported. First, to implement the functionality of topology discovery, the Link Layer Discovery Protocol (LLDP) is used. Second, for ensuring the network monitoring, a python thread runs periodically, i.e. once each pre-defined time window, in the SDN controller. Each time that thread runs, it enforces the exchange of some OF messages through the control channel that exists between the SDN controller and each switch. Those OF messages enable the SDN controller to be updated with relevant statistical information about switch ports and flow rules.


Lecture 16

The current laboratorial lecture taught how to use the Northbound API of the Ryu Controller to configure a firewall application which is controlling in terms of security an OpenvSwitch, using the Southbound protocol OpenFlow v1.3.


Lecture 18

The current laboratorial lecture taught how to deploy a Ryu SDN application that offers an on-demand elastic service, which is designated as the fog datacenter. The fog datacenter automatically detects the need to activate a part of the network topology before routing some traffic destined to some destination node. This destination node is also activated before the SDN application controlling the necessary switches to deploy the routing path through the network infrastructure to that receiving node. This fog datacenter could offer heterogeneous resources, such as networking, computation, and storage, where and when those resources are necessary, at the network edge.


Lecture 20

The current laboratorial lecture taught how to write a Ryu application that supports scenarios with multiple SDN controllers. There are three possible functional roles for each SDN controller forming the cluster of the diverse SDN controllers. The three possible SDN controller roles are MASTER, SLAVE, or EQUAL. This lecture aims to deliver to its practitioners relevant knowledge in the next aspects: i) study the two possible and exclusive switch reactions for the case the communication with the control plane has failed; ii) show how each SDN controller is configured for its role within the control cluster; iii) evidence how the control cluster formed by distinct SDN controllers gives more strong guarantees against a SDN controller failure at the control plane; iv) study how the cluster SDN controllers divide among them the control responsibility of the diverse nodes of the data plane; and v) study how the SDN controllers forming the control cluster and, using the OpenFlow v1.3 protocol interact with the network devices (i.e. OVS switches) to deploy diverse multi-controller scenarios.


Lecture 22

The current laboratorial lecture aims to fulfill the next learning goals: i) experiment some given python code that deploys a specific topology connecting three switches via a triangular topology, using the Mininet Python API; ii) experiment a given SDN Ryu Application that implements, namely, the mechanism already discussed in the last Theoretical lecture, designated as Network Monitoring via OpenFlow (OF) & Group Table Reconfiguration; and iii) evaluate previous code in some practical scenarios associated with QoS rate metric fulfillment and network operation robustness against switch port failure.


Aulas

Seminar 1 of 2

Seminar about SDN and other related technologies from the point of view of an invited consulting Telco entreprise.


Seminar 2 of 2

Seminar about SDN and other related technologies from the point of view of an invited telecom national operator.