什么是开放网络？

网络行业的发展如果非要归纳出一个明确的发展趋势的话，那这个趋势无疑是“开放”。业界有一个奇怪的现象，但凡涉及到“开源、开放”的技术或者社区，好像都比较受到追捧，网络行业也不外如是，那么到底什么是开放网络呢？

网络用户和运营商长期以来一直在传播这样一个观点，他们认为开放是指支持组织的自由替代。如果我现在在网络中有个A盒子，它可以用B盒子加以取代，那这就是开放网络。但是这是不是就意味着用户可以简单地在同一个位置取代设备？这些接口是否完全相同？用户能够接受需要微调以支持硬件取代的网络吗？甚至是只支持主流硬件替代的“开放”网络吗？

扑朔迷离的未来

传统网络设备有三种类型的接口。一类支持端口/中继数据平面连接。另一种支持的控制交互，第三种支持设备管理。软件组件在某种意义上等同于身，需要独立的接口，通常被称为应用程序接口即API，我们将网络软件API归类于设备接口相同的第三个种类中。事实上，像托管路由实例一样的网络软件将具备这三类接口，但是它们同时还具有一整套设备从未显示的API，而这些API使软件定义中的开放性变得扑朔迷离。

假设用户需要托管一个Virtual_Router单个软件元素，用户必须能够将其部署在需要软件和一组API的服务器上，用户必须能够管理服务器和路由器实例。

当用户希望能够扩展虚拟路由器的端口和中继接口时，这种情况将变得不受控制。端口和中继件必须连接核心路由器元素——另一套API，用户可以在完整的软件定义网络（SDN）或网络功能虚拟化（NFV）中轻松识别几十个API，并且部署完成的SDN/NFV可能具有数万个API。处理数量呈爆炸式增长的API，厂商给出的方式是将API发布在某种目录中。

然而，这种方式效果非常有限，因为API不是我们在设备中可以看到的物理接口，设备通过物理接口以非常具体的方式互通。API不会描述集体图案管虚拟设备的工作原理，而是如何在虚拟设备内部进行工作。API支持软件组件工作流程，但是当路由器具备标准功能时，每个路由器供应商将其软件分成相同的组件？还是使用完全相同的信息格式来进行通信？

举个规模化网络软件的负载能力的例子，一个厂商可能会在其“规模化控制”API中要求每个分组数据包的规模限制，另一厂商可能希望根据托管它的处理器的CPU利用率来规模化组件的副本。第三个厂商可能都不接受明确的规模化控制。当今开放的最大问题是，开放API不仅仅意味着已发布的API，还意味着通过API的信息格式，并且取决于软件实现的细节。

基于意图（intent）

网络软件正在试图通过一种基于所谓“意图”的层次建模来解决这个问题，意图模式描述“what”所指的是功能而不是实现方式（How）。由于暴露了特定的属性显式API，虚拟路由首先被建模，任何想要成为虚拟路由的东西都必须具备这样的高级模型。其中可能会定义“port-instances”和“trunk-instances”，它们描述了虚拟路由的各项功能，但在某种程度上，某一部分的意图模型包含隐藏或专用的逻辑，这些是不开放的。

用户可以根据开放的定义将一个兼容的虚拟路由替换成另一个虚拟路由，如果虚拟路由模型分解成“port-instances”和“trunk-instances”模型，那么也可以通过替换这些加以实现。然而，如果基本的核心路由逻辑不是单独建模的，那么用户不能实现设备或虚拟路由的替换。

这意味着在我网络软件和软件驱动的网络中，我们承认了一切都不开放且不允许实现专有的变化的方式来表述所谓的开放性的概念扩展。这意味着开放API本身就是一个笑话，因为它不具备任何意义，开放的未来是将功能与实现分开的软件建模的未来。

我们应该关注的是如何建立软件建模，如果我们可以为设备和设备网络定义标准结构，并且可以在基于意图的层次结构上构建这种标准的网络，我们未来的软件定义网络元素将遍地开花，这也是我们所期待的。