RYU基础整理

时间  2019-12-01
标签 ryu 基础 整理 繁體版
原文   原文链接

1. RYU结构，源码

1.1 RYU文件目录

　　下面介绍ryu/ryu目录下的主要目录内容。html

base

　　base中有一个很是重要的文件：app_manager.py，其做用是RYU应用的管理中心。用于加载RYU应用程序，接受从APP发送过来的信息，同时也完成消息的路由。python

　　其主要的函数有app注册、注销、查找、并定义了RYUAPP基类，定义了RYUAPP的基本属性。包含name, threads, events, event_handlers和observers等成员，以及对应的许多基本函数。如：start(), stop()等。web

　　这个文件中还定义了AppManager基类，用于管理APP。定义了加载APP等函数。不过若是仅仅是开发APP的话，这个类能够没必要关心。shell

controller——实现controller和交换机之间的互联和事件处理

　　controller文件夹中许多很是重要的文件，如events.py, ofp_handler.py, controller.py等。其中controller.py中定义了OpenFlowController基类。用于定义OpenFlow的控制器，用于处理交换机和控制器的链接等事件，同时还能够产生事件和路由事件。其事件系统的定义，能够查看events.py和ofp_events.py。编程

　　在ofp_handler.py中定义了基本的handler（应该怎么称呼呢？句柄？处理函数？），完成了基本的如：握手，错误信息处理和keep alive 等功能。更多的如packet_in_handler应该在app中定义。api

　　在dpset.py文件中，定义了交换机端的一些消息，如端口状态信息等，用于描述和操做交换机。如添加端口，删除端口等操做。数组

lib——网络基本协议的实现和使用

　　lib中定义了咱们须要使用到的基本的数据结构，如dpid, mac和ip等数据结构。在lib/packet目录下，还定义了许多网络协议，如ICMP, DHCP, MPLS和IGMP等协议内容。而每个数据包的类中都有parser和serialize两个函数。用于解析和序列化数据包。cookie

　　lib目录下，还有ovs, netconf目录，对应的目录下有一些定义好的数据类型，再也不赘述。网络

ofproto

　　在这个目录下，基本分为两类文件，一类是协议的数据结构定义，另外一类是协议解析，也即数据包处理函数文件。如ofproto_v1_0.py是1.0版本的OpenFlow协议数据结构的定义，而ofproto_v1_0_parser.py则定义了1.0版本的协议编码和解码。数据结构

topology——交换机和链路的查询模块

　　包含了switches.py等文件，基本定义了一套交换机的数据结构。event.py定义了交换上的事件。dumper.py定义了获取网络拓扑的内容。最后api.py向上提供了一套调用topology目录中定义函数的接口。

contrib——第三方库

　　这个文件夹主要存放的是开源社区贡献者的代码。

cmd——入口函数

　　定义了RYU的命令系统，为controller的执行建立环境，接收和处理相关命令

services

　　完成了BGP和vrrp的实现。

tests

　　tests目录下存放了单元测试以及整合测试的代码。

 

1.2 RYU 架构

RYU SDN 架构：

 

 

 

组件功能：

 

1.3 应用程序编程模型

Ryu 事件处理、进程与线程：
　　1) Applications：该类继承自ryu.base.app_manager.RyuApp，用户逻辑被描述为一个APP。
　　2) Event ： 继承自ryu.controller.event.EventBase ， 应用程序之间的通讯由transmitting and receiving events 完成。
　　3) Event Queue：每个application 都有一个队列用于接收事件。
　　4) Threads：Ryu 使用第三方库eventlets 运行多线程。由于线程是非抢占式的，所以，当执行耗时的处理程序时要很是当心。
　　5) Event loops： 建立一个application 时，会自动生成一个线程，该线程运行一个事件循环。当队列事件不为空时，这个事件循环会加载该事件而且调用相应的事件处理函数（注册以后）。
      6) Additional threads：可使用hub.spawn()添加其它线程，用来处理特殊的应用

      7) Eventlets：这是一个第三方库，里面的库函数被封装到hub 模块中被开发人员加载使用。【提供线程和事件队列的实现】
      8) Event handlers：使用ryu.controller.handler.set_ev_cls 修饰一个事件处理函数。当该类型的事件触发后，事件处理函数就会被应用程序的事件循环调用。


 

 

