36、QoSJava：实现端到端QoS的创新解决方案

QoSJava：实现端到端QoS的创新解决方案

1. 背景与动机

如今，网络已成为大多数人日常生活中不可或缺的一部分。人们利用网络进行购物、观看电影、打电话、阅读新闻、玩游戏等各种活动。自然而然地，他们希望当前的网络基础设施能够从仅提供连接性，转变为提供更广泛、切实且灵活的具有服务质量（QoS）保障的网络服务。然而，目前各种服务的流量由IP网络承载，而IP网络仅提供尽力而为的传输。因此，近年来在IP网络中提供QoS成为了一个热门话题。

许多研究人员关注这一问题，并提出了大量的解决方案。其中，集成服务（IntServ）、区分服务（DiffServ）和多协议标签交换（MPLS）等方案广为人知。此外，许多项目也提出了创新的解决方案。例如，CADENUS、TEQUILA和AQUILA等项目，它们是欧盟委员会信息社会技术（IST）项目的一部分，已经实现了在IP网络中提供QoS的架构。这些方案相互独立，为IP网络的QoS问题提供了解决途径。

然而，目前提出的QoS解决方案都未得到广泛应用，当前的网络仍然是一个尽力而为的IP网络。尽管一些网络区域配备了具有MPLS功能的路由器，但为每个微流建立标签交换路径（LSP）并不实际。端到端的QoS距离最终目标仍然遥远。

服务提供商（SP）无疑能从QoS中获利，但为何现状依旧如此呢？通过对大规模网络的研究，我们发现了根本原因。当前的网络基础设施被划分为多个域，属于不同的网络提供商（NP）。这些网络提供商根据自身预算购买具有不同功能的网络设备，并基于这些设备采用不同的QoS机制。值得注意的是，不同的QoS机制之间并不兼容。上述提到的项目都假设整个网络采用单一的QoS机制，这在实际环境中并不实用。虽然映射机制可以实现两种不同QoS机制之间的互操作，但开发所有QoS机制对之间的映射机制并不现实，尤其是随着未来越来越多新的QoS机制出现。此外，不同厂商的设备具有不同的命令集。当需要更改QoS机制时，网络管理员不能批量修改，而必须逐个登录路由器进行配置修改，这增加了运营成本。总之，IP网络中提供端到端QoS的主要障碍是网络设备和QoS机制的异构性。

2. QoSJava的提出

为了解决上述问题，我们提出了QoSJava。这个解决方案的灵感来源于Java。在当前网络中提供端到端QoS与在分布式环境中编程有相似之处。在分布式环境中编程需要考虑程序的可移植性和运行时环境的异构性。同样，在异构IP网络中提供端到端QoS需要适应各种QoS机制和设备。我们知道，Java是一种适用于分布式网络环境的强大语言。编译后的Java程序在特定平台上的Java虚拟机（JVM）上运行。JVM在使Java具有可移植性方面起着核心作用，它在编译后的Java程序与底层硬件平台和操作系统之间提供了一层抽象。因此，Java能够隐藏运行时环境的异构性并取得巨大成功。

受Java的启发，我们认为QoSJava是IP网络中QoS供应的理想解决方案。与其他QoS解决方案不同，QoSJava可以为异构IP网络提供QoS，而无需假设网络采用相同的QoS机制。QoSJava通过QoS机制适配器（QoS Mechanism Adapter）和设备驱动程序（Device Driver）实现这一目标，它们的功能类似于JVM，在应用程序和异构环境之间提供了一个抽象层。类似于Java，QoSJava首先将用户的QoS需求转换为一系列“字节码”，即部署任务规范。然后，QoS机制适配器将部署任务规范转换为指令脚本。接着，脚本被输入到设备驱动程序中，设备驱动程序将脚本中的每个指令解释为与网络设备对应的一系列命令。最后，这些命令在设备上执行，完成配置。因此，QoSJava可以迁移到具有不同QoS机制和不同厂商设备的任意网络中，从而提供端到端的QoS。

3. QoSJava框架

