ＩＰ Ｏｖｅｒ ＡＴＭ的ＱＯＳ探讨

为满足日益增多的各种网络多媒体应用，

因特网上传统的“尽力传送”服务模式

正逐步朝着“集成服务”模式过渡。

而ＡＴＭ已成为实现Ｂ－ＩＳＤＮ的基础

传输手段，本文即探讨了以ＡＴＭ

技术来实现ＩＰ业务的相关问题。

    AＴＭ宽带网络是计算机通信领域最近采用的实施方案。ＡＴＭ特有的网络交换排列规律和支持信令软件的能力，使ＡＴＭ有能力提供实时、有保证的服务质量（ＱＯＳ），有利于数字音频、视频和数据业务方面的应用。

    目前的因特网是通过由网间协议（ＩＰ）提供的异种网络来转发数据的。ＩＰ几乎完全独立于所使用的子网技术，ＩＰ分组能越过许多不同种类的子网（包括ＡＴＭ网），且发送端和接收端不必知道所经过路径的网络细节。ＩＰ是数据报协议，不要求数据发送前建立连接。

    ＡＴＭ技术有着良好的提供“集成服务”的能力。将ＡＴＭ应用到现在的因特网上，要求ＡＴＭ网络管理ＩＰ数据报的传输。这就要在一个异种互联网络环境里，运用有保证性能的ＡＴＭ虚电路来承载因特网业务，同时有效地解决ＡＴＭ数据转发模型（虚电路）和因特网（数据报）之间的差异。互联网工程任务组（ＩＥＴＦ）提出的ＩＰ ｏｖｅｒ ＡＴＭ模型就是基于ＡＴＭ技术的交换虚电路之上的。

１ 因特网的“集成服务”

    因特网从数据业务转向多媒体业务的关键问题是确保服务质量。因特网采用ＴＣＰ／ＩＰ协议，通过路由器等中继设备，将众多的分立系统互连在一起。这种传统的因特网构造和运行方式，强调了各种异构系统之间灵活的互连以及因特网的可扩展性和可靠性。不同应用要求可以通过使用较高层的协议来满足，没有严格要求的应用可使用简单的传输层协议（ＵＤＰ）。但由于各种条件的制约，使得所有的网络应用都只能建立在提供最简单的ＩＰ数据报服务基础上。正是这一制约使得传统的因特网只能运行无ＱＯＳ保证的非实时应用。因此，要在因特网上提供有保证ＱＯＳ的服务，就要改变其体系结构和运行方式以实现因特网的“集成服务”。

    “集成服务”模型体现在网络接口内，其必须能充分体现现在和将来应用所需的业务，因此有必要根据业务要求对各种应用进行分类，包括：有保证的业务类型、可预测的业务类型、可控制延迟的业务类型和可控制的负载业务类型。

    因特网业务类型的实现依赖于用户和网络之间的流量合同，用户规定它的业务量和ＱＯＳ要求，网络通过做流量控制和用户流量的策略来保证与流量规定的一致性。这种预防式的流量控制要求具有恒定比特率（ＣＢＲ）和可变比特率（ＶＢＲ）传输能力。

２ ＡＴＭ的ＱＯＳ要求

    ＡＴＭ宽带网络是针对各种电信业务的统一网络平台，具有吞吐量大、时延低的特点，对广泛的应用要求采取不同的策略，如划分不同业务类型并采取不同的ＱＯＳ保证策略。能够适应广泛的应用业务要求是ＡＴＭ的最关键措施之一。根据现有的和可能会出现的应用，ＡＴＭ论坛标准规定ＡＴＭ的业务类型有：ＣＢＲ、实时的可变比特率（ｒｔ－ＶＢＲ）、未规定比特率（ＵＢＲ）和可用比特率（ＡＢＲ）业务。对于每一类业务规定有两组参数：一组是向网络呈现的业务量参数；另一组是对网络要求的ＱＯＳ参数。为了满足ＱＯＳ指标，网络运用了一些业务量管理和控制机制。对不同的应用提供相应ＱＯＳ的能力。表１指出了ＡＴＭ的ＱＯＳ参数与ＡＴＭ信元传输性能参数的对应关系。