1.4  OpenFlow的解析和封装

Ofp_handler

　　负责底层数据通讯的模块是ofp\_handler模块。ofp\_handler启动以后，start函数实例化了一个controller.OpenFlowController实例。OpenFlowController实例化以后，当即调用\__call\__()函数，call函数启动了server\_loop去建立server socket，其handler为domain\_connection\_factory函数。每当收到一个switch链接，domain\_connection\_factory就会实例化一个datapath对象。这个对象用于描述交换机的全部行为。其中定义了接收循环和发送循环。

Datapath

　　datapath.serve函数是socket通讯收发逻辑的入口。该函数启动了一个绿色线程去处理发送循环，而后本线程负责接收循环的处理。self.\_send\_loop是发送主循环。其主要逻辑为：不断获取发送队列是否有数据，如有，则发送；底层调用的是socket.send\_all（）函数。

　　接收函数\_reck\_loop中实现了数据的接收和解析。 

@_deactivate
        def _recv_loop(self):
            buf = bytearray()   #初始化一个字节数组
            required_len = ofproto_common.OFP_HEADER_SIZE   # ofproto_common模块定义了OpenFlow经常使用的公共属性         
                                                            # 如报头长度=8
            count = 0
            while self.is_active:
                ret = self.socket.recv(required_len)
                if len(ret) == 0:
                    self.is_active = False
                    break
                buf += ret
                while len(buf) >= required_len:
                    # ofproto_parser是在Datapath实例的父类ProtocolDesc的属性。
                    # 用于寻找对应协议版本的解析文件,如ofproto_v1_0_parser.py
                    # header函数是解析报头的函数。定义在ofproto_parser.py。
                    (version, msg_type, msg_len, xid) = ofproto_parser.header(buf)
                    required_len = msg_len
                    if len(buf) < required_len:
                        break
                    # ofproto_parser.msg的定义并无在对应的ofproto_parser中
                    # msg函数的位置和header函数位置同样，都在ofproto_parser.py中。
                    # msg返回的是解析完成的消息。
                    # msg函数返回了msg_parser函数的返回值
                    # ofproto_parser.py中的_MSG_PARSERS记录了不一样版本对应的msg_parser。其注册手法是经过@ofproto_parser.register_msg_parser(ofproto.OFP_VERSION)装饰器。
                    # 在对应版本的ofproto_parser,如ofproto_v1_0_parser.py中，都有定义一个同名的_MSG_PARSERS字典，这个字典用于记录报文类型和解析函数的关系。此处命名不恰当，引入混淆。
                    # parser函数经过@register_parser来将函数注册/记录到_MSG_PARSERS字典中。
                    
                    msg = ofproto_parser.msg(self,
                                             version, msg_type, msg_len, xid, buf)
                    # LOG.debug('queue msg %s cls %s', msg, msg.__class__)
                    if msg:
                        # Ryu定义的Event system很简单，在报文名前加上前缀“Event”,便是事件的名称。
                        # 同时此类系带msg信息。
                        # 使用send_event_to_obserevrs()函数将事件分发给监听事件的handler，完成事件的分发。
                        ev = ofp_event.ofp_msg_to_ev(msg)
                        self.ofp_brick.send_event_to_observers(ev, self.state)
    
                        dispatchers = lambda x: x.callers[ev.__class__].dispatchers
                        # handler的注册是经过使用controller.handler.py文件下定义的set_ev_handler做为装饰器去注册。                
                        # self.ofp_brick在初始化时，由注册在服务列表中查找名为"ofp_event"的模块赋值。
                        # ofp_handler模块的名字为"ofp_event"，因此对应的模块是ofp_handler
                        handlers = [handler for handler in
                                    self.ofp_brick.get_handlers(ev) if
                                    self.state in dispatchers(handler)]
                        for handler in handlers:
                            handler(ev)
    
                    buf = buf[required_len:]
                    required_len = ofproto_common.OFP_HEADER_SIZE
    
                    # We need to schedule other greenlets. Otherwise, ryu
                    # can't accept new switches or handle the existing
                    # switches. The limit is arbitrary. We need the better
                    # approach in the future.
                    count += 1
                    if count > 2048:
                        count = 0
                        hub.sleep(0)　　

