OpenFlow,长期以来一直是软件定义网络的管理和控制协议,目前正面临着来自其它协议的挑战。可替代OpenFlow的协议包括NETCONF、BGP、OVSDB、XMPP以及MPLS-TP。然而,虽然这些协议都可以用于管理网络操作的各个方面,但它们并不提供和OpenFlow完全相同的功能和特性。
NETCONF协议
NETCONF协议,由RFC 6241定义,用以替代命令行界面(command line interface, CLI)、简单网络管理协议(Simple Network Management Protocol, SNMP)以及其它专有配置机制。管理软件可以使用NETCONF协议将配置数据写入设备,也可从设备中检索数据。所有数据用可扩展标记语言(Extensible Markup Language, XML)编码,通过SSL或传输层安全这样安全、面向连接的协议,使用远程过程调用(remote procedure calls, RPCs)方式传输。
NETCONF协议定义了多个数据存储,或多套配置数据。正在运行的配置数据存储包含当前设备正在使用的配置信息。一些设备还储存启动配置数据,其中包含设备第一次启动时的配置数据,不过和运行中配置数据分离开来。
除了配置数据,设备还储存状态数据和信息,如包统计数据、运行中设备收集的其他数据。控制软件可以读取这些数据,但是不能写入。
候选配置数据存储是一个可选的设备性能。如果启用,它包含一组配置数据,控制器能用来更新正在运行的数据存储,以及修改设备操作。从备选配置数据中分离出正在运行的配置数据可以消除配置不一样的问题(例如,一系列CLI命令正在更新配置,随着一个个命令相继执行,配置就会处于一个不一致的状态)。
一旦NETCONF会话开始,控制器和设备就会交换一组“特性”。这组“特性”包括一些信息,如NETCONF协议版本支持列表、备选数据是否存在、运行中的数据存储可修改的方式。除此之外,“特性”在NETCONF RFC中定义,开发人员可以通过遵循RFC中描述的规范格式添加额外的“特性”。
NETCONF协议的命令集由读取、修改设备配置数据,以及读取状态数据的一系列命令组成。命令通过RPCs进行沟通,并以RPC回复来应答。一个RPC回复必须响应一个RPC才能返回。一个配置操作必须由一系列RPC组成,每个都有与其对应的应答RPC。
所选择的传输协议必须保证RPC按发送顺序传递给设备,而且应答必须按照发起RPC的顺序被接收。除了从控制器向设备发送命令,设备也可以发出通知来告知控制器设备上的一些事件。
NETCONF协议命令:
get-config:请求返回所有或一部分配置数据。传递的参数指定哪些配置数据需要返回,哪些具体元素需要获取。设备回复所请求的数据,如果设备不能满足请求,返回RPC错误。
get:请求返回运行中配置数据和状态数据。该命令可以请求所有数据或指定一组元素。
edit-config: 修改配置数据。包含在命令中的操作指令对目标数据中的特定配置数据元素进行操作。
merge:编辑命令中携带的数据被合并到现有数据。
replace:编辑命令中携带的数据替换现有的数据。
create:创建指定的数据存储元素,命令中的数据插入。如果该元素已经存在,设备返回RPC错误。
delete:删除指定的数据存储元素。如果元素不存在,设备返回RPC错误。
remove:和delete指令类似,但是如果元素不存在,操作被忽略,并且不返回错误。
copy-config:将一个数据存储复制到另一个。如果目标数据存储不存在,则创建它。
commit:将备选数据存储中的内容复制到运行中的数据存储。当设备功能不允许copy-config命令来修改运行中的数据存储时使用该命令。
delete-config:删除指定的数据存储。
lock and unlock:一台设备可能支持多个NETCONF与多个控制器会话,还可能继续支持其他配置机制,如CLI或SNMP. lock命令防止其他配置源干扰正在运行的一系列NETCONF操作。unlock命令释放锁,并允许其它源在设备上操作。实际操作中,locks命令应该只能在短时间执行。
close-session:控制器软件通常在设备启动时就会打开一个NETCONF连接,并且只要控制器还在管理设备,就会一直维持连接。当控制器不再管理设备时,close-session用来正常关闭连接。
NETCONF vs. OpenFlow
虽然NETCONF和OpenFlow都可以提供控制器软件和设备之间的通信,但是两个协议在很多方面是完全不同的。NETCONF是一个配置协议,而OpenFlow只是在流程表中在指定数据包如何通过路由传入。OpenFlow的交换机使用OF-Config进行配置,而OF-Config使用NETCONF来与设备进行通信。
NETCONF协议通过一组可选性能适用于任何设备架构,开发人员可以创建额外“特性”,因此NETCONF设备可以包含专有功能。反观,OpenFlow拥有特定设备体系结构。OpenFlow设备必须以一个标准的架构建立,没有专有功能,以确保厂商能够开发依附OpenFlow标准的白盒交换机。这些商品设备一投入使用将大大降低网络成本。
OpenFlow交换机不支持传统交换机和路由器用来确定网络路径的路由协议,所有有关数据包路径的信息都来自路由器。NETCONF设备可以支持这样的路由协议。在软件定义网络中,这些协议将继续被使用,控制器软件管理网络操作的某些方面,同时数据包路径仍旧在设备级别确定。
OpenFlow还是NETCONF?
因此,到底是选择OpenFlow还是NETCONF呢?本质是:网络有所不同。一些网络管理员会选择继续使用已更新NETCONF接口的现有设备。其它管理员可能会因为价格优势选择白盒交换机。随着软件定义网络技术的成熟,管理员们必须继续关注市场发展,选择最密切满足其网络需求的设计和产品。
好文章,需要你的鼓励
Replit与RevenueCat达成合作,将订阅变现工具直接集成至Replit平台。用户只需通过自然语言提示(如"添加订阅"),即可完成应用内购和订阅配置,无需离开平台。RevenueCat管理超8万款应用的订阅业务,每月处理约10亿美元交易。此次合作旨在让"氛围编程"用户在构建应用的同时即可实现商业变现,月收入未达2500美元前免费使用,超出后收取1%费用。
LiVER是由北京大学、北京邮电大学等机构联合提出的视频生成框架,核心创新是将物理渲染技术与AI视频生成结合,通过Blender引擎计算漫反射、粗糙GGX和光泽GGX三种光照图像构成"场景代理",引导视频扩散模型生成光影物理准确的视频。框架包含渲染器智能体、轻量化编码器适配器和三阶段训练策略,支持对光照、场景布局和摄像机轨迹的独立精确控制。配套构建的LiVERSet数据集含约11000段标注视频,实验显示该方法在视频质量和控制精度上均优于现有方法。
所有人都说AI需要护栏,但真正在构建它的人寥寥无几。SkipLabs创始人Julien Verlaguet深耕这一问题已逾一年,他发现市面上多数"护栏"不过是提示词包装。为此,他打造了专为后端服务设计的AI编程智能体Skipper,基于健全的TypeScript类型系统与响应式运行时,实现增量式代码生成与测试,内部基准测试通过率超90%。他认为,编程语言的"人类可读性时代"正走向终结,面向智能体的精确工具链才是未来。
这项由蒙特利尔学习算法研究所(Mila)与麦吉尔大学联合发布的研究(arXiv:2604.07776,2026年4月)提出了AGENT-AS-ANNOTATORS框架,通过模仿人类数据标注的三种角色分工,系统化生成高质量网页智能体训练轨迹。以Gemini 3 Pro为教师模型,仅用2322条精选轨迹对90亿参数的Qwen3.5-9B模型进行监督微调,在WebArena基准上达到41.5%成功率,超越GPT-4o和Claude 3.5 Sonnet,并在从未见过的企业平台WorkArena L1上提升18.2个百分点,验证了"数据质量远比数量重要"这一核心结论。