17 November, 2024

狙击 K8s 用户的“流氓”专利：分布式软件定义网络 (dSDN)

笔记

背景

流氓专利（Patent Troll）通常是指一种专利滥用现象，其中专利的持有人或公司主要以专利诉讼和许可费为目的，而非通过生产或使用专利技术来进行创新。这类专利持有者有时被称为 专利流氓（Patent Trolls）。

流氓专利的主要特征：

没有实际的产品或服务

广泛的专利覆盖范围

诉讼作为主要手段

针对创新企业和开源社区

近年来，专利诉讼的阴云正逐渐笼罩技术创新领域。特别是在开源社区，专利“流氓”（Patent Trolls）的出现不仅威胁了开发者的创造力，还可能拖累整个行业的进步。以 CNCF（云原生计算基金会）生态为例，开发者们正在面临专利诉讼的压力，这些诉讼往往针对的是社区内广泛使用的基础性技术，而非真正创新的专利。

在这次的 KubeCon NA 2024 SALT LAKE CITY，CNCF 执行董事 Priyanka Sharma 在她的主题演讲中透露，专利流氓正在“追捕”使用 Kubernetes 的公司。这个专利就是 Edge Networking Systems LLC 公司的专利 Distributed software defined networking US-11695823-B1。

dSDN 专利

关于专利的完整内容，可以从这里获取。下面是针对这份长达 42 页内容的简单概括，如有解释不准的请指出。

该专利描述了一种分布式的软件定义网络（SDN）架构，旨在提高网络的灵活性和可扩展性。其中控制平面被分布到多个网络设备中，而不是集中在单一控制器上。这种方法通过在网络设备之间共享控制功能，减少了单点故障的风险，并提高了网络的可靠性和性能。

通过这种分布式 SDN 架构，网络运营商可以构建更灵活、高效和可靠的网络基础设施，满足现代网络环境中不断增长的需求。

背景

传统的 SDN 架构通常依赖于集中式控制器来管理网络流量和策略。然而，这种集中式方法可能导致性能瓶颈和单点故障问题。为了解决这些问题，提出了分布式控制的概念，将控制功能分散到多个网络设备中。

技术实现

该专利详细描述了一种实现分布式 SDN 的方法，包括：

多个交换机作为分布式控制器：将控制功能分散到多个交换机中，每个交换机具备一定的独立决策能力。
消除集中式瓶颈：每个交换机都能独立工作，减少了对单个控制器的依赖。
流量管理的优化：提供一种协调机制，确保多个交换机之间的控制决策一致，避免冲突。
分布式控制器之间的通信：这些分布式控制器（交换机）需要通过特定的协议进行通信。该协议可能设计为高效且低延迟，确保控制信息能够在设备之间快速传递。
动态适应流量变化：当网络中流量模式发生变化时（如突然的流量高峰或设备故障），分布式控制架构可以快速响应。这种动态适应能力在数据中心环境中特别重要，因为数据中心需要高性能和低延迟的网络连接。

这种技术提供了如下的特性，适用于大型数据中心和多租户的场景。

弹性和容错性：消除了单点故障，提高了网络的可靠性。
性能提升：减少集中控制器的压力，使网络更高效。
分布式协调：通过设计良好的协议实现设备之间的无缝协作。

技术细节

分布式控制功能

专利描述了如何将传统集中式控制平面功能分布到多个网络设备（如交换机）上：

控制逻辑的分布：专利中提到，分布式架构允许每个交换机独立处理网络策略和流量控制功能。
动态适应能力：这些设备可以根据网络状态动态调整控制策略，例如路由决策和负载平衡。
高可用性：由于控制功能是分布式的，即使部分设备失效，系统仍能保持运行，增强了网络的可靠性。

多个交换机之间的通信协议

专利对交换机间通信协议的描述包括：

协调机制：确保多个分布式控制器之间的一致性，避免因独立决策产生冲突。
通信效率：使用设计良好的低延迟协议，使控制信息能够快速同步到所有相关设备。
示例协议或技术：文中未具体提及某种标准协议（如 OpenFlow），但强调了新设计的专有通信机制。

专利要求

该专利的权利要求涵盖了分布式 SDN 架构的各个方面，包括：