OpenFlow协议实现

　　OpenFlow协议解析部分代码大部分在ofproto目录下，少部分在controller目录下。首先介绍ofproto目录下的源码内容，再介绍controller目录下的ofp_event文件。

__init__

　　首先，__init__.py并不为空。该文件定义了两个功能相似的函数get_ofp_module()和get_ofp_modules()，前者用于取得协议版本对应的协议定义文件和协议解析模块，后者则取出整个字典。对应的字典在ofproto_protocol模块中定义。

ofproto\_protocol

　　在ofproto\_protocol定义了\_versions字典，具体以下：

_versions = {
        ofproto_v1_0.OFP_VERSION: (ofproto_v1_0, ofproto_v1_0_parser),
        ofproto_v1_2.OFP_VERSION: (ofproto_v1_2, ofproto_v1_2_parser),
        ofproto_v1_3.OFP_VERSION: (ofproto_v1_3, ofproto_v1_3_parser),
        ofproto_v1_4.OFP_VERSION: (ofproto_v1_4, ofproto_v1_4_parser),
    }

　　除此以外，该文件还定义了Datapath的父类ProtocolDesc，此类基本上只完成了与协议版本相关的内容。该类最重要的两个成员是self.ofproto和self.ofproto\_parser，其值指明所本次通讯所使用的OpenFlow协议的版本以及对应的解析模块。

ofproto\_common

　　ofproto\_common文件比较简单，主要定义了OpenFlow须要使用的公共属性，如监听端口，报头长度，报头封装格式等内容。

ofproto\_parser

　　ofproto\_parser文件定义了全部版本都须要的解析相关的公共属性。如定义了最重要的基类MsgBase(StringifyMixin)。

　　StringifyMixin类的定义在lib.stringify文件，有兴趣的读者可自行查看。MsgBase基类定义了最基础的属性信息，具体以下所示：

　　此外，该类还定义了基础的parser函数和serialize函数。基础的parser函数基本什么都没有作，仅返回一个赋值后的消息体。

　　serialize函数分为3部分，self.\_serialize\_pre(), self.\_serialize\_body()和self.\_serialize\_header()。本质上完成了header的序列化。关于body的序列化，将在对应的派生类中获得重写。

ofproto_v1_0

　　以1.0版本为例介绍ofproto\_v1\_x.py文件的做用。因为Ryu支持多版本的OpenFlow，因此在ofproto目录下，定义了从1.0到1.5版本的全部代码实现。因此其文件命名为ofproto\_v1_x.py，x从[1,2,3,4,5]中得到，分别对应相应的协议版本。

　　此类文件最重要的一个目的是定义了全部须要的静态内容，包括某字段的全部选项以及消息封装的格式以及长度。与OpenFlow消息内容相关的有协议的类型，动做的类型，port的类型等。此外对应每个报文，都须要定义其封装的格式，以及封装的长度。Ryu采用了Python的Struct库去完成数据的解封装工做，关于Struct的介绍将在后续内容介绍。具体定义内容举例以下：

　　OFP\_HEADER\_PACK\_STR = '!BBHI'的意思是将header按照8|8|16|32的长度封装成对应的数值。在Python中分别对应的是1个字节的integer|一个字节的integer|2个字节的integer|4个字节的integer。

　　calcsize函数用于计算对应的format的长度。

ofproto_v1_0_parser

　　本模块用于定义报文的解析等动态内容。模块中定义了与OpenFlow协议对应的Common\_struct及message type对应的类。每个message对应的类都是有MsgBase派生的，其继承了父类的parser函数和serialize函数。若报文无消息体，如Hello报文，则无需重写parser和serialize函数。