QoSJava的框架由两部分组成：用户部分和管理员部分，如下图所示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(User Part):::process -->|QoS Requirement| B(User Interface):::process
    B -->|Translated Requirement| C(User Requirement Translator):::process
    C -->|Resource Request| D(Resource Manager):::process
    D -->|Admission Decision| E(Admission Control):::process
    E -->|Deployment Task| F(Deployment):::process
    F -->|Script| G(QoS Mechanisms Adapter):::process
    G -->|Commands| H(Device Driver):::process
    H -->|Configuration| I(Network Devices):::process
    J(Administrator Part):::process -->|Initialization| K(Network Initialization):::process
    J -->|Monitoring| L(Network Monitoring):::process
    J -->|Configuration| M(High - level Configuration):::process
    K -->|Info| D
    L -->|Info| D
    M -->|Policy| C

用户部分位于虚线左侧，处理从用户提交QoS需求到网络设备配置的整个过程。管理员部分位于右侧，供网络管理员初始化网络、监控网络性能和执行高级配置任务。QoS机制适配器和设备驱动程序贯穿两个部分，充当“虚拟机”的角色。在本文中，我们主要关注用户部分，因为它是端到端QoS供应的基础。

3.1 用户界面（User Interface）

用户界面（UI）是终端用户的入口。作为前端，UI负责接收用户的需求，将其传递给用户需求翻译器，并将准入结果返回给用户。在Java中，软件功能使用Java语言编码。同样，在QoSJava中，用户的QoS需求通过QoS需求描述语言表达，该语言可以是服务级别协议（SLA）、XML规范或任何其他标准格式。UI的实现不受限制，开发人员可以选择任何合适的技术来实现。在我们的原型中，采用SLA来表达用户的需求，UI以Web服务的形式呈现给终端用户。

3.2 用户需求翻译器（User Requirement Translator）

并非所有终端用户都是网络专家，因此他们通常以简单的方式表达QoS需求。此外，由于用户界面的不同实现，存在各种表达方式。因此，需要在用户界面和执行逻辑之间插入一层，以提取反映用户实际需求的技术参数，并以统一的方式表示。用户需求翻译器（URT）就是QoSJava中的这一层。基于策略服务器提供的策略，URT分析用户的期望，并得出以下元组来描述特定的QoS需求：
[
QoSReq_{e2e}^q = (SrcIP, DesIP, BW, Class, Delay, LossRate, Jitter, StartTime, EndTime)
]
该元组中的参数可以根据需要进行扩展。目前定义的项目包括：源IP地址（SrcIP）、目的IP地址（DesIP）、所需带宽（BW）、服务的流量类别（Class）、端到端延迟（Delay）、端到端丢包率（LossRate）、端到端抖动（Jitter）、合同开始生效的时间（StartTime）和合同开始到期的时间（EndTime）。

3.3 资源管理器（Resource Manager）

资源管理器（RM）对其对应域的物理网络有一个逻辑视图，包括网络拓扑、每个网络设备的状态和可用资源。与整个网络相比，一个域中的网络设备较少，因此基于域的资源管理更具实用性。RM从我们自己开发的网络管理系统中获取网络信息。收集网络设备（主要是路由器）的信息后，RM进行资源规划和管理的计算。RM维护一个资源数据库，以记录其所在域的资源信息。根据指定用户QoS需求的元组，RM执行准入控制并生成相应的监控任务。

路由器是IP网络中最重要的组件，因此路由器资源反映了网络资源。与QoS相关的路由器资源可以抽象为以下元组：
[
Res = (RouterID, DomainID, RT, IfNum, If_1, If_2, \cdots, If_{IfNum})
]
其中，对于每个接口 ( If_i ) ：
[
If_i = (BW, Buffer, Priority, Bucket, NextHop)
]
当前元组包含以下项目：路由器的标识（RouterID，即路由器的一个IP地址）、路由器所在域的标识（DomainID）、路由表（RT）、路由器中的接口数量（IfNum）、每个路由器接口的详细信息（ ( If_1, If_2, \cdots, If_{IfNum} ) ）、接口的带宽（BW）、接口的缓冲区大小（Buffer）、调度优先级（Priority）、桶大小（Bucket）以及接口连接的路由器（NextHop）。

路由器信息可以从网络管理系统中获取。元组Res中包含的项目可以根据需要进行扩展，并且应向网络管理系统添加相应的接口以检索所需信息。