３ ＩＰ ｏｖｅｒ ＡＴＭ的ＱＯＳ要求

    如何用相应的ＱＯＳ将一套ＩＰ数据报映射到ＡＴＭ虚电路，准确地用于对话的ＱＯＳ将由应用决定。例如，像Ｔｅｌｎｅｔ和ｒｌｏｇｉｎ的交互式应用就要求低延迟；大量文件传输（如ＦＴＰ）在高吞吐量连接上工作得最好。在许多情形下，ＱＯＳ与应用的内容有关。下面列出了网络决定ＩＰ数据流ＱＯＳ要求的几种方法：

.    通过检查ＴＣＰ或ＵＤＰ端口数目或其它的高层信息，ＡＴＭ网边缘的主机或路由器由其应用获得相应的ＱＯＳ。这种方法利用已知的端口，依赖于因特网中的应用和其它的一般应用。

.    通过监测给定对话吞吐量一定时间，网络可计算出ＡＴＭ虚电路相应的一套要求（如峰值和平均吞吐量要求）。当ＩＰ对话持续时间允许这样的测量时，则可使用这样的自适应计划。

.    应用可能发送一些表示它们要求的ＱＯＳ请求种类，这样的消息能够包含在ＩＰ数据分组选项内，或者运用像ＲＳＶＰ及实时信道管理等信令协议。

.    通过默认的一套参数，可能是没有资源预留的尽力传递。这对于给定的对话不能决定ＱＯＳ参数的情况非常必要。

    上述措施可通过ＡＴＭ骨干网提高网络性能，但在异类互联网中不会提高到ＩＰ会话的端到端的性能保证。为因特网“集成服务”与ＡＴＭ相关功能的对应关系，ＲＳＶＰ运用每个数据流所关联的流描述符进行控制，其方式与ＡＴＭ运用虚通道标识符、虚信道标识符的流量约定相同。

４ ＩＰ ｏｖｅｒ ＡＴＭ集成服务的实现

    为在ＩＰ ｏｖｅｒ ＡＴＭ上实现集成服务，需要针对ＡＴＭ网络的特性，研究“集成服务”的关键技术如何与ＩＰ ｏｖｅｒ ＡＴＭ网络结合。这主要包括两个问题：资源预留的实现机制和ＩＰ服务模式向ＡＴＭ服务模式的映射机制问题。