　　本模块定义了几个重要的全局函数：\_set\_msg\_type，\_register\_parser，msg\_parser和\_set\_msg\_reply。其做用介绍以下：

  • _set_msg_type: 完成类与ofproto模块中定义的报文名字的映射，缘由在于ofproto模块定义的名字并非类名，而解析时须要使用ofproto中的名字。
  • _register_parser：完成对应的类与类中的parser函数的映射，当解析函数从ofproto模块的名字映射到类以后，若须要解析，则需从类对应到对应的解析函数。parser函数是一个类函数，因此在使用时必须传入对应的类的对象做为参数。
  • msg_parser：从_MSG_PARSERS中获取对msg_type的parser，并返回解析以后的内容。
  • _set_msg_reply：完成该类与对应的回应报文的映射。
def _set_msg_type(msg_type):
        '''Annotate corresponding OFP message type'''
        def _set_cls_msg_type(cls): cls.cls_msg_type = msg_type return cls return _set_cls_msg_type def _register_parser(cls): '''class decorator to register msg parser''' assert cls.cls_msg_type is not None assert cls.cls_msg_type not in _MSG_PARSERS _MSG_PARSERS[cls.cls_msg_type] = cls.parser return cls @ofproto_parser.register_msg_parser(ofproto.OFP_VERSION) def msg_parser(datapath, version, msg_type, msg_len, xid, buf): parser = _MSG_PARSERS.get(msg_type) return parser(datapath, version, msg_type, msg_len, xid, buf) def _set_msg_reply(msg_reply): '''Annotate OFP reply message class''' def _set_cls_msg_reply(cls): cls.cls_msg_reply = msg_reply return cls return _set_cls_msg_reply

　　报文若是有消息体，则须要重写parser函数或者serialize函数，具体根据报文内容而不同。此处，分别以Packet\_in和Flow\_mod做为parser的案例和serialize的案例，示例以下： 

　　此模块代码量大，包括OpenFlow协议对应版本内容的彻底描述。分类上可分为解析和序列化封装两个重点内容。读者在阅读源码时可根据需求阅读片断便可。

Inet & ether

　　这两个模块很是简单，ether定义了经常使用的以太网的协议类型及其对应的代码；inet定义了IP协议族中不一样协议的端口号，如TCP=6。

oxm_field

　　在1.3等高版本OpenFlow中，使用到了oxm\_field的概念。oxm全称为OpenFlow Extensible Match。当OpenFlow逐渐发展成熟，flow的match域愈来愈多。然而不少通讯场景下使用到的匹配字段不多，甚至只有一个。OXM是一种TLV格式，使用OXM能够在下发流表时仅携带使用到的match域内容，而放弃剩余的大量的match域。当使用的match域较少时，统计几率上会减小报文传输的字节数。

nx_match

　　该文件定义了nicira extensible match的相关内容。

ofp_event

　　这个模块的位置并再也不ofproto，而位于controller目录下。controller模块下的event定义了基础的事件基类。ofp\_event模块完成了OpenFlow报文到event的生成过程。模块中定义了EventOFPMsgBase(event.EventBase)类和\_ofp\_msg\_name\_to\_ev\_name(msg\_name)等函数的定义。相关函数都很是的简单，可从函数名了解到其功能。示例代码以下：

def _ofp_msg_name_to_ev_name(msg_name):
        return 'Event' + msg_name

Struct lib

　　Python的struct库是一个简单的，高效的数据封装\解封装的库。该库主要包含5个函数，介绍以下：

  • struct.pack(fmt, v1, v2, ...)： 将V1,V2等值按照对应的fmt(format)进行封装。
  • struct.pack_into(fmt, buffer, offset, v1, v2, ...)：将V1,V2等值按照对应的fmt(format)封装到buffer中，从初始位置offset开始。
  • struct.unpack(fmt, string): 将string按照fmt的格式解封
  • struct.unpack_from(fmt, buffer[offset=0，])： 按照fmt的格式，从offset开始将buffer解封。
  • struct.calcsize(fmt)： 计算对应的fmt的长度。