基于收集的资源信息，首先进行网络规划。规划是粗粒度的，可以提高资源利用率，但无法实现最优的资源分配。实际上，由于互联网流量模式的复杂性，不存在实现最优资源利用率的解决方案。规划计算黄金、白银和青铜服务的资源矩阵，类似于区分服务（DiffServ）中的EF、AF和BE聚合。资源矩阵为准入控制过程奠定了基础。规划的基本思想是找出网络的瓶颈，并将其带宽分配给共享该链路的聚合流。具体算法可参考相关资料。规划产生的资源矩阵为 ( R_{Gold} )、 ( R_{Silver} ) 和 ( R_{Bronze} ) ，它们是 ( n \times n ) 的矩阵，其中 ( n ) 是域中边缘路由器的数量。以矩阵 ( R_{Gold} ) 中的元素 ( r_{i,j}^{Gold} ) 为例，它表示 ( ER_i ) 和 ( ER_j ) 之间黄金服务的可用资源，定义如下：
[
r_{i,j}^{Gold} = (SrcER, DesER, BW, Class, Buffer, Priority, Bucket)
]
其中，SrcER和DesER分别是入口边缘路由器和出口边缘路由器的IP地址，其他参数与元组QoSReq和If中的含义相同。

由于用户的QoS需求 ( QoSReq_{e2e}^q ) 可能涉及多个采用不同QoS机制的域，准入控制组件（AC）首先根据域的能力将 ( QoSReq_{e2e}^q ) 分解为多个QoS需求 ( q_i \in QoSReq ) （ ( i = 1,2,\cdots,m ) ），并将它们发送到第 ( i ) 个域的AC进行准入。 ( m ) 是端到端路径上的域总数， ( q_i ) 对应于第 ( i ) 个域。分解算法可参考我们之前的工作。

分解后，AC将每个QoS需求 ( q_i ) 转换为第 ( i ) 个域的资源需求。函数 ( f ) 将QoS需求映射到资源需求：
[
f: q_i \to r_{i}^{out}
]
其中：
[
r_{i}^{out} = (SrcER, DesER, BW, Class, Buffer, Priority, Bucket)
]
根据资源需求 ( r_{i}^{out} ) 和策略服务器提供的准入策略，AC查询资源数据库中的相应资源矩阵，并确定用户的需求是否可以被准入。如果端到端路径上所有域的资源都足够，则准入成功；否则，将返回失败通知和失败原因，以指导用户进行重新协商。

如果准入成功，AC从可用资源数据库中减去分配的资源。监控任务生成器还会生成一个监控任务 ( T_i ) ，用于在服务运行期间进行QoS监控。由于篇幅限制， ( T_i ) 的参数在此未给出，可参考相关资料。

用户需求被准入并生成监控任务后，部署组件为下层创建部署任务。部署任务规范是QoSJava的“字节码”，指定了为QoS供应应分配多少资源以及如何执行监控任务以保证QoS。该规范可以写成XML文档，也可以写成使用下层提供的应用程序编程接口（API）的配置文件。在我们的实现中，QoS机制适配器为部署组件提供了一系列API，部署组件可以使用这些API发出命令，如资源分配和监控任务执行。

3.4 QoS机制适配器（QoS Mechanisms Adapter）

不同的QoS机制具有不同的资源管理模式和QoS供应方法。在集成服务（IntServ）中，需要在端到端路径上的所有路由器中预留资源；区分服务（DiffServ）在边缘对流量进行分类并指定数据包的逐跳行为（PHB），如EF、AF和BE；MPLS则在网络入口建立LSP并为数据包添加标签。此外，不同的QoS机制在流量监控方面也表现不同。QoS机制适配器（QMA）的目的是隐藏这些异构性，为资源管理器提供一个统一的接口。

QoS机制适配器至少应执行两项操作：解释资源分配任务 ( r_{i}^{out} ) 和解释监控任务 ( T_i ) 。 ( r_{i}^{out} ) 和 ( T_i ) 都在部署任务规范中指定。基于域中采用的QoS机制，QMA将部署任务规范转换为一个包含设备驱动程序提供的一系列指令的脚本。适配方案如下：
[
QoSAdapter(r_{i}^{out}) =
\begin{cases}
\text{端到端路径上所有路由器的配置} & \text{IntServ} \
\text{边缘路由器的配置} & \text{DiffServ} \
\text{路由器之间的LSP建立} & \text{MPLS} \
\text{待扩展} & \text{其他QoS机制}
\end{cases}
]
[
QoSAdapter(T_i) =
\begin{cases}
\text{监控端到端路径上的所有路由器} & \text{IntServ} \
\text{监控入口路由器和出口路由器} & \text{DiffServ} \
\text{监控LSP的入口和出口} & \text{MPLS} \
\text{待扩展} & \text{其他QoS机制}
\end{cases}
]
在IntServ中，QMA需要将部署任务规范转换为端到端路径上域内所有路由器的配置。在DiffServ中，QMA将规范转换为入口路由器和出口路由器的配置，指定流量类别（EF/AF/BE）、队列优先级、数据包丢弃方案等。在MPLS中，规范被转换为标签分发、LSP建立和监控。

