【SDNLAB独家译稿】（接本系列上一篇《OpenVirteX体系结构之操作与子系统（一）》，本文翻译第三章3.3-3.4小节，其他部分的翻译会陆续发布。）

3.3 事件循环

本节对核心I/O循环操作进行概述。

3.3.1 概述

OVX事件循环进行OpenFlow消息的处理。事件循环的主要角色是：

• 完成datapath和租户控制器的OpenFlow握手（初始化）：如前所述，OVX实现控制器端和交换机端的OpenFlow握手来建立OVX与datapath、OVX与租户控制器之间的控制信道。
• OpenFlow消息的虚拟化与去虚拟化：对于每个OpenFlow消息都必须跨物理-虚拟区域，OVX必须能够正确查找其必须写入的控制器通道，并在有必要时，重写该消息域以保持不同租户网络视图的一致性。OVX也可以通过查找接收到网络侧消息的datapath，重写消息，以及解决租户头空间之间的重叠，来逆转这个过程。重写消息不仅保证与PhysicalNetwork网络视图一致，也可使租户之间的流量隔离。
• 处理到/从数据通路（datapath）和控制器的keep－alives消息：datapath和控制器在空闲时交换echo request/reply消息。OVX在单一通道上处理这些消息。

事件循环当前的实现依赖于网络的异步I/O和Java执行的线程池。这是处理API调用的一个单独的循环。

3.3.2消息处理与虚拟化（去虚拟化）

OVXMessage实现了如下一个或两个接口：
虚拟化：virtualize(PhysicalSwitch sw)：控制器侧消息
去虚拟化：devirtualize(OVXSwitch sw)：网络侧消息

这些接口方法的参数均为已从各自信道上接收到消息的交换机实例。不跨虚拟与物理分界的消息，如握手消息与keep－alives(OVXEchoRequestReply)消息并没有virtualize()和devirtualize()方法 。穿过分界的消息依次在各自的devirtualize()和virtualize()方法中实现虚拟到物理和物理到虚拟的转化过程。

这些方法被handleIO()调用，交换机抽象方法在PhysicalSwitch和OVXSwitch中实现。

OVXMessage方法实际的调用发生在物理交换机与虚拟交换机的有限状态机处于ACTIVE的状态时：

PhysicalSwitch.Switchstate.ACTIVE:

OVXSwitch.Switchstate.ACTIVE:

FSM的默认行为是发出警告和丢弃消息。

图3.5总结了事件循环的高级视图。

图3.5： 核心OVX事件循环，显示了通过OVX的主要消息处理路径。蓝色、绿色、橙色块在逻辑上分别表示虚拟、全局和物理组件。灰色的步骤出现在SwitchChannelHandler（橙色区域）和ControllerChannelHandler（蓝色区域）。蓝色箭头表示OpenFlow信道。

每个消息具体如何被virtualize()或devirtualize()处理取决于各自的OvxMessage类如何定义这些方法。此处我们不会涉及到每一个消息，但当出现特定的消息时再做集中讨论。

3.4 网络发现与呈现

为完成精确的虚拟化，OVX必须保持网络状态视图的更新。这包括：

1.探测拓扑和流表变化
2.网络变化及时更新到物理网络和物理交换机上
3.检测，并在必要时，将变化应用到租户网络

OVX不仅完成拓扑发现，而且将虚拟拓扑呈现给租户。这些均通过操作LLDP实现。前两节内容描述了OVX如何通过网络拓扑和状态来保持物理网络同步。然后描述了OVX如何给租户控制器呈现虚拟网络，以使租户产生他们正在控制真实网络的错觉。

3.4.1 拓扑发现/LLDP 处理

物理LLDP处理。从网络中接收到的LLDP消息或是发到网络中的LLDP消息由SwitchDiscoveryManager处理。先前提到，SwitchDiscoveryManager与PhysicalSwitch 链路对保存在PhysicalNetwork.discoveryManager。在每个可能的毫秒级，每一个SwitchDiscoveryManager经由它配对的交换机发送出LLDP。默认1000毫秒，该参数定义在SwitchDiscoveryManager构造函数中。由于LLDP包会被邻近的交换机拦截同时上传到OVX上，SwitchChannelHandler通过调用PhysicalNetwork.HandleLLDP()来拦截他们。这个方法通过LLDPEventHandler [net.onrc.openvirtex.core.io]接口定义，由网络超类实现。HandleLLDP()调用已收到LLDP包的物理交换机配对的SwitchDiscoveryManager。SwitchDiscoveryManager的整体行为说明如下：

更新物理网络。SwitchDiscoveryManager.run()在毫秒级内更新拓扑结构。OVX定义了两种类型的端口：

• fast：成功接收LLDP的端口（也就是说是链路的终端）
• slow：发送MAX_PROBE_COUNT数量的LLDP包未被确认的端口（也就是说，端口是边缘端口，或者端口并不是链路的一部分。MAX_PROBE_COUNT当前值为3）

接收到LLDP报文的端口被认为是快速端口，在接收方的交换机的SwitchDiscoveryManager上设置快速端口，对于每个由快速端口发送的LLDP报文，其探测计数将会递增。相反地，报文被确认后，计数则会递减。探测计数存储在Map<Short, AtomicInteger> portProbeCount中。当端口的探测计数超过最大探测数MAX_PROBE_COUNT，将变成慢速端口。从慢速到快速端口的更新与探测计数的递减发生在SwitchDiscoveryManager.ackProbe()中，与之相反的情况在run()中实现。

3.4.2 PhysicalSwitch统计集合

先前提到，与物理交换机有关的统计有两种结构：

• AtomicReference<Map<Short, OVXPortStatisticsReply>> portStats；
• AtomicReference<Map<Integer, List>> flowStats;

这些映射通过StatisticsManager[net.onrc.openvirtex.elements.datapath.statistics]的物理交换机实例来完成，这个交换机轮询了OFFlowStatisticsRequests 和OFPortStatisticsRequests之间相应的datapath。

物理流表同步。在PhysicalSwitch中流表表示为PhysicalSwitch.flowStats结构，FlowStatisticsRequests通过定期轮询OFFlowStatisticsRequests相应的datapath来填充这个结构，这个过程是由每个StatisticsManager[net.onrc.openvirtex.elements]的PhysicalSwitch实例编排。当前轮询间隔30秒，由refreshInterval设置。除了流量统计，StatisticsManager还通过轮询OFPortStatisticsRequests的datapath来收集端口统计。

3.4.3 OVXNetwork呈现

虚拟拓扑呈现。OVX从运行自己的拓扑发现的租户控制器中接收到包含LLDP的PacketOut。来自租户的LLDP在OVXNetwork中处理。通过在虚拟域中处理LLDP，OVX显著减少了物理网络中的LLDP包的数量。

对于每个存在这种探测包的输出端口，OVXNetwork：

1.通过neighborPortMap查找目的端口
2.构造一个带有Inport的PacketIn到目的地
3.通过包含目的端口的OVXSwitch发送PacketIn到NOS

换言之，对于每一个租户拓扑，OVX模拟了网络中LLDP包广播、接收的过程。这个例程是由OVXNetwork.handleLLDP()实现。下图总结了这个过程。

后续更多精彩章节请看《OpenVirteX体系结构之操作与子系统（三）》！

译自：北邮FNL实验室张歌，http://ovx.onlab.us/documentation/architecture/