　　更详细的封装语法，请查看struct对应的连接。此处仅对经常使用语法进行介绍：

  • ！：大端存储
  • c: char
  • B： 一个字节长度，unsigned char.
  • H：两个字节，16位
  • I： 4个字节，int型
  • Q: 64bits
  • x: padding
  • 3x：3个字节的padding
  • 5s: 5字节的字符串

 

 

 

 

1.5  Ryu的处理流程

  •  入口函数执行流程

  • 事件处理流程

  • 补充说明

 

 

 

1.6  ryu运行

 　　从main函数入手，讲述RYU的ryuapp基类细节、app_manager类如何load apps，注册并运行application，Event的产生以及分发，还有最重要的应用ofp_handler。

main()

　　RYU的main函数在ryu/cmd/manager.py文件中，部份内容以下：

　　首先从CONF文件中读取出app list。若是ryu-manager 命令任何参数，则默认应用为ofp_handler应用。紧接着实例化一个AppManager对象，调用load_apps函数将应用加载。调用create_contexts函数建立对应的contexts, 而后调用instantiate_apps函数将app_list和context中的app均实例化。启动wsgi架构，提供web应用。最后将全部的应用做为任务，做为coroutine的task去执行，joinall使得程序必须等待全部的task都执行完成才能够退出程序。最后调用close函数，关闭程序，释放资源。如下的部分将以主函数中出现的调用顺序为依据，展开讲解。

OFPHandler

　　上文说到，若是没有捕获Application输入，那么默认启动的应用是OFPHandler应用。该应用主要用于处理OpenFlow消息。在start函数初始化运行了一个OpenFlowController实例。OpenFlowController类将在后续介绍。

　　OFPHandler应用完成了基本的消息处理，如hello_handler：用于处理hello报文，协议版本的协商。其处理并不复杂，可是值得注意的一点是装饰器：Decorator的使用。

Decorator

　　Python修饰器的函数式编程 Python Decorator能够看做是一种声明，一种修饰。如下举例参考自Coolshell。举例以下：

　　实际上等同于foo = decorator(foo), 并且它还被执行了。举个例子：

　　运行以后，就会输出   you  EVOL me

　　多个decorator:

　　这至关于：

　　而带参数的decorator:

　　至关于

　　decorator(arg1,arg2)将生成一个decorator。

class式的 Decorator

class myDecorator(object):

    def __init__(self, fn):
        print "inside myDecorator.__init__()"
        self.fn = fn

    def __call__(self):
        self.fn()
        print "inside myDecorator.__call__()"


@myDecorator
def aFunction():
    print "inside aFunction()"

print "Finished decorating aFunction()"

aFunction()


#结果：

>>>
inside myDecorator.__init__()
Finished decorating aFunction()
inside aFunction()
inside myDecorator.__call__()
>>> 

 

　　@decorator使用时，__init__被调用，当function被调用是，执行__call__函数，而不执行function,因此在__call__函数中须要写出self.fn = fn，更多内容能够直接访问Python Decorator Library。

OpenFlowController

　　前一部分提到OFPHandle的start函数会将OpenFlowController启动。本小节介绍OpenFlowController类。该类的定义在ryu/cmd/controller.py文件中。OpenFlowController.__call__()函数启动了server_loop()函数，该函数实例化了hub.py中的StreamServer类，并将handler函数初始化为datapath_connection_factory函数，并调用serve_forever()，不断进行socket的监听。StreamServer定义以下：

Datapath

　　Datapath类在RYU中极为重要，每当一个datapath实体与控制器创建链接时，就会实例化一个Datapath的对象。 该类中不只定义了许多的成员变量用于描述一个datapath，还管理控制器与该datapath通讯的数据收发。其中_recv_loop函数完成数据的接收与解析，事件的产生与分发。

　　@_deactivate修饰符做用在于在Datapath断开链接以后，将其状态is_active置为False。self.ofp_brick.send_event_to_observers(ev, self.state) 语句完成了事件的分发。self.brick的初始化语句能够在self.__init__函数中找到：

　　由上可知，self.ofp_brick其实是由service_brick（中文能够成为：服务链表？）中的“ofp_event”服务赋值的。在每个app中，使用@set_ev_cls(ev_cls,dispatchers)时，就会将实例化ofp_event模块，执行文件中最后一句：