上述公式仅给出了QMA结果的语义。在实现中，QMA产生的结果是一个带有指令序列的执行脚本。一个指令封装了一系列网络设备的命令，并且可以执行比单个命令更高级的任务。以下是一个执行脚本的示例，描述了一个域 ( D_1 ) 采用IntServ的场景。因此，在 ( D_1 ) 中，需要在端到端路径上的所有路由器中进行资源预留和监控任务部署：

[INTSERV_QOSCONFIG]  
#ResvRes<Domain D_1, IP of Router 1, r_{i}^{out} tuple> 
#DeployMonTask<Domain D_1, IP of Router1, T_i tuple> 
… 
#ResvRes<Domain D_1, IP of Router N, r_{i}^{out} tuple> 
#DeployMonTask<Domain D_1, IP of Router N, T_i tuple>

当出现新的QoS机制时，可以通过扩展当前执行脚本或添加新的执行脚本来为QoSJava添加新的适配模块。因此，新的QoS机制可以融入QoSJava，而不会影响现有的QoS机制。由于QMA的存在，各种QoS机制可以在网络中共存，以提供端到端的QoS。

3.5 设备驱动程序（Device Driver）

QoS机制适配器隐藏了QoS机制的异构性，而设备驱动程序（DD）则使网络设备的差异变得透明。由于路由器厂商的不同策略，他们的产品具有不同的命令集。我们原型中的DD可以适应主要路由器厂商（如Cisco、Juniper和HuaWei）的命令集。

DD为QMA提供指令，并负责根据域中设备的类型将每个指令解释为命令。指令描述了需要执行的高级任务，如资源预留和监控任务部署。完成这些任务需要在路由器中执行一系列命令。上层可以使用指令发出高级命令，DD相应地将命令转换为一系列命令。因此，DD可以实现网络设备的自动配置，管理员无需手动逐个修改路由器的配置。

我们的原型提供了20多种指令，分为QoS供应、监控任务部署、数据收集、路由器配置/控制和网络管理等类别。用于网络管理的指令封装了简单网络管理协议（SNMP）命令。以下是一个指令示例，它被解释为Cisco路由器（2600、3600和7200系列）的命令：

#MODIFY_SERVICECLASS <19> 
@TELNETCONN <1> 
****** 
Enable 
****** 
Config terminal 
policy-map p-in-<19> 
class <17> 
police cir <10> bc <11> pir <12> be <13> conform-action set-dscp-transmit <14> exceed-action drop 
violate-action drop 
@TELNETDISC 

注意： <N> 表示指令的第N个形式参数。

综上所述，QoSJava通过QoS机制适配器和设备驱动程序，有效地解决了IP网络中由于设备和QoS机制异构性导致的端到端QoS难题。它不仅能够兼容当前的QoS机制和设备，还对未来新的QoS解决方案和先进设备开放，为实现高效、灵活的网络QoS供应提供了一种可行的途径。

QoSJava：实现端到端QoS的创新解决方案

4. QoSJava的部署

