Containernet 2.0: A Rapid Prototyping Platform for Hybrid Service Function Chains

依旧是先用gemini过一遍

(1) 研究背景与痛点

• 核心挑战: 网络功能虚拟化 (NFV) 在实际应用中面临的最大挑战之一是降低虚拟网络功能 (VNF) 和服务功能链 (SFC) 的开发复杂性
• 现有工具的局限: 目前的工具主要集中在打包支持和描述符 (descriptors) 的静态验证上. 它们虽然能帮助发现静态文件中的错误, 但在集成和配置 VNF 内部软件时无法提供支持
• 混合环境需求: 未来的 5G 网络将普遍采用混合场景, 即同一个服务链中既包含基于容器 (Container) 的 VNF, 也包含基于虚拟机 (VM) 的 VNF
  • 在此之前, 没有工具能明确支持这种混合 SFC 的原型设计

(2) 解决方案: Containernet 2.0

作者推出了 Containernet 2.0, 这是一个开源的 NFV 原型设计平台, 支持在本地创建和执行复杂的混合 SFC

• 架构基础: 该项目是著名的网络仿真器 Mininet 的分支 (fork)
• 混合支持: 它是第一个支持在单一链中结合容器和虚拟机 (VM) 的快速原型工具
• 向后兼容: 平台完全向后兼容原始的 Mininet API, 允许模拟链路的延迟, 丢包和抖动
• VM 集成机制:
  • Containernet 通常通过管道 (pipe) 连接到容器的 TTY
  • 对于 VM, 无法直接使用管道. 解决方案是为每个 VM 添加一个管理网络接口, 并使用 SSH 进行连接
  • 这意味着所有使用的 VM 都必须安装 SSH, 且凭据需对平台可用

(3) Demonstration

论文展示了一个端到端的 SFC 原型工作流, 包括组合, 执行和配置:

• GUI 编辑器: 扩展了 Mininet 的图形编辑器 (MiniEdit), 支持 Docker 和 VM 主机的可视化组合以及多宿主 (multihoming) 支持

• 演示拓扑: 包含三个关键组件的混合链:

  1. Proxy (代理): 基于 Squid, 部署在 Docker 容器中 (L3)
  2. Firewall (防火墙): 基于 Iptables, 部署在 VM 中 (L2)
  3. IDS (入侵检测系统): 基于 Snort, 部署在 VM 中 (L2)

• 测试流程: 使用视频流流量测试服务, 并通过交互式命令行 (CLI) 对运行中的 VNF 进行实时重新配置

Containernet 2.0 旨在让开发者能够在笔记本电脑上快速构建, 测试和配置 production-ready 的混合网络服务, 填补了静态描述符编写与实际服务部署之间的空白

Introduction

在网络功能虚拟化 (NFV) 中, 复杂的网络服务由多个串联的虚拟化网络功能 (VNF) 组成, 这种结构被称为服务功能链 (SFC) [1].

此类 SFC 通常由网络服务描述符 (Network Service Descriptors) 定义, 这些描述符是描述相关 VNF 之间相互关系及链路连接方式的静态文件.

此外, VNF 通过 VNF 描述符 (VNFD) 进行定义, 该描述符规定了 VNF 及其部署单元 (VDU) (例如虚拟机镜像或容器) 应如何在可用的 NFV 基础设施 (NFVI) 之上进行配置 (Provisioning) 与部署 [2].

所有这些工件 (Artifacts) 通常由网络服务开发人员开发, 他们负责编写描述符, 制备新的或重用现有的 VNF, 并根据网络服务的需求对这些 VNF 进行配置.

目前, 该开发过程的大部分环节主要依赖手工操作, 步骤繁琐, 复杂且易于出错, 而可用的工具支持却十分有限. 现有的 NFV 开发支持解决方案 -- 即所谓的 NFV 服务开发工具包 (SDK) -- 主要侧重于描述符的创建或生成, 以及针对这些描述符的静态语法和语义检查 [3], [4].

这些工具有助于识别静态描述符中的缺陷和错误, 例如 SFC 定义中缺失的链路.

然而, 当需要对 VNF 及其内部包含的软件组件进行集成与配置时, 这些工具并未能向开发人员提供相应的支持.

例如, 需要在现有的虚拟机或容器镜像内部安装并配置防火墙软件的情况.