　　register_service函数实体以下：

　　其中inspect.stack()[1]返回了调用此函数的caller, inspect.getmodule(frm[0])返回了该caller的模块，当前例子下，module=ofp_event。

　　咱们能够经过ryu-manager --verbose来查看到输出信息，从而印证这一点。

　　因此当运行ofp_handler应用时，就会注册ofp_event service，为后续的应用提供服务。分发事件以后，还要处理自身订阅的事件，因此首先找到符合当前state的caller,而后调用handler。_caller类能够在handler.py文件中找到，包含dispatchers和ev_source两个成员变量。前者用于描述caller须要的state,后者是event产生者的模块名称。

　　对应的发送循环由_send_loop完成。self.send_p是一个深度为16的发送queue。

　　serve函数完成了发送循环的启动和接受循环的启动。启动一个coroutine去执行self._send_loop()， 而后立刻主动发送hello报文到datapath(能够理解为交换网桥：Bridge)，最后执行self._recv_loop()。

　　而serve函数又在datapath_connection_factory函数中被调用。固然向外提供完整功能的API就是这个。因此在OpenFlowController类中能够看到在初始化server实例的时候，handler赋值为datapath_connection_factory。其中使用到的contextlib module具体内容不做介绍，读者可自行学习。

　　到此为止，OFPHandler应用的功能实现介绍完毕。RYU启动时，须要启动OFPHandler，才能完成数据的收发和解析。更多的上层应用逻辑都是在此基础之上进行的。若要开发APP则须要继承RyuApp类，并完成observer监听事件，以及注册handler去完成事件处理。

RyuApp

　　RyuApp类是RYU封装好的APP基类，用户只须要继承该类，就能够方便地开发应用。而注册对应的observer和handler都使用@derocator的形式，使得开发很是的简单高效，这也是Python的优势之一吧。RyuApp类的定义在ryu/base/app_manager.py文件中。该文件实现了两个类RyuApp和AppManager。前者用于定义APP基类，为应用开发提供基本的模板，后者用于Application的管理，加载应用，运行应用，消息路由等功能。

　　app_manager.py文件中import了instpect和itertools module，从而使得开发更方便简洁。inspect模块提供了一些有用的方法，用于类型检测，获取内容，检测是否可迭代等功能。itertools则是一个关于迭代器的模块，能够提供丰富的迭代器类型，在数据处理上尤为有用。

_CONTEXT

　　这是一个极其难理解的概念。博主的理解是，_CONTEXT内存储着name:class的key value pairs。为何须要存储这个内容？实际上这个_CONTEXT携带的信息是全部本APP须要依赖的APP。须要在启动本应用以前去启动，以知足依赖的，好比一个simple_switch.py的应用，若是没有OFPHandler应用做为数据收发和解析的基础的话，是没法运行的。具体文档以下：

_EVENTS

　　用于记录本应用会产生的event。可是当且仅当定义该event的语句在其余模块时才会被使用到。

self.__init__

　　__init__函数中初始化了许多重要的成员变量，如self.event_handler用于记录向外提供的事件处理句柄，而self.observer则恰好相反，用于通知app_manager本应用监听何种类型的事件。self.event是事件队列。

self.start

　　start函数将启动coroutine去处理_event_loop，并将其加入threads字典中。

self._event_loop

　　_event_loop函数用于启动事件处理循环，经过调用self.get_handlers(ev, state)函数来找到事件对应的handler，而后处理事件。

event dispatch

　　应用中能够经过@set_ev_cls修饰符去监听某些事件。当产生event时，经过event去get observer，获得对应的观察者，而后再使用self.send_event函数去发送事件。在这里，实际上就是直接往self.event队列中put event。

　　其余函数如注册handler函数：register_handler，注册监听函数：register_observer等都是很是简单直白的代码，再也不赘述。

AppManager

　　AppManager类是RYU应用的调度中心。用于管理应用的添加删除，消息路由等等功能。