QoSJava的部署过程是一个系统性的操作，涉及多个关键步骤，以确保其在网络环境中能够稳定、高效地运行，为用户提供端到端的QoS保障。以下是详细的部署步骤：
1. 环境准备
- 硬件设施 ：确保网络中具备足够的路由器、交换机等网络设备，并且这些设备的性能能够满足QoSJava运行的要求。例如，路由器需要有足够的处理能力和内存来执行资源预留和监控任务。
- 软件系统 ：安装并配置好网络管理系统，该系统用于为资源管理器提供网络设备的信息。同时，确保策略服务器正常运行，为用户需求翻译器和准入控制组件提供必要的策略支持。
2. 组件安装与配置
- 用户界面（UI） ：根据实际需求选择合适的技术实现UI，如在我们的原型中采用Web服务的形式。将UI配置为能够接收用户的QoS需求，并将其准确传递给用户需求翻译器。
- 用户需求翻译器（URT） ：根据策略服务器提供的策略，配置URT的分析规则，使其能够准确地将用户的QoS需求转换为统一的元组格式。
- 资源管理器（RM） ：将RM与网络管理系统进行连接，确保RM能够获取网络设备的信息。同时，初始化资源数据库，为后续的资源规划和管理做好准备。
- QoS机制适配器（QMA） ：根据网络中采用的QoS机制，配置QMA的适配脚本。对于新出现的QoS机制，及时扩展或添加相应的适配模块。
- 设备驱动程序（DD） ：针对不同厂商的网络设备，配置DD的命令解释规则，使其能够将指令准确地转换为设备可执行的命令。
3. 测试与验证
- 功能测试 ：对QoSJava的各个组件进行功能测试，确保它们能够正常工作。例如，测试UI是否能够正确接收和传递用户需求，URT是否能够准确转换需求，RM是否能够进行有效的资源规划和准入控制等。
- 性能测试 ：在实际网络环境中进行性能测试，评估QoSJava对网络性能的影响。测试指标包括端到端延迟、丢包率、带宽利用率等，确保QoSJava能够满足用户的QoS需求。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(环境准备):::process --> B(组件安装与配置):::process
    B --> C(测试与验证):::process
    C -->|通过| D(正式部署):::process
    C -->|未通过| B

5. QoSJava的实现与实验结果

我们已经实现了QoSJava的原型，并进行了一系列实验来验证其有效性。

5.1 实现细节

• 编程语言与工具 ：使用了多种编程语言和工具来实现QoSJava的各个组件。例如，UI采用Web服务技术实现，使用了Java和相关的Web框架；RM和AC使用Python编写，利用其丰富的库进行资源计算和管理；QMA和DD则使用C++实现，以提高性能和对底层设备的控制能力。
• 数据库管理 ：采用关系型数据库（如MySQL）来存储资源信息和监控数据。资源管理器通过数据库接口对资源数据库进行读写操作，确保数据的一致性和可靠性。

5.2 实验设置

• 网络拓扑 ：构建了一个包含多个域的网络拓扑，每个域中包含不同数量和类型的路由器。部分域采用IntServ机制，部分域采用DiffServ机制，以模拟真实的异构网络环境。
• 流量模型 ：模拟了多种类型的流量，包括实时视频流、语音通话、文件传输等，以测试QoSJava在不同流量场景下的性能。

5.3 实验结果

测试指标	采用QoSJava前	采用QoSJava后
端到端延迟	较高且不稳定	显著降低且稳定
丢包率	较高	明显降低
带宽利用率	较低	提高，资源分配更合理

实验结果表明，QoSJava能够有效地解决IP网络中由于设备和QoS机制异构性导致的端到端QoS问题。通过自动配置网络设备，QoSJava能够根据用户的QoS需求，合理分配网络资源，提高网络性能，为用户提供稳定、可靠的网络服务。

6. 总结与展望

本文提出了QoSJava，一种创新的端到端QoS解决方案。通过QoS机制适配器和设备驱动程序，QoSJava成功地解决了IP网络中由于设备和QoS机制异构性带来的难题，实现了在异构网络环境中提供端到端QoS的目标。

QoSJava具有以下优点：
- 兼容性强 ：能够兼容多种QoS机制和不同厂商的网络设备，无需假设网络采用单一的QoS机制。
- 可扩展性好 ：对于新出现的QoS机制和先进设备，通过扩展执行脚本或添加新的适配模块，QoSJava可以轻松地将其融入网络。
- 自动化配置 ：通过设备驱动程序实现了网络设备的自动配置，降低了网络管理员的操作成本。

未来，我们将继续对QoSJava进行优化和改进：
- 性能优化 ：进一步提高QoSJava的处理性能，减少资源分配和配置的时间，以适应高速网络的需求。
- 新功能开发 ：增加更多的QoS保障功能，如动态资源调整、故障自动恢复等，提高网络的可靠性和稳定性。
- 应用拓展 ：将QoSJava应用到更多的网络场景中，如数据中心网络、物联网等，为不同领域的用户提供优质的网络服务。

总之，QoSJava为IP网络中的QoS供应提供了一种创新、可行的解决方案，具有广阔的应用前景和发展潜力。随着网络技术的不断发展，QoSJava有望在未来的网络环境中发挥更加重要的作用。