狙击 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^[1]。

dSDN 专利

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

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

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

背景

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

技术实现

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

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

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

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

技术细节

分布式控制功能

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

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

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

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

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

专利要求

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

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

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

核心技术的重叠

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

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

Kubernetes 网络插件（CNI）：许多使用分布式方法来管理网络流量（例如 Flannel、Calico）。关于 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^[4]（CNCF 英雄挑战赛），寻求找到用于终结该专利的证据：2013 年 6 月 13 日或更早的有关该技术的开源文档、标准或规范、产品手册、文章、博客、书籍或任何公开可用的信息。

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

专利规避与技术创新

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

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

其他法律策略

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

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

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