在实践中, 这意味着开发人员需要搭建一个本地 NFVI 测试床, 将开发的服务部署于其上, 并进行人工配置与测试. 一旦系统运行正常并通过测试, 开发人员必须导出虚拟机或容器镜像以进行交付 -- 对于敏捷开发环境而言, 这一过程过于复杂.

为解决这一问题, 业界需要一种能够支持在开发人员笔记本电脑上本地执行并配置复杂 SFC 的快速原型设计平台:

早期的解决方案通过采用单节点 NFVI 部署 [5] 或在仿真环境中使用基于 Java 的 VNF 代理功能, 构建了轻量级的原型设计平台 [6].

另一些方案虽然提供了明确的调试支持, 但其侧重点在于软件定义网络 (SDN), 而非真实 VNF 的集成 [7].

我们在之前的工作 [8] 中提出的名为 MeDICINE 的解决方案, 支持在多接入点 (multi-PoP) 环境中对基于容器的 VNF 进行快速原型设计. 然而, MeDICINE 主要关注编排系统与所开发网络服务之间的集成, 而非聚焦于网络服务及 VNF 本身 [9]. 更为重要的是, 上述解决方案均不支持由基于容器和基于虚拟机的 VDU 同时组成的混合 SFC, 而这种混合部署将是 5G 部署中的常见场景 [10].

在本次演示中, 我们介绍了 Containernet 2.0 [11], 这是首个支持执行由基于容器和基于虚拟机的 VNF 组成的混合 SFC 的快速原型设计平台.

我们的平台可安装并在开发人员的笔记本电脑上本地运行, 并配备了直观的服务编排图形用户界面 (GUI), 使开发人员能够在数分钟内构建服务原型.

在演示过程中, 我们将展示如何在原型平台上编排, 配置并执行一个示例网络服务.

此外, 我们还将展示通过 Containernet 的交互式命令行界面 (CLI) 对相关 VNF 进行实时交互和重新配置. 最后, 如第 III 节所述, 我们将使用视频流流量对该服务进行测试.

Rapid-Prototyping of Hybrid Network Services

One key requirement for rapid prototyping is the availability of an execution environment in which the developed components can be quickly deployed and tested by a developer. To build this execution environment for complex SFCs, we initiated the Containernet [11] project, a fork of the famous Mininet network emulator [12]. Containernet allows to execute VNFs in form of Docker containers and to interconnect them to arbitrary complex topologies. Containernet 2.0 extends the existing project by adding execution support for VMbased VNFs to the platform. Fig. 1 shows the architecture of Containernet 2.0 and how a network service developer uses it. As a first step, the developer defines the SFC by using either Containernet's GUI editor or a script that calls Containernet's Python API

(1). After this, Containernet deploys and interconnects the involved VNFs in its local, Mininet-based emulation environment

(2). Once all VNFs are running, the developer uses Containernet's interactive CLI to interact with and configure the running VNFs that can either be Docker containers or full-featured VMs

(3). To establish the network between the VNFs, the underlying Mininet is used.

Our platform is fully backwards compatible to the original Mininet emulation API, e.g., it allows to emulate arbitrary delays, loss, and jitter on the links between VNFs. It also allows to include SDN switches and customized SDN controllers into the prototyped topologies, e.g., to build custom chaining solutions.

快速原型设计的一项关键要求是必须具备一个执行环境, 使开发人员能够在此环境中快速部署并测试所开发的组件. 为构建面向复杂服务功能链 (SFC) 的执行环境, 我们发起了 Containernet [11] 项目, 该项目是著名网络仿真器 Mininet [12] 的一个分支.

Containernet 允许以 Docker 容器的形式执行虚拟网络功能 (VNF), 并将其互连以构建任意复杂的拓扑结构.

Containernet 2.0 对现有项目进行了扩展, 在平台中增加了对基于虚拟机的 VNF 的执行支持.

图 1 展示了 Containernet 2.0 的架构以及网络服务开发人员使用该平台的方式:

(1) 开发人员可通过 Containernet 的图形用户界面 (GUI) 编辑器或调用 Containernet Python API 的脚本来定义 SFC

(2) 随后, Containernet 在其基于 Mininet 的本地仿真环境中部署并互连相关的 VNF

