Sample Application: The Learning Switch Functionality


  • Create a HashMap called mac_to_port
  • On packet_in, parse packet to get source and destination MAC addresses
  • Store in a hashmap mapping between src_mac and in_port
  • Lookup dst_mac in mac_to_port map to find next hop
  • If next hop is found, create flow_mod and send
  • Else, flood like hub.


Processing a Packet: System View

The application's workflow when processing a packet is shown in the following figure.

Steps 1-3 in the figure show pkt_in processing. Steps 4-7 show pkt_out processing (flooding if not match is found). finally, Steps 8-12 show flow programming to the switch.
The sequence details are as follows:
  1. A packet_in is sent from the switch to controller
  2. The OpenFlow java library parses the packet and translates it into an MD-SAL format governed by the OpenFlow protocol model; the OpenFlow 1.0/1.3 Plugin creates an MD-SAL Notification and publishes it into the MD-SAL.
  3. MD-SAL routes the notification to all registered consumers, in this case the Learning Switch application
  4. If the Learning Switch application does not yet have the mapping between the mac address and the port, it floods the packet. Flooding is done as pkt_out to the switch. The application issues an MD-SAL RPC (with input parameter that constitutes the pkt_out PDU payload).
  5. MD-SAL routes the RPC to the OpenFlow 1.0/1.3 Plugin
  6. The OpenFlow 1.0/1.3 Plugin processes the packet, which is eventually translated into an OpenFlow pkt_out PDU in the OpenFlow Java library.
  7. The OpenFlow pkt_out PDU is sent to the switch.
  8. When the application wants to program a flow, it creates a new flow in the MD-SAL Database. A new flow is created in the appropriate table (Table 0) , which is in the appropriate flow-capable node (i.e switch, openflow:1 in the example), which is in the config space of the MD-SAL inventory database. The inventory database is a subtree (namespace) of the MD-SAL database.
  9. MD-SAL generates a change notification, which is received by the Forwarding Rules Manager (FRM). The FRM listens on flow updates - i.e. it registered for MD-SAL change notifications on the config name space subtree that corresponds to flows.
  10. The FRM programs the flow. It issues an MD-SAL RPC flow programming operation.
  11. MD-SAL routes the RPC to the OpenFlow 1.0/1.3 Plugin
  12. The OpenFlow 1.0/1.3 Plugin processes the packet, which is eventually translated into an OpenFlow FlowMod PDU in the OpenFlow Java library.
  13. The OpenFlow FlowMod PDU is sent to the switch.


Building the Application

  • Prerequisites:
    • Java 7, Maven 3.0.5 or later, Linux or Mac
  • Download the application code from ODL OpenFlow Plugin repo:
> git clone https://git.opendaylight.org/gerrit/p/openflowplugin.git
  • Build the application:
> cd  openflowplugin/samples/learning-switch/
> mvn clean install
  • The build creates the ‘learning-switch-0.0.3-SNAPSHOT.jar’ bundle in ‘openflowplugin/samples/learning-switch/target’

Analyzing the Code in Eclipse:

Prerequisites: Install maven plugin for Eclipse

Setting up the Environment

  • Unzip the downloaded controller package
  • Delete the ‘Simple Forwarding Application’ bundle from the distribution:
> rm opendaylight/plugins/org.opendaylight.controller.samples.simpleforwarding-0.4.1.jar
  • Upload the created bundle: put the ‘learning-switch-0.0.3-SNAPSHOT.jar’ bundle into the ‘opendaylight/plugins’ folder
  • Update logger configuration:
  • Optionally, add the following line to the 'configuration/logback.xml' file:
<logger name="org.opendaylight.openflowplugin.learningswitch" level="TRACE"/>

Update on dependencies

As the released version is getting outdated, it is preferable to use the latest version
SNAPSHOTs (grab latest SNAPSHOT).

Starting up the Environment

  • Run the controller:
> ./run.sh -of13
  • Check that the application bundle is active. On the controller console, type:
osgi > lb learn
  • You should see something like:
START LEVEL 6
   ID|State      |Level|Name
  103|Active     |    4|learning-switch (0.0.3.SNAPSHOT)
osgi>
  • Optionally, check that the controller is listening on Ports 6633 and 6653.
    • On a Linux console, type:
> netstat -lnp | grep 'java’
    • On a Mac OSX console, type:
> lsof -i | grep LISTEN |grep java
  • Start Mininet:
> sudo mn --topo single,10  --controller 'remote,ip=<controller-ip-address>,port=6633' --switch ovsk,protocols=OpenFlow13

Running the App

Workflow

Learning Switch Startup

public class Activator extends AbstractBindingAwareConsumer implements AutoCloseable {
    @Override
    public void onSessionInitialized(ConsumerContext session) {
        [...]
    }
}
and inject them into a new LearningSwitchManagerMultiImpl instance, which we then start.
  • During its startup, LearningSwitchManagerMultiImpl hooks up into MD-SAL services by:
    • registering a new instance of PacketInDispatcherImpl as a NotificationListener
    • creating a FlowCommitWrapperImpl instance, which will store flow information into the Configuration data tree
    • creating a MultipleLearningSwitchHandlerFacadeImpl instance, whose function is to ensure that a single instance of LearningSwitchHandlerSimpleImpl is created for each known switch
    • creating a WakeupOnNode instance and registering it with DataBrokerService to have it notified about when FlowCapableNodes change in the inventory

New Switch Activation

When OpenFlow plugin discovers sees a new switch connected, it will create a new entry for it in the inventory and will start populating the inventory with the tables learned from the switch. Each such update triggers WakeupOnNode.onDataChanged() callback, which examines the inventory entry and looks for presence of a table with id == 0 (InstanceIdentifier: Nodes/Node/augmentation:FlowCapableNode/Table). As soon as it finds it, it will inform MultipleLearningSwitchHandlerFacadeImpl about the switch coming online.
MultipleLearningSwitchHandlerFacadeImpl reacts to the new switch by inserting a low-priority flow, which will forward all packets to the controller, into the configuration data tree. It then notifies the per-switch LearningSwitchHandlerSimpleImpl of the location of table 0. The store operation will asynchronously trigger FRM, which will push the flow onto the switch through the OpenFlow Plugin. LearningSwitchHandlerSimpleImpl disconnects WakeupOnNode listener from the inventory node of that particular switch, so as to suppress any future notifications.
From this point on the new switch is configured and the rest of the logic will only react to PacketInNotification events.

Processing a PacketInNotification

When a PacketIn occurs, LearningSwitchHandlerSimpleImpl.onPacketReceived() triggers. It examines the packet's source and destination MAC address and creates the source MAC to ingress port mapping. It then checks if the destination MAC has a port mapping defined. If it does not, it floods the packet to all ports. If it there is a mapping, it will check if a flow has been created to cover this packet's path towards the port where the destination MAC was seen. If not, it creates a flow. In either case it forwards the packet through the destination port. This is necessary because flow installation has a latency during which we should not be losing packets.
After starting injecting packets, you should see a gradual drop in the number of packets being sent to the controller as it builds up the flows to cover the traffic hitting the switches.

The Testing Scenario

- build distribution/base - remove plugins/org.opendaylight.controller.samples.simpleforwarding-*-SNAPSHOT.jar - copy simple learning jar into plugins folder - start controller (run.sh) - start wireshark - start mininet+(ovs(OF-1.0|OF-1.3)|cpqd)
 - ovs(OF-1.0) : sudo mn --topo single,10  --controller 'remote,ip=10.0.42.5,port=6633' --switch ovsk,protocols=OpenFlow10
 - ovs(OF-1.3) : sudo mn --topo single,10  --controller 'remote,ip=10.0.42.5,port=6633' --switch ovsk,protocols=OpenFlow13
 - cpqd        : sudo mn --topo single,10  --controller 'remote,ip=10.0.42.5,port=6633' --mac --switch user
- observe wireshark, wait for flow_mod message - check if flow is pushed to switch
 - ovs(OF1.0): sudo ovs-ofctl -O OpenFlow10 dump-flows s1
 - ovs(OF1.3): sudo ovs-ofctl -O OpenFlow13 dump-flows s1
 - cpqd      : sudo dpctl unix:/tmp/s1 stats-flow
- in mininet enter:
 - h1 ping h2
 - pingall
- observe ws, flows ..



















Reference:https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:MD-SAL_App_Tutorial


评论

发表评论

此博客中的热门博文

openflow switch(I)

