Hello, welcome back. In this lecture we'll talk Ryu. We'll give an overview of the Ryu controller. We'll give an overview of the controller, talk about its API, and provide a demonstration of the Layer 2 Learning Switch. Here's an overview of the Ryu architecture. At the very bottom of the picture, you can see a bunch of libraries that we'll talk about. We also have a Ryu controller interface with switches via various south-bound interfaces. We have an OpenFlow controller, a Ryu manager, and an app manager that sit on top of that. And on top of that we have applications and other north-bound APIs such as rest and open step neutron. Ryu can also speak to switches natively via the OpenFlow controller. Like other SDN controllers, RYU has the ability to handle asynchronous events such as packet-in, but one of its advantages is to talk to switches via many different south-bound APIs. We'll now talk in a little bit more detail about each of Ryu's components. The Ryu libraries support multiple southbound protocols, including OF-CONFIG, OVSDB, NETCONF, XFLOW, and an open vSwitch Python Binding. There's also support for various parsing, and constructing packet parsers that conform to various protocol definitions. Ryu supports OpenFlow up to version 1.4, and handles a variety of controller to switch messages. Including handshake, switch-config, flow-table config, ability to read and modify state, queue configs and barrier commands. The controller also handles various asynchronous messages such as packet-in, flow-removed, and port-status. The Ryu manager, which we'll look at in a minute, is the main executable. It listens to port 6633 by default, and any OpenFlow switch can connect to the manager, whether it's software or hardware. All control applications inherit from the RyuApp class. The Ryu north-bound API provides support for Openstack Neutron, as well as GRE-based overlays, VLANs. It also provides a generic REST interface for performing OpenFlow Operations and makes it easy to introduce new REST APIs. Ryu ships with many applications including a simple switch, which we'll look at, a router, a firewall, and many others. The application has a FIFO event queue, and event processing as blocking, meaning that when a controller is processing an event all other tasks, such as processing incoming packets, are blocked. Here's some code showing a simple switch overview, which we will look at in detail in just a minute. As you can see, the Ryu control application is a simple Python program. The layer to switch class inherits from the Ryu path, and the main function of interest is the packet-in handler. This Python decorator sent event class indicates when this particular function is called. As you can see, this particular function is called any time a packet arrives at the controller, as indicated by this event specification. This particular packet handler simply floods all packets on outgoing ports. Let's take a quick look at a simple hub program that is included in your force virtual machine. This is probably the simplest Ryu control program we could write. Here you can see a simple constructor. The main function of interest is the packet-in handler which, according to the decorator, is invoked anytime a packet-in event occurs. You can see that the syntax is very similar to that which we used in Pox. When the event occurs, we parse the message, the data path of that message, the open flow of protocol version, and the set of possible actions. We then generate a packet to send from the switch, with the OFP packet-out method, and simply send that message out of the controller. We can start this simple three-note mini-netology and the simple hub and we see that this controller works as expected. The simple switch works similarly. There's also a packet-in handler. And as is the case with learning switches, we learn the corresponding mapping between the output port, and the MAC address. We also install a flow in the OpenFlow switch to avoid a packet-in event in the future. Here we could see the output of the simple switch, which is provided In the Ryu distribution. Here's an overview of the code structure of the Ryu code base. When you look at the Ryu code base, you'll see many different sub-directories. App contains the set of applications that run on top of the controller. Base contains the base class for Ryu applications. In particular, it contains the RyuApp class which is inherited. We're creating a new application. Controller contains the required set of files to handle OpenFlow functions, such as packets from switches, network events, and so forth. Lib contains a set of packet libraries to parse different protocol headers and a library for OFConfig, as well as libraries for parcing netflow and esflow. OF proto contains the overflow protocol specification in related parsers. Topology contains coded forms of policy discovery related to OpenFlow switches. In conclusion, Ryu is a Python-based SDN controller that supplies rich support for a wide variety of north-bound applications and south-bound control protocols. It's easy to program and provides OpenFlow support up to OpenFlow 1.4. You can read more about Ryu in the url provided here and we also provided some examples such as the ones we offered in this lecture in the course virtual machine.