(3) 一旦所有 VNF 启动运行, 开发人员即可利用 Containernet 的交互式命令行界面 (CLI) 与运行中的 VNF 进行交互和配置, 这些 VNF 既可以是 Docker 容器, 也可以是全功能虚拟机

平台利用底层的 Mininet 来建立 VNF 之间的网络连接. 我们的平台与原始 Mininet 仿真 API 完全向后兼容, 例如, 它允许在 VNF 之间的链路上仿真任意延迟, 丢包和抖动. 它还支持将 SDN 交换机和定制的 SDN 控制器集成到原型拓扑中, 以便构建自定义的服务链方案.

A. Supporting VMs in Containernet

Our main requirement for the integration of VMs into Containernet 2.0 is to be fully aligned with the existing Mininet and Containernet APIs. Our design allows a user to add a fully-featured VM to an emulation topology with a single Python command that expects the path to the VM image to be used as additional parameter, as shown in Listing 1 line 6 and line 7. Other parameters, like the node name or the IP addresses to be used, remain the same as in the existing implementations. This enables the seamless integration of VMs into existing emulation topologies. Additional parameters, like the hypervisor type, can be optionally passed to the underlying libvirt 1 implementation.

A more challenging problem was the integration with Containernet's interactive CLI that should allow a user to interact with all nodes (Mininet hosts, Docker container, and VMs) in the emulated network through a common CLI interface. In contrast to the CLI interaction scheme used in Mininet and Containernet, which uses pipes to directly connect to the TTYs of the emulated hosts or containers, a direct interaction with VMs is not possible. To solve this, we opted for a networkbased solution that adds a management network interface to each VM and connects to it using SSH 2 . This solution solves the problem and gives seamless access to all VMs in the emulated topology (see Fig. 1). The downside of this approach is that it introduces the requirement that all used VMs need to have SSH installed and their access credentials have to be available to Containernet 2.0. We argue that this is an acceptable requirement since the majority of existing NFV and cloud orchestration solutions rely on such management interfaces in any case.

将虚拟机集成到 Containernet 2.0 中的主要要求是必须与现有的 Mininet 和 Containernet API 保持完全一致. 我们的设计允许用户通过一条 Python 命令将全功能虚拟机添加到仿真拓扑中, 该命令仅需将虚拟机镜像的路径作为一个额外参数传入, 如代码清单 1 第 6 行和第 7 行所示:

其他参数 (如节点名称或使用的 IP 地址) 则与现有实现保持一致.

这使得虚拟机能够无缝集成到现有的仿真拓扑中. 其他参数 (如管理程序类型) 可以作为可选参数传递给底层的 libvirt 实现.

一个更具挑战性的问题是与 Containernet 交互式 CLI 的集成, 该 CLI 旨在允许用户通过统一的界面与仿真网络中的所有节点 (Mininet 主机, Docker 容器和虚拟机) 进行交互.

Mininet 和 Containernet 所采用的 CLI 交互机制是利用管道 (pipe) 直接连接到仿真主机或容器的终端 (TTY), 与之不同的是, 直接与虚拟机进行此类交互是不可行的!!!

为解决这一问题, 我们选择了一种基于网络的解决方案, 即为每个虚拟机添加一个管理网络接口, 并利用 SSH 进行连接.

该方案解决了上述问题, 并实现了对仿真拓扑中所有虚拟机的无缝访问 (见图 1).

三类交互方式

1. Mininet 和 Containernet: 基于 Pipe 的交互方式
2. VM-based Host: 基于 SSH 的交互方式, TTY

该方法的缺点在于引入了一个前提条件, 即所有使用的虚拟机都必须安装 SSH, 且其访问凭据必须对 Containernet 2.0 可见. 我们认为这是一个可接受的要求, 因为大多数现有的 NFV 和云编排解决方案无论如何都依赖于此类管理接口.

B. Extending MiniEdit for Containernet

To simplify the composition of complex SFCs, we extended Mininet's graphical editor, called MiniEdit, as shown in Fig. 2. In particular, we added support for Docker-based and VMbased hosts as well as support for multihoming and direct interconnections between all types of nodes. The multihoming feature is especially important since VNFs usually have multiple network interfaces, like data input, data output, and management/control. Having these features in place, our platform can be used to prototype complex SFCs including their data plane and control plane.