４．１ 资源预留的实现机制

    如Ｉｎｔｅｒｎｅｔ草稿建议，ＲＳＶＰ是因特网集成业务的组成部分。它通过网络提供有保证的、预测的、端到端性能的实时应用，可归类为ＩＰ的控制协议。因此它提供异类接收器的灵活处理，就像动态地改变多点广播组的适配。ＲＳＶＰ的主要任务是在连接建立时的资源请求命令。为了实现准确，ＲＳＶＰ实际不预留资源，而是对底层系统标明预留请求。

    ＲＳＶＰ协议是一个基于接收方，由接收方发起的资源预留协议。ＲＳＶＰ在通信双方已经建立的路径上进行动态的ＱＯＳ协商，并且采用定时更新的方法随网络的状态而变化，其所建立的资源预留是单向的。而目前ＩＥＴＦ所提出的构造ＩＰ ｏｖｅｒ ＡＴＭ网络的方案中，所使用的ＵＮＩ信令是基于发送方的，信令状态只有当网络中的链路显示发生变化时才改变。为了应用ＡＴＭ的ＱＯＳ服务，必须在建立链路时就明确其ＱＯＳ参数，并进行ＱＯＳ协商。

    ＲＳＶＰ控制消息的传输是通过将ＲＳＶＰ分组压缩成ＩＰ或ＩＰＶ６分组来实现的。预留在单点广播和多点广播时都可做。预留的基础是流业务和ＱＯＳ特征的详细描述。ＲＳＶＰ定义了流规范（ＦｌｏｗＳｐｅｃ）和滤波器规范（ＦｉｌｔｅｒＳｐｅｃ）。流规范应用令牌桶描述突发业务，并规定了业务量参数（ＴＳｐｅｃ），还定义了所需的ＱＯＳ参数（ＲＳｐｅｃ）；滤波器规范包含流标识，并且做到了预留。尽管预留是面向接收端的，预留的初始者是发送器，它通知有关要发送流的特征给相应的接收器。预留协议的特征是预留方向。ＲＳＶＰ作为面向接收端的协议，预留的初始者是发送器；与此相反，ＡＴＭ信令协议是面向发送端。而且，ＲＳＶＰ是用软件陈述来管理节点内（终端系统、路由器）的陈述信息，以实现ＲＳＶＰ内资源预留的重协商。因此，对于ＡＴＭ的硬件陈述在呼叫建立后（Ｑ．２９３１信令），不可能改变已规定的ＱＯＳ参数。与ＲＳＶＰ模型对比，ＱＯＳ建立时间与连接建立时间相关联。这些概念的不同，使得ＲＳＶＰ与ＡＴＭ的集成更困难，两者的比较见表２。除了ＲＳＶＰ与ＡＴＭ一般功能不同之外，ＲＳＶＰ在多点广播组内支持几个发送端会话，ＡＴＭ却不支持这样的功能。

    为了将ＲＳＶＰ映射到ＡＴＭ，有两种可能性。当ＲＳＶＰ只在预留单方向时，集成的可能性大一些，从发送端到接收端，ＲＳＶＰ发送预留消息以建立ＡＴＭ连接；当ＡＴＭ在双方向预留时，也有可能。但是面向接收端，虚信道建立的仿真只对于单点广播ＶＣ适用，与只允许单向分配的多点广播情况相矛盾。

    另一种方法是，从下行主机接收预留消息，相应的路由器或主机根据预留消息建立与下一个下行驿站的ＡＴＭ连接。在此基础上，它还能建立ＡＴＭ点到多点连接，至少对异类接收器是这样的（与支持异类接收器的ＲＳＶＰ相反） 。

４．２ ＩＰ服务模式向ＡＴＭ服务模式的映射问题

    由于ＩＰ和ＡＴＭ的集成业务类型之间的不同，还要求详细分析映射业务类型，以及业务参数的业务量和质量。根据ＡＴＭ和ＩＥＴＦ的业务分类，ＩＰ业务的特征为延迟，而ＡＴＭ依据比特速率进行分类，如ＡＢＲ、ＶＢＲ、ＣＢＲ。

    在呼叫建立阶段，转换业务量和ＱＯＳ参数是层到层附加的通信。在ＡＴＭ链路层通过协商和转换获得自己的ＱＯＳ和业务量参数之后，进行接入控制以控制可用的资源。应用的数据流描述应该在ＡＴＭ层和实际要求的情况下运用。因此，必须避免由于不正确的映射引起的过高估计，以实现有效的带宽利用。

    依据ＲＳＶＰ和ＡＴＭ业务量参数的描述，ＡＴＭ允许与ＲＳＶＰ相反的传输可变比特速率（突发、峰值）和无突发流量的恒定比特速率业务。ＡＴＭ的业务量参数相应地包括最大突发量（ＭＢＳ）、可维持信元速率（ＳＣＲ）和峰值信元速率（ＰＣＲ）。ＡＴＭ与ＲＳＶＰ的有关参数比较。

     在恒定比特率信道上有可能传输所有的ＩＰ流，但这意味着资源没有有效地利用，如传输突发的业务。在这种情形，通过可变比特率信道的传输更有效。