图片
一、基础概念图： 　　首先我们先看下Open Flow Switch的整体结构，以便有一个初步的感性认识，如下图所示： 从上面架构图中，我们可以看到Open Flow Switch主要是由以下几个部分构成： 1、Remote Controller：我们知道，SDN网络将传统的网络结构划分成了Control Plane和Data Plane两部分，这里的Remote Controller正是Control Plane部分，通过约定的通信协议来远程控制管理OpenFlow Switch，增加、删除或者修改OpenFlow Switch的Flow Entries。 2、OpenFlow Channel：它可以被认为是OpenFlow Switch对外开放的接口，接受来自于Remote Controller的通信协议，进而来操纵OpenFlow Switch。 3、OpenFlow Protocol：一种通信协议规范，用于Remote Controller和OpenFlow Switch之间的消息交换。 4、Flow Table：包含多个Flow Entry记录，控制数据包的流向，具体过程可参考下文。 5、Group Table：相对于Flow Table，控制着数据包更高级的转发特性，比如Flooding、Multipath、Fast Reroute、Link Aggregation等。 6、Pipeline：由多个Flow Table链接而成，控制数据包的一系列行为。 OpenFlow Ports 1、Standard Ports（标准端口）：  　　OpenFlow Standard Ports通常被定义为是 Physical ports, logical ports和支持的 LOCAL Reserved ports （不包括其他的Reserved ports）。它们可被用于 ingress port，也可被用于 output port，同样可以用于 Group 里，它们都有 port counters。 2、Physical Ports（物理端口）： 　　OpenFlow Physical Ports是OpenFlow Switch定义的、 对应于物理交换机的一个硬件接口的port。 比如在一个以太网交...
阅读全文

YANG Tools:YANG to Java Mapping

1   YANG to JAVA mapping 1.1   Package name 1.1.1   Other package names 1.2   Class and interface name 1.3   Getters and setters name 1.4   Module 1.4.1   Data Interface 1.4.2   Service Interface 1.5   Typedef 1.5.1   Type's valid arguments 1.5.1.1   Enumeration's substatement enum 1.5.1.2   Bits's substatement bit 1.5.1.3   Union's substatement type 1.5.2   String mapping 1.6   Container 1.7   Leaf 1.8   Leaf-list 1.9   List 1.10   Choice and case 1.11   Grouping and uses 1.12   Rpc 1.13   Notification 1.14   Augment 1.15   Identity Package name The package name consists from following parts: opendaylight prefix  - every package name starts with prefix  org.opendaylight.yang.gen.v1  which is hardcoded in  BindingGeneratorUtil.moduleNamespaceToPackageName() . YANG version  - is specified through...
阅读全文

OpenDaylight架构简介

图片
在我们跳入代码之前，需要对OpenDaylight控制器进行高级概述。 OpenDaylight是一个模块化平台，大多数模块 reusing  一些常见的服务和接口。 每个模块都是在多供应商子项目下开发的。 你可以在这里找到项目的列表。 在OpenDaylight平台上构建应用程序的想法是利用其他平台包中的功能，每个平台包都通过Java接口导出重要的服务。 许多这些服务是在称为MD-SAL的适应层上在提供者 - 消费者模型中构建的。 在OpenDaylight的核心编程中的MD-SAL数据存储涉及采用用于SDN应用开发的模型 - 视图 - 控制方法： 1. YANG Model for  数据，RPC和通知 （ YANG Model for data, RPC and notifications ） 2.REST API视图通过RESTconf实现自动生成和访问 3.Java编码处理数据更改，通知和RPC回调 （ Java Implementation coded to handle data changes, notifications and RPC call backs） 3.1模型驱动的SAL（MD-SAL） 模型驱动的服务适配层（MD-SAL）是平台的内核，不同的 层和模块通过API互连 。 以下是关于MD-SAL的一些重要注意事项：    1. 每个API都 是在构建期间从 YANG语言中定义的模型生成的 ，并且当模型包（ model bundle ）装入到Karaf平台时 加载到控制器中 。   2.在平台的核心是逻辑集中的数据存储，其将相关状态保持在两个桶中 - 1）配置数据存储，2）操作数据存储。   3.使用MD-SAL映射逻辑， 所有事件调用和数据通过此中央数据存储区从“提供者”到“消费者” 。 3.2  YANG  模型 OpenDaylight大量使用YANG来 建模在不同模块间的数据 ，通知或  remote procedure call  （RPC）。 对于那些不熟悉YANG的学生，我们建议您通过Tail-F系统学习YANG教程。 简而言之，YANG是一种用于描述存储在容器...
阅读全文