在网络设备中实现分布式控制功能的方法。
分布式控制器之间的通信协议和机制。
提高网络弹性和可靠性的具体技术手段。

对 K8s 用户和开源社区的影响

核心技术的重叠

专利描述的分布式控制架构，其中控制平面被分布在多个设备中。这种方法在某些方面与 Kubernetes 的分布式设计理念相似，例如：

Kubernetes 的控制平面：分布在多个组件中（API Server、Scheduler、Controller Manager 等）。

Kubernetes 网络插件（CNI）：许多使用分布式方法来管理网络流量（例如 Flannel、Calico）。关于 CNI 的内容，可以看下我之前写得 [CNI 及插件系列](# 认识一下容器网络接口 CNI)。

专利的权利要求覆盖了类似的分布式控制技术或机制，可能会引发对 Kubernetes CNI 插件和控制平面的专利争议。

网络插件的实现与授权风险

Kubernetes 用户依赖网络插件来实现容器的互联互通。这些插件（如 Calico、Cilium、Flannel）可能会采用分布式架构来管理流量策略和路由规则。专利中的某些保护范围可能直接或间接涉及这些插件的实现方式，影响：

插件的开发与分发：开发者需要确保其实现不侵犯专利。
用户的合规性：企业用户可能需要额外评估所选插件是否受到该专利的限制。

影响多集群管理

专利中描述的分布式 SDN 架构在多网络设备之间共享控制功能，这与 Kubernetes 的多集群管理需求有共性。例如：

Kubernetes 多集群网络解决方案（如 Submariner、ClusterAPI）需要在多个集群中共享和同步流量控制与策略。
如果这些方案依赖于类似的分布式控制方法，则可能需要规避专利中的保护内容。

对开源社区的潜在挑战

许多 Kubernetes 相关技术和插件属于开源项目，而专利可能会对这些项目的分发或使用造成限制，尤其是：

专利许可模式：是否对非商业用途宽松，对商业用途严格？
潜在诉讼风险：Kubernetes 的商业支持者（如 Red Hat、VMware、Google 等）可能需采取措施避免侵犯该专利。

可能的创新机会

该专利可能成为 Kubernetes 社区进一步发展的触发点，促使用户和开发者探索新的网络架构和控制方法，例如：

开发专利规避设计，避免重叠技术。
优化现有 Kubernetes 网络方案以实现更高效的多集群连接。

应对

专利无效诉讼

在专利无效诉讼中，找到先有技术（prior art）是终结该专利的关键，也可能是眼下可以最快解决问题的手段。

为此 CNCF 成立了 Cloud Native Heroes Challenge（CNCF 英雄挑战赛），寻求找到用于终结该专利的证据：2013 年 6 月 13 日或更早的有关该技术的开源文档、标准或规范、产品手册、文章、博客、书籍或任何公开可用的信息。

所有提交符合竞赛规则的参赛作品的参赛者都将获得一件免费的“Cloud Native Hero”T 恤，提出可用于终结 832-B1 的证据的人还将获得 3000 美元的现金奖励。

专利规避与技术创新

即使专利有效，也可以通过设计专利规避方案降低风险，这一步属于长期的计划。

寻找替代架构：采用与专利描述不同的控制平面分布方法。例如，避免专利中描述的特定通信协议。
社区协议演进：鼓励社区制定新的开源协议，完全公开并避免侵权。
标准化路线：将重要技术提交到标准组织（如 IETF），利用标准化保护开源实现。

其他法律策略

这个领域并非我能力所及的，只能罗列出我从网络上找到的内容。

请求专利审查：也就是前面提到的专利无效诉讼，需要提交无效性证据，申请专利再审。比如，OpenFlow 是最早支持软件定义网络 (SDN) 的协议之一，其早期标准定义了网络控制平面的集中式管理方式，但也为后来的分布式实现奠定了基础。还有
提出公共利益诉讼：通过法院指出专利对开源社区的危害，寻求公开利益支持。
与专利持有人谈判：如无法避免，可寻求宽松的开源许可证，以保障社区合法使用。

应对“流氓专利”的核心在于 技术调查与法律手段结合，同时 联合开源社区力量 提供支持。找到确凿的先有技术证据是终结专利的关键，而通过创新设计规避方案也能帮助社区摆脱潜在限制。