显而易见，ＩＰ／ＲＳＶＰ业务类型并不直接与ＡＴＭ的业务类型相关，此种考虑的基础是ＡＴＭ论坛４．０所规定的ＡＴＭ业务类型。

     对于有保证的业务类型，只有两种ＡＴＭ业务类型是可能映射的：ＣＢＲ和实时的ＶＢＲ，因其有保证的带宽和端到端的延迟。与令牌桶深度相结合，可以做到分配相应的业务类型。这意味着，数值为１的令牌桶深度处理恒定的数据流。考虑ＣＢＲ业务类型，峰值信元速率是实际上已规定的唯一业务量参数。但是，ＰＣＲ可直接从ＲＳＶＰ基于端到端延迟算得的平均令牌速率获得；与有保证业务相结合的可变比特流能够映射实时的ＶＢＲ业务类型，期望令牌桶的深度值大于１。ＲＳｐｅｃ和ＴＳｐｅｃ参数转换成可维持信元率（ＳＣＲ）和最大突发长度（ＭＢＳ）。作为实时ＶＢＲ非常必要的业务量参数ＰＣＲ目前还没有从ＲＳＶＰ参数获得。基本上，ＲＳＶＰ对有保证的业务类型没有定义任何ＱＯＳ参数。

     对于可预测业务，因特网“集成服务”提供一个非常高的概率，使数据流中的分组所通过的端到端延迟不超过已有的限制。非实时的ＶＢＲ尤其适合于这类业务，因为它也期望有界的端到端延迟。除了作为ＲＳｐｅｃ组成部分的端到端延迟之外，业务量参数的映射对应于实时的ＶＢＲ映射。

     可控制的延迟业务在网络的组成部分方面具有相对较低的要求，并不提供任何有关分组延迟保证的定量级别。相反，它只希望通过移去过量的流量来避免开销。通过比较可控制的延迟业务和ＡＢＲ得知，两类业务在拥塞控制协助下都支持“尽力传递”业务。与ＲＳＶＰ相反，ＡＴＭ不提供任何端到端延迟规范。当前，只有平均令牌速率能映射平均信元速率。网络资源上没有任何要求的“尽力传递”业务，能映射成提供相同特征ＵＢＲ的业务。

     总之，ＱＯＳ参数的完全翻译和转换是不可能的。例如ＣＬＲ一般不能从ＲＳＶＰ参数映射成ＡＴＭ参数。作为ＲＳＶＰ的业务量参数，只包含令牌桶深度和平均令牌速率，业务量参数准确的映射或转变更加困难。引进峰值速率作为ＲＳｐｅｃ的一部分，可以实现ＡＴＭ参数的映射。考虑其附加开销，应用还需考虑传输和网络层的开销累积。引进最小分组长度作为ＴＳｐｅｃ的组成部分将实施开销累积。当考虑实际的开销时，为了预留应用的请求带宽，开销会出现在ＡＴＭ层内。

４．３ ＩＰｎｇ ｏｖｅｒ ＡＴＭ方案

    下一代因特网网络协议（ＩＰｎｇ）是ＩＰＶ４的改进版，它包含许多已扩展或保存的ＩＰ机制，以及一些新的机制和特点。在ＱＯＳ方面，ＩＰｎｇ头中的流标识和优先域可用于主机来鉴别分组，这些分组是ＩＰｎｇ路由器请求的特殊处理，如默认的ＱＯＳ或实时业务。对于属于同一流响应标记分组的特殊处理特征，可通过ＲＳＶＰ或ＩＰｎｇ选项来转换。为了支持多媒体和实时应用，要求一定程度的一致性、吞吐量、延迟和抖动，因此在ＱＯＳ方面的改进非常重要。

ＩＰｎｇ与ＡＴＭ的集成中，ＩＰｎｇ为了特定流的预留，要求决定相对应的虚信道（ＶＣ）标识，这就需实现ＩＰｎｇ分组映射到ＡＴＭ的ＶＣ。特定流的ＱＯＳ和业务量参数只能通过应用层来做。但是运用ＲＳＶＰ，应用级的ＱＯＳ和业务量参数能够直接地映射成ＡＴＭ参数。

    根据ＩＰｎｇ的标准实现和ＡＴＭ的发展过程，应用“尽力传递”业务传递ＡＴＭ上ＩＰｎｇ的分组，即复用ＡＴＭ虚信道的分组中，基于ＣＢＲ信道上的预留还不能由ＡＴＭ的子系统来支持。

    ＩＰｎｇ到ＡＴＭ的适配由核心模块来实现，它作为汇聚模块，提供ＡＴＭ子系统上较高层网络协议的适配。要实现ＩＰｎｇ地址到相应的ＡＴＭ地址的自动解析，需要运用地址解析协议（ＡＲＰ）。根据经典的ＩＰ ｏｖｅｒ ＡＴＭ原理，在同一信道传输ＡＲＰ与ＩＰｎｇ分组是通过用ＬＬＣ／ＳＮＡＰ加密分组来区别。这样地址解析的基础是能处理１６字节ＩＰｎｇ地址的自适应ＡＲＰ。