　　首先从启动函数开始介绍，咱们能够看到run_apps函数中的代码和前文提到的main函数语句基本同样。首先获取一个对象，而后加载对应的apps，而后获取contexts，context中其实包含的是本应用所须要的依赖应用。因此在调用instantiate_apps函数时，将app_lists内的application和contexts中的services都实例化，而后启动协程去运行这些服务。

load_apps

　　首先从建立一个apps_lists的生成器（我的理解应该是生成器而非迭代器）。在while循环中，每次pop一个应用进行处理，而后将其自己和其context中的内容添加到services中，再去调用get_dependent_services函数获取其依赖应用，最后将全部的依赖services添加到app_lists中，循环至最终app_lists内元素全都pop出去，完成application的加载。

create_contexts

　　context实例化函数将context中name:service class键值对的内容实例化成对应的对象，以便加入到services 列表中，从而获得加载。首先从列表中取出对应数据，而后判断是否时RyuApp的子类，是则实例化，不然直接赋值service class。load_app函数在读取的时候还会再次判断是不是RyuApp子类。

instantiate_apps

　　此函数调用了self._instantiate函数，在_instantiate函数中又调用了register_app()函数，此函数将app添加到SERVICE_BRICKS字典之中，而后继续调用了ryu.controller.handler 中的 register_instance函数，最终完成了应用的注册。此后继续调用self._update_bricks函数完成了服务链表的更新，最后启动了全部的应用。

_update_bricks

　　此函数完成了更新service_bricks的功能。首先从获取到service实例，而后再获取到service中的方法，若方法有callers属性，即便用了@set_ev_cls的装饰符，拥有了calls属性。（caller类中的ev_source和dispatcher成员变量描述了产生该event的source module， dispatcher描述了event须要在什么状态下才能够被分发。如：HANDSHAKE_DISPATCHER，CONFIG_DISPATCHER等。）最后调用register_observer函数注册了observer。

ryu.controller.handler.register_instance

　　以上的部分介绍了App的注册，observer的注册，handler的查找和使用，可是，始终没有提到handler在何处注册。实际上，handler的注册在register_instance部分完成了。为何他的位置在handler文件，而不在app_manager文件呢？我的认为多是为了给其余非Ryu APP的模块使用吧。

 

2. RYU实践

2.1 二层交换机

　　　　http://ryu.readthedocs.org/en/latest/writing_ryu_app.html

第一步：

ryu.base import app_manager：该文件中定义了RyuApp基类，开发APP须要继承该基类；

保存为L2Switch.py    运行： ryu-manager L2Switch.py

from ryu.base import app_manager

class L2Switch(app_manager.RyuApp):
    def __init__(self, *args, **kwargs):
        super(L2Switch, self).__init__(*args, **kwargs)

 

第二步：

ofp_event完成了事件的定义，从而咱们能够在函数中注册handler，监听事件，并做出回应。

packet_in_handler方法用于处理packet_in事件。

@set_ev_cls修饰符用于告知RYU，被修饰的函数应该被调用。第一个参数表示事件发生时应该调用的函数，第二个参数告诉交换机只有在交换机握手完成以后，才能够被调用。

 

数据操做：

  • ev.msg：每个事件类ev中都有msg成员，用于携带触发事件的数据包。
  • msg.datapath：已经格式化的msg其实就是一个packet_in报文，msg.datapath直接能够得到packet_in报文的datapath结构。datapath用于描述一个交换网桥。也是和控制器通讯的实体单元。datapath.send_msg()函数用于发送数据到指定datapath。经过datapath.id可得到dpid数据，在后续的教程中会有使用。
  • datapath.ofproto对象是一个OpenFlow协议数据结构的对象，成员包含OpenFlow协议的数据结构，如动做类型OFPP_FLOOD。
  • datapath.ofp_parser则是一个按照OpenFlow解析的数据结构。
  • actions是一个列表，用于存放action list，可在其中添加动做。
  • 经过ofp_parser类，能够构造构造packet_out数据结构。括弧中填写对应字段的赋值便可。

若是datapath.send_msg()函数发送的是一个OpenFlow的数据结构，RYU将把这个数据发送到对应的datapath。

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls

