标签：
【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：
cookieCounter确保了OVXSwitch内cookie的唯一性。具体地讲，当FlowMod增加流表时被OVXFlowMod.devirtualize()分配一个新的cookie，新cookie在流表中作为匹配机制,也就是说当OVX接收FlowRemoved时，必须删除条目，以保持与网络的状态的一致性。
bufferMap.PacketIn/PacketOut引用同一个bufferID。在消息的转换过程中，需要将来自packet_in的buffer_id和生成的buffer_id存起来，当packet_out数据下发时，需要查找并转换。
如上所示，所存储的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，以达到虚拟化。
虚拟化过程流程如下：
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（网络方向箭头）。
该行为的注意事项在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.6 状态同步
3.6.1 组件状态协调(原文未完善)
3.6.2 错误升级
OVX使用错误拦截来同步物理网络。网络中的错误，如端口、链路、交换机出现问题，将通过OFPortStatus消息发送到OVX上。目前OVX的实现期望PortStatus消息的OFPortReason字段携带具体原因值，如发生故障的交换机在该消息中携带原因值OFPPR_DELETE来发送。OVX将这些PortStatus消息作为 OVXPortStatus[net.onrc.openvirtex.messages]实例处理。
OVXPortStatus消息的处理依赖于OVX的状态。在一个简单的案例中，只有端口、链路而没有租户网络的存在，PhysicalNetwork中的交换机将被除去。即使存在租户，在给定具有特定属性的虚拟拓扑结构的网络中，OVX也具有隐藏错误情况的能力。
■OVXBigSwitches网络：non-OVXPort中的端口故障与网络故障是相似的。BVS中的端口如果发生故障则可以在租户网络中完全隐藏，前提是：BVS的OVXPorts之间存在替代路径，或者没有SwitchRoutes使用这些端口。
■冗余OVXLink：如果在OVXPort定义的OVXLink之间有多条链路是可用的，端口在一条路径失效的情况下可以通过故障转移到另一条路径。
此外，未映射端口的故障将被简化到最简单的情况。图3.10显示了可以由OVX抑制的故障情形。
图3.10三种情况中的错误可以被抑制。左）PhysicalSwitches b和c未映射到OVXNetwork，租户对于b和c以及与它们相关的错误完全是无知的。中）多个物理路径映射到vs1和vs2之间的OVXLink([a-b,b-d],[a-d],[a-c,c-d]…)，提供足够的备份路径，这样就不会有链路故障报告给租户，除非a和d之间的所有路径均出现了故障，或者是PhysicalPorts映射到OVXPorts失败。右）整个PhysicalNetwork映射到一个BVS和crossbar。PhysicalLinks、端口和交换机的故障可能会被隐藏，除非a和d之间的SwitchRoute用完了路径，或OVXPorts失败。
OVXBigSwitch和OVXLink灵活性在3.7节中讨论。顺便说一句，当发生下列情况时错误升级仅影响视图：
（1）映射到OVXLinks和SwitchRoutes的OVXPorts；
（2）非弹性路径部分；
（3）映射到OVXSwitch边缘端口。
已删除的PhysicalPort的移除过程遵循3.2.3节的图3.3中所描述的依赖关系树，详情可查看《OpenVirteX体系结构之操作与子系统（一）》，完整的错误升级过程在OVXPortStatus.virtualize()中实现。
本文未完。。。。。。
本文来源于SDNLAB，可点击此继续阅读原文。如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。另外我们网站也有大型企业招聘平台，里面有很多优质的岗位，有意者请点击招聘查看详情。
如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。
（1） 微博（http://weibo.com/sdnlab/）
（2） 微信(账号：SDNLAB)
（3） QQ群
SDN研究群（214146842）
OpenDaylight研究群（194240432）
标签：
原文地址：http://www.cnblogs.com/SDNLAB123/p/4262551.html
