【SDNLAB独家译稿】接本系列上一篇《OpenVirteX体系结构之操作与子系统（二）》，本文翻译OpenVirteX第三章剩余部分。

3.5 网络虚拟化

在OVX中，虚拟化和去虚拟化是在虚拟层面与物理层面分界移动的逻辑动作，对于OpenFlow消息操作而言，这意味着一下几个步骤：

1.修改源和目的地网络地址；

2.从OVXSwitch/ OVXPort和PhysicalSwitch/ PhysicalPort的主机附着点转换到/；

3.丢弃来自或发送到给定虚拟和物理网络拓扑中的无效点（主机、交换机）的消息。

1 源于物理和虚拟网络为主机（IP地址）和交换机（DPIDs和端口号）所使用的不同寻址方案。2逻辑上遵循1，由于主机的连接点也会根据网络视图有不同的命名。3用来隔离虚拟网络之间的流量。本节提供了这三个过程中发挥作用的各种机制的描述。

3.5.1 交换机表示转换

在消息处理期间，虚拟化过程中的一个关键功能就是OVXSwitch和PhysicalSwitch之间的转换。

OVXSwitch->PyhsicalSwitch(南向):

OVXSwitch拦截租户控制器发送的南向消息。查询目的PhysicalSwitch的方法有以下两种：

通过入口OVXPort：PhysicalSwitch通过映射到OVXPort的PhysicalPort发现，该OVXPort通过消息中的端口字段发现，如：OFMatch结构中的in_port域。对于一个OVXBigSwitch来说，任何没有入端口的值都将被忽略。
通过OVXMap查询：对于一个OVXSingleSwitch，1:1的映射允许OVX通过租户ID在physicalSwitchMap上直接查询。

在每个OVXSwitch子类中实现的OVXSwitch.sendsouth()方法中查找。

PhysicalSwitch -> OVXSwitch (北向):

反向查找过程开发了OVX如何定义租户网络和如何进行OpenFlow通信。

租户网络：主机不能被连接到一个以上的OVXNetwork，主机可通过MAC地址作为唯一的标识。通过使用从OFMatch字段中得到的MAC地址，租户ID可以从OVXMap的macMap中取得。

OpenFlow通信：OpenFlow针对同一次会话中的多条消息里的某些字段使用相同的值，OVX可使用新值来代替南向消息的cookie、XID、buffer id字段，或者当接收到相应的应答时（北向）可被映射成原本的状态。下一节将进一步讨论字段转换的过程。

3.5.2 OpenFlow字段转换—Cookie，Buffer ID，XID

OVX使用下列几种结构来保持字段翻译中使用的映射：

XidTranslator [net.onrc.openvirtex.datapath] : LRULinkedHashMap<Integer, XidPair> xidMap
OVXFlowTable [net.onrc.openvirtex.datapath] : ConcurrentHashMap<Long, OVXFlowMod> flowmodMap
OVXSwitch : LRULinkedHashMap<Integer, OVXPacketIn> bufferMap

XIDTranslator.XID值必须在每一个datapath内是唯一的。XIDTranslator使用OpenFlow的XID来复用/解复用一个数据通路和多租户之间的通信。对于每个南向OVXMessage，XIDTranslator：

1.生成一个新的XID；

2.创建一个XidPair来存储原来的XID和源OVXSwitch；

3.在xidMap中使用新的XID作为键来存储XidPair；

4.给调用者返回新的XID。

XidTranslator.translate()实现以上的动作。调用者（PhysicalSwitch）用新的值来代替消息中的XID，这样一个datapath就仅有一个唯一的XID用于接收消息。对于北向消息，XIDTranslator：

1.恢复给定消息的XID的XidPair；

2.返回XidPair给调用者。

发起会话的租户可以从XidPair中的OVXSwitch得以恢复, 这个相反的过程由XidTranslator.untranslate()实现。

OVXFlowTable .OVXFlowTable以map形式存储新的流表项，该map以OVX生成的cookies作为key，对应的value是未被修改的OVXFlowMods，生成的Cookie用于编码源租户ID：

private long generateCookie() {
    ...
        final int cookie = this.cookieCounter.getAndIncrement();
        return (long) this.vswitch.getTenantId() &lt;&lt; 32 | cookie;
    }
}

private long generateCookie() {

...

final int cookie = this.cookieCounter.getAndIncrement();

return (long) this.vswitch.getTenantId() << 32 | cookie;

}