class L2Switch(app_manager.RyuApp):
    def __init__(self, *args, **kwargs):
        super(L2Switch, self).__init__(*args, **kwargs)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofp = datapath.ofproto
        ofp_parser = datapath.ofproto_parser

        actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]
        out = ofp_parser.OFPPacketOut(
            datapath=datapath, buffer_id=msg.buffer_id, in_port=msg.in_port,
            actions=actions)
        datapath.send_msg(out)

 

第三步：

import struct
import logging

from ryu.base import app_manager
from ryu.controller import mac_to_port
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_0
from ryu.lib.mac import haddr_to_bin
from ryu.lib.packet import packet
from ryu.lib.packet import ethernet

class L2Switch(app_manager.RyuApp):

    OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION]#define the version of OpenFlow

    def __init__(self, *args, **kwargs):
        super(L2Switch, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

    def add_flow(self, datapath, in_port, dst, actions):
        ofproto = datapath.ofproto

        match = datapath.ofproto_parser.OFPMatch(
            in_port = in_port, dl_dst = haddr_to_bin(dst))

        mod = datapath.ofproto_parser.OFPFlowMod(
            datapath = datapath, match = match, cookie = 0,
            command = ofproto.OFPFC_ADD, idle_timeout = 10,hard_timeout = 30,
            priority = ofproto.OFP_DEFAULT_PRIORITY,
            flags =ofproto.OFPFF_SEND_FLOW_REM, actions = actions)

        datapath.send_msg(mod)

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocol(ethernet.ethernet)

        dst = eth.dst
        src = eth.src

        dpid = datapath.id    #get the dpid
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst , msg.in_port)
        #To learn a mac address to avoid FLOOD next time.

        self.mac_to_port[dpid][src] = msg.in_port


        out_port = ofproto.OFPP_FLOOD

        #Look up the out_port 
        if dst in self.mac_to_port[dpid]:
            out_port = self.mac_to_port[dpid][dst]

        ofp_parser = datapath.ofproto_parser

        actions = [ofp_parser.OFPActionOutput(out_port)]

        if out_port != ofproto.OFPP_FLOOD:
            self.add_flow(datapath, msg.in_port, dst, actions)


        #We always send the packet_out to handle the first packet.
        packet_out = ofp_parser.OFPPacketOut(datapath = datapath, buffer_id = msg.buffer_id,
            in_port = msg.in_port, actions = actions)
        datapath.send_msg(packet_out)
    #To show the message of ports' status.
    @set_ev_cls(ofp_event.EventOFPPortStatus, MAIN_DISPATCHER)
    def _port_status_handler(self, ev):
        msg = ev.msg
        reason = msg.reason
        port_no = msg.desc.port_no

        ofproto = msg.datapath.ofproto

        if reason == ofproto.OFPPR_ADD:
            self.logger.info("port added %s", port_no)
        elif reason == ofproto.OFPPR_DELETE:
            self.logger.info("port deleted %s", port_no)
        elif reason == ofproto.OFPPR_MODIFY:
            self.logger.info("port modified %s", port_no)
        else:
            self.logger.info("Illeagal port state %s %s", port_no, reason)

 

2.2 simple-switch.py 的APP测试

　　在mininet上模拟一台交换机（s1）三台主机（h1,h2,h3），而后远端链接RYU控制器，使用127.0.0.1，和6633端口创建链接

　　第一，在RYU控制器开启simple-switch.py的APP，输入命令：ryu-manager simple-switch.py：

　　第二，在另一个终端上创建mininet模拟拓扑，输入命令：mn --topo single,3 --mac --switch ovsk --controller remote

　　         而后在RYU的那个终端就会显示链接的创建，同时，也会同步一些交换机和控制器创建链接的信息，如图：

　　此时，在交换机的转发流表是空的，所以此时主机之间是不能够通讯的，在使用h1去ping h2的时候，就会自动创建流表

　　注意是先进行广播，而后创建反方向的流表，而后创建正方向的流表。流表如图：

 

 

 

 

 

资料出处：

　　http://ryu.readthedocs.org/en/latest/api_ref.html

　　http://www.sdnlab.com/6395.html

　　http://www.sdnlab.com/12838.html

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程