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接口的现有设备。其它管理员可能会因为价格优势选择白盒交换机。随着软件定义网络技术的成熟,管理员们必须继续关注市场发展,选择最密切满足其网络需求的设计和产品。
好文章,需要你的鼓励
穆拉蒂时隔18个月首次接受重大媒体采访,介绍其创立的Thinking Machines Lab正在开发的"交互模型"。该模型能以200毫秒间隔处理音频、文本和视频流,捕捉人类交流中的中断、修正和停顿。她还谈及OpenAI"政变周"经历,强调行业决策权过于集中的担忧,并回应了公司近期研究人员离职问题,表示这是初创实验室的正常波动。
STATE16研究院这篇综述发现,物理AI系统存在"静默失效"风险——AI以高度自信执行基于错误世界信息的动作,却不触发任何报警,并提出在AI输出与物理执行之间建立独立授权层的框架。
本期《Quick Charge》播客涵盖多个热点话题:特斯拉疑似试图删除FSD欺诈相关证据以规避巨额赔付;卡特彼勒持续推进建筑领域电气化布局;住宅太阳能30%税收抵免即将到期。此外,嘉宾Tom Pacheco就高压系统与电池技术培训展开探讨,强调电动车技术人才培养的紧迫性。节目同时提醒有意安装太阳能的用户尽快行动,可通过EnergySage平台比较多家安装商报价。
UIUC与微软联合研发的OpenWebRL框架让4B小模型仅凭400条初始数据,通过在真实网站上边做边学的强化学习方式,在网页智能体基准上超越了用27万条数据训练的竞争对手。