cookieCounter确保了OVXSwitch内cookie的唯一性。具体地讲，当FlowMod增加流表时被OVXFlowMod.devirtualize()分配一个新的cookie，新cookie在流表中作为匹配机制,也就是说当OVX接收FlowRemoved时，必须删除条目，以保持与网络的状态的一致性。

bufferMap.PacketIn/PacketOut引用同一个bufferID。在消息的转换过程中，需要将来自packet_in的buffer_id和生成的buffer_id存起来，当packet_out数据下发时，需要查找并转换。

// use bufferID of PacketOut to recover original (unmodified) PacketIn
final OVXPacketIn cause = sw.getFromBufferMap(this.bufferId);
…
// recover original OFMatch, packet data
this.match = new OFMatch().loadFromPacket(cause.getPacketData(),this.inPort);
this.setBufferId(cause.getBufferId());
ovxMatch = new OVXMatch(match);
ovxMatch.setPktData(cause.getPacketData());

// use bufferID of PacketOut to recover original (unmodified) PacketIn

final OVXPacketIn cause = sw.getFromBufferMap(this.bufferId);

…

// recover original OFMatch, packet data

this.match = new OFMatch().loadFromPacket(cause.getPacketData(),this.inPort);

this.setBufferId(cause.getBufferId());

ovxMatch = new OVXMatch(match);

ovxMatch.setPktData(cause.getPacketData());

如上所示，所存储的PacketIn内容被用来逆转之前虚拟化过程中地址、端口以及bufferID的转换。接下来讨论地址虚拟化的机制。

3.5.3 地址虚拟化

3.5.3.1 综述

OVX为每个主机创建虚拟地址（OVXIPAddress）和物理地址（PhysicalIPAddress）以避免租户流量之间存在地址空间冲突。虚拟地址在租户的OVXNetwork中是唯一的，而物理地址在整个物理网络中是唯一的。虚拟和物理IP地址之间转换可保证每个租户控制器依照其网络的编址方案（尽管可能与其他租户方案重叠）来处理流，并且datapath有能力识别不同租户的流量。

地址转换将datapath分成两组：

边缘：含有主机挂载的datapath；
核心：datapath仅和其他datapath相连。

边缘datapath用于重写IP地址。边缘交换机主要用于以下两个方面：

1. 对于网络侧的流量，nw_src和nw_dst字段进行OVXIPAddress值匹配，将OVXIPAddress重写成PhysicalIPAddress；

2.对于来自主机侧的流量，匹配PhysicalIPAddress值，将PhysicalIPAddress重写成OVXIPAddress
核心交换机依据PhysicalIPAddresses进行匹配和转发。

OVX拦截并改变FlowMod以便将这些行为添加到datapath上。除了FlowMod， OVX也改变PacketIn和PacketOut——核心datapath只能“看见”PhysicalIPAddress值，控制器只能看见OVXIPAddres值。图3.6描述地址虚拟化的过程。表2表示一组由租户控制器发送到OVX，OVX到datapath的可能FlowMod，以达到虚拟化。

图3.6 虚拟化过程

虚拟化过程流程如下：

a)PacketIn消息携带OVXIP值，未经修改发送到租户控制器；

b)相应的FlowMod匹配OVXIP，并将值重写为PhysicalIP；

c)虚拟链路通过psw2映射回两跳路径；

d)目的地边缘的PacketIn与核心网络中的转换行为一致；

e)OVX下发与PhysicalIP匹配的FlowMod消息，并将它们重写回OVXIP。

图3.6 三个datapath的地址虚拟化过程，交换机标识的数字表示端口号。在租户网络和实际网络中，端口号可能不同，即使是准确的映射，如pws1和vsw1。这里，h1开始发送数据包到h2，OVX根据目标datapath相对于源和目的主机中的位置分别处理PacketIns（租户方向箭头）和FlowMods（网络方向箭头）。

表2：到OVXSwitch和datapath可能的FlowMod消息集合

该行为的注意事项在ARP报文处理中介绍，具体见3.5.4节。

3.5.3.2 实现

转换过程通过下列几个OVXMessage类实现：

PhysicalIPAddress -> OVXIPAddress:
* OVXPacketIn

OVXIPAddress -> PhysicalIPAddress:
* OVXPacketOut
* OVXFlowMod
* OVXActionNetworkLayerSource/Destination

图3.7、3.8、3.9按顺序展示了OVXPacketIn、OVXPacketOut、OVXFlowMod消息的虚拟化与去虚拟化过程。

图3.7：PacketIn虚拟化

图3.8：PacketOut去虚拟化

图3.9：FlowMod去虚拟化

分页阅读： 1 2