SDN实现模型

来自Linux78|wiki
Bob讨论 | 贡献2020年12月18日 (五) 10:49的版本
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)

从技术角度来看,供应商将网络设备的控制平面完全分离出来并让网络设备执行单纯的转发功能并非始终可行,因而供应商们采用了不同的方法来实现SDN,与我们目前讨论的SDN实现机制并非完全一致。服务提供商们也面临着很多实际操作困难,很难将自己的网络完全迁移到SDN,因而有可能采用某种替代方案来部署SDN,只要这些替代实现方案能够充分享受SDN带来的好处,能够实现控制平面与转发平面的分离,就是有效的SDN实现方式。常见的SDN实现方式主要有如下3种。

1.开放(经典)SDN

该方法是实现控制平面与转发平面相分离的经典实现方式。

由于供应商研发的网络设备还暂时无法实现这一目标,因而这种方式利用SDN支持层(SDN SupportLayer)来代替本地控制平面,以实现SDN的支持能力。新的SDN支持层能够与SDN控制器以及设备的转发平面协同工作,使得网络设备具备通过SDN协议与SDN控制器进行通信的能力,而且还能直接控制转发平面

2.混合SDN

很多供应商都采用了通过SDN支持层修改设备控制平面的SDN实现方式,并声称其设备已支持SDN。

但是这并不意味着设备的本地控制平面已不复存在,本地智能仍然可以与外部控制器实现的控制平面协同工作。对于这种实现方式来说,由于设备会运行自己的(分布式)本地控制平面,并由外部SDN控制器通过修改这些协议使用的路由参数或者直接修改转发平面来增强设备的智能,因而将该实现方法称为混合SDN。请注意,与经典SDN实现方式相比,混合SDN实现方式的主要区别在于设备仍然使用本地控制平面。

3.通过API实现SDN

有些供应商通过提供用于部署、配置和管理设备的API来实现SDN,应用程序可以通过API控制设备的转发平面,等同于控制器与网络设备之间使用的南向API。不过,由于API可以直接插入到应用程序中,因而这种SDN实现方式可能不需要使用标准南向协议的SDN控制器。与供应商一直使用的私有CLI(Command-Line Interface,命令行接口)相比,该实现方式是向更加协作化和开放化的方向进行转变,但很难做到真正的开放性,因为这些API很可能无法实现多供应商之间的兼容性,因而并没有真正解决私有性问题。

使用这种基于API的SDN实现方式的应用程序必须知道它们正在与哪些供应商的设备进行通信,从而能够使用正确的API。支持这种SDN实现方式的观点认为,该实现方式允许应用程序影响转发决策,而且任何想要构建应用程序和使用API的人都能公开使用API,因而实现了SDN的核心目标。虽然这种方式让网络具备了可编程性,但灵活性不足(因为私有的南向API)。

部分供应商通过提供自己的控制器来解决灵活性问题,这些控制器使用私有的南向API(面向网络设备)和标准的北向API。图5-7给出了通过API实现SDN的实现方案。

4.通过叠加方式实现SDN

从网络中分离控制平面的另一种方法是在现有网络之上创建独立的叠加网络,该实现方式中的底层网络仍然拥有采用传统方式进行本地管理的控制平面。不过,对于叠加网络来说,该底层网络实质上仅提供连接并转发数据。对于网络用户来说,底层网络及其拓扑结构和控制平面都是透明的,叠加网络就是与用户进行交互的网络。该实现方式下的用户可以通过外部控制器来管理叠加网络,不需要构成底层网络的设备支持任何SDN功能。该SDN网络实现方式符合SDN的基本要求,唯一的约束条件就是要求底层设备必须支持实现叠加网络的协议。

前面讨论了虚拟网络的概念,虚拟网络实际上就是叠加网络。采用该SDN实现方式的技术方案主要包括由大量供应商支持的VXLAN(Virtual Extensible LAN,虚拟可扩展LAN)以及由Microsoft支持的NVGRE(Network Virtualization using Generic RoutingEncapsulation,采用通用路由封装的网络虚拟化)。