为了简化复杂 SFC 的编排, 我们扩展了名为 MiniEdit 的 Mininet 图形编辑器, 如图 2 所示.

具体而言, 我们增加了对基于 Docker 和基于虚拟机的主机的支持, 同时也支持了多宿主 (multihoming) 功能以及所有类型节点之间的直接互连.

多宿主功能尤为重要, 因为 VNF 通常拥有多个网络接口, 例如数据输入, 数据输出以及管理/控制接口. 具备了这些功能后, 我们的平台可用于对包含数据平面和控制平面的复杂 SFC 进行原型设计.

Demo

The objective of the planned demonstration is three-fold. First, we demonstrate how a complex network service can be composed with our graphical user interface. The created network service consists of both container-based and VM-based VNFs creating a hybrid SFC. Second, we demonstrate how our prototyping platform can be used to run production-ready network services on a developer's laptop. Finally, we show how the developer can interact and reconfigure the running service as well as test its functionality.

本次计划演示的目标包含三个方面. 首先, 我们将演示如何利用我们的图形用户界面 (GUI) 编排复杂的网络服务. 所构建的网络服务由基于容器和基于虚拟机的 VNF 共同组成, 从而形成一个混合服务功能链 (SFC). 其次, 我们将展示我们的原型设计平台如何支持在开发人员的笔记本电脑上运行生产就绪 (production-ready) 的网络服务. 最后, 我们将展示开发人员如何与运行中的服务进行交互, 重新配置, 并测试其功能.

A. Demonstrated Scenarios

Our demonstration comes with a set of example VNFs that operate on different layers of the networking stack, i.e., a proxy based on Squid 3 deployed in a Docker container acting on L3, a firewall based on Iptables 4 deployed in a VM acting on L2, and an intrusion detection system (IDS) based on Snort5 deployed in a VM acting on L2. Additionally, a Docker-based content server for video streaming is used to generate test traffic. During the demo, these example VNFs are combined to an SFC as shown in Fig. 2.

In particular, we show how the available VNFs are configured prior and after their deployment, e.g., we show how a developer can reconfigure a firewall or analyze the correctness of the IDS rules.

我们的演示配备了一组示例 VNF, 这些 VNF 运行在网络协议栈的不同层级上, 即:

• 一个基于 Squid 3 的代理 (部署于 Docker 容器中, 工作在 L3 层)
• 一个基于 Iptables 4 的防火墙 (部署于虚拟机中, 工作在 L2 层)
• 一个基于 Snort 5 的入侵检测系统 (IDS) (部署于虚拟机中, 工作在 L2 层)

此外, 我们使用一个基于 Docker 的视频流内容服务器来生成测试流量. 在演示过程中, 这些示例 VNF 将被组合成如图 2 所示的 SFC

具体而言, 我们将展示如何在部署前后对可用的 VNF 进行配置, 例如, 演示开发人员如何重新配置防火墙或分析 IDS 规则的正确性

B. Demonstration Steps

The demonstration includes the following steps:

1) Step 1: Composition of a hybrid network service, consisting of VMs and containers, using Containernet's intuitive graphical composition interface (Fig. 2).

2) Step 2: Instantiation of the hybrid network service in the local emulation environment.

3) Step 3: Live interaction and reconfiguration of running VNFs through Containernet's interactive CLI.

4) Step 4: End-to-end verification of the service composition and configuration using test traffic, i.e., video streaming.

演示包含以下步骤:

1. 使用 Containernet 直观的图形化编排界面构建由虚拟机和容器组成的混合网络服务

2. 在本地仿真环境中实例化该混合网络服务

3. 通过 Containernet 的交互式命令行界面 (CLI) 对运行中的 VNF 进行实时交互与重新配置

4. 使用测试流量 (即视频流) 对服务的编排与配置进行端到端验证

C. Demonstration Requirements

The demonstration can be executed either locally on a single laptop running the entire emulation platform or remotely on a server. It requires a power outlet for a laptop and one or two large screens to show the visualizations and executed services.

本演示既可以在运行整个仿真平台的单台笔记本电脑上本地执行, 也可以在服务器上远程执行. 演示需要为笔记本电脑提供电源插座, 并配备一到两个大屏幕以展示可视化效果和执行的服务