关于ＩＰｎｇ流量的预留需要考虑ＩＰｎｇ分组的分解复用机制。下面列出将ＩＰｎｇ流量映射到ＡＴＭ信道的策略：

.一对一映射，允许ＩＰｎｇ流传输通过一个ＡＴＭ的专用虚信道；

.    多对一映射，多个ＩＰｎｇ流分配到一个虚信道，这将有益于具有相同ＱＯＳ业务要求的流量；

.    全对一映射，目前正运用，因为还不能做到预留，所以所有的分组都是经过ＡＢＲ运用具有流控制的“尽力传递”业务来传送。

    要实现ＲＳＶＰ到ＡＴＭ上的映射，要求相应的应用程序接口（ＡＰＩ）。ＡＰＩ用于ＩＰｎｇ ｏｖｅｒ ＡＴＭ的ＩＰｎｇ汇聚模块中，并支持实时处理和ＩＰｎｇ流传输，ＡＴＭ与ＲＳＶＰ的集成。

    此ＡＰＩ能从本地守护进程接收预留信息，守护进程是作为ＲＳＶＰ实现的一部分。基于流规范所包含的信息，在完成前面所述的映射类别和参数之后，新的ＡＴＭ ＶＣ预留将会很容易地做到。除了计算并附加相应的开销（如ＡＡＬ５尾部的开销）到业务量参数，并将ＲＳＶＰ参数（ｂｉｔ／ｓ）转换成ＡＴＭ参数（ｃｅｌｌ／ｓ）之外，还要考虑ＡＴＭ内信元预留的精度。很明显，相当精密的精度对于终端系统和ＡＴＭ交换机之间都非常有必要，以运用接入控制实现预留。□

（收稿日期：１９９８－０５－０８）

[摘要] 文章对因特网的“集成服务”、ＡＴＭ的ＱＯＳ要求以及ＩＰ ｏｖｅｒ ＡＴＭ的ＱＯＳ要求进行了探讨，并在此基础上提出了运用资源预保留协议将ＡＴＭ集成到因特网上的实现方案。

[关键词] ＡＴＭ上的网间协议 服务质量 集成服务 资源预保留协议

[Abstract] Ｔｈｉｓ ｐａｐｅｒ ｄｉｓｃｕｓｓｅｓ ｔｈｅ ｉｎ-ｔｅｇｒａｔｅｄ ｓｅｒｖｉｃｅｓ ｏｆ Ｉｎｔｅｒｎｅｔ，ＱＯＳ ｒｅｑｕｉｒｅｍｅｎｔｓ ｏｆ ＡＴＭ ａｎｄ ＱＯＳ ｒｅｑｕｉｒｅｍｅｎｔｓ ｏｆ ＩＰ ｏｖｅｒ ＡＴＭ．Ｔｈｅ ｓｏｌｕｔｉｏｎ ｏｆ ｉｎｔｅｇｒａｔｉｎｇ ＡＴＭ ｔｏ Ｉｎｔｅｒｎｅｔ ｂｙ ｕｓｉｎｇ ＲＳＶＰ ｉｓ ｐｒｏｐｏｓｅｄ．

[Keywords] ＩＰ ｏｖｅｒ ＡＴＭ ＱＯＳ Ｉｎｔｅ-ｇｒａｔｅｄ ｓｅｒｖｉｃｅ ＲＳＶＰ ■