Network Working Group                                        M. Garrett
Request for Comments: 2381                                     Bellcore
Category: Standards Track                                     M. Borden
                                                           Bay Networks
                                                            August 1998
        
Network Working Group                                        M. Garrett
Request for Comments: 2381                                     Bellcore
Category: Standards Track                                     M. Borden
                                                           Bay Networks
                                                            August 1998
        

Interoperation of Controlled-Load Service and Guaranteed Service with ATM

受控负载服务和保证服务与ATM的互操作

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

Abstract

摘要

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IP Integrated Services networks containing ATM subnetworks.

本文档提供了在Internet和ATM技术之间映射服务类别、流量管理功能和参数的指南。服务映射有助于为包含ATM子网的IP综合服务网络提供有效的互操作和端到端服务质量。

The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS), Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included.

这里给出的讨论和规范支持保证服务(GS)、受控负载服务(CLS)的IP综合服务协议和ATM论坛UNI规范,版本3.0、3.1和4.0。还包括对ATM上IP尽力而为服务的一些讨论。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. (Note, in many cases the use of "MUST" or "REQUIRED" reflects our interpretation of the requirements of a related standard, e.g., ATM Forum UNI 4.0, rsvp, etc.)

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。(注意,在许多情况下,“必须”或“必需”的使用反映了我们对相关标准要求的解释,例如ATM论坛UNI 4.0、rsvp等)

Table of Contents

目录

1.0 Introduction ....................................................  3
    1.1 General System Architecture .................................  4
    1.2 Related Documents ...........................................  7
2.0 Major Protocol Features for Traffic Management and QoS ..........  8
    2.1 Service Category and Bearer Capability ......................  8
        2.1.1 Service Categories for Guaranteed Service .............  9
        2.1.2 Service Categories for Controlled Load ................ 10
        2.1.3 Service Categories for Best Effort .................... 11
    2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions . 11
    2.3 ATM Adaptation Layer ........................................ 13
    2.4 Broadband Low Layer Information ............................. 13
    2.5 Traffic Descriptors ......................................... 13
        2.5.1 Translating Traffic Descriptors for Guaranteed Service. 15
        2.5.2 Translating Traffic Descriptors for Controlled Load
              Service  .............................................. 18
        2.5.3 Translating Traffic Descriptors for Best Effort Service 19
    2.6 QoS Classes and Parameters .................................. 19
    2.7 Additional Parameters -- Frame Discard Mode ................. 22
3.0 Additional IP-Integrated Services Protocol Features ............. 22
    3.1 Path Characterization Parameters for IP Integrated Services . 22
    3.2 Handling of Excess Traffic .................................. 24
    3.3 Use of Guaranteed Service Adspec Parameters and Slack Term .. 25
4.0 Miscellaneous Items ............................................. 26
    4.1 Units Conversion ............................................ 26
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service ....... 27
    5.1 Encoding GS Using Real-Time VBR ............................. 28
    5.2 Encoding GS Using CBR ....................................... 29
    5.3 Encoding GS Using Non-Real-Time VBR ......................... 30
    5.4 Encoding GS Using ABR ....................................... 30
    5.5 Encoding GS Using UBR ....................................... 30
    5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ...................... 31
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service .. 32
    6.1 Encoding CLS Using Non-Real-Time VBR ........................ 32
    6.2 Encoding CLS Using ABR ...................................... 33
    6.3 Encoding CLS Using CBR ...................................... 35
    6.4 Encoding CLS Using Real-Time VBR ............................ 35
    6.5 Encoding CLS Using UBR ...................................... 35
    6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ..................... 35
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ...... 36
    7.1 Encoding Best Effort Service Using UBR ...................... 37
8.0 Security Considerations ......................................... 38
9.0 Acknowledgements ................................................ 38
Appendix 1  Abbreviations ........................................... 39
References .......................................................... 40
Authors' Addresses .................................................. 42
Full Copyright Statement ............................................ 43
        
1.0 Introduction ....................................................  3
    1.1 General System Architecture .................................  4
    1.2 Related Documents ...........................................  7
2.0 Major Protocol Features for Traffic Management and QoS ..........  8
    2.1 Service Category and Bearer Capability ......................  8
        2.1.1 Service Categories for Guaranteed Service .............  9
        2.1.2 Service Categories for Controlled Load ................ 10
        2.1.3 Service Categories for Best Effort .................... 11
    2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions . 11
    2.3 ATM Adaptation Layer ........................................ 13
    2.4 Broadband Low Layer Information ............................. 13
    2.5 Traffic Descriptors ......................................... 13
        2.5.1 Translating Traffic Descriptors for Guaranteed Service. 15
        2.5.2 Translating Traffic Descriptors for Controlled Load
              Service  .............................................. 18
        2.5.3 Translating Traffic Descriptors for Best Effort Service 19
    2.6 QoS Classes and Parameters .................................. 19
    2.7 Additional Parameters -- Frame Discard Mode ................. 22
3.0 Additional IP-Integrated Services Protocol Features ............. 22
    3.1 Path Characterization Parameters for IP Integrated Services . 22
    3.2 Handling of Excess Traffic .................................. 24
    3.3 Use of Guaranteed Service Adspec Parameters and Slack Term .. 25
4.0 Miscellaneous Items ............................................. 26
    4.1 Units Conversion ............................................ 26
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service ....... 27
    5.1 Encoding GS Using Real-Time VBR ............................. 28
    5.2 Encoding GS Using CBR ....................................... 29
    5.3 Encoding GS Using Non-Real-Time VBR ......................... 30
    5.4 Encoding GS Using ABR ....................................... 30
    5.5 Encoding GS Using UBR ....................................... 30
    5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ...................... 31
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service .. 32
    6.1 Encoding CLS Using Non-Real-Time VBR ........................ 32
    6.2 Encoding CLS Using ABR ...................................... 33
    6.3 Encoding CLS Using CBR ...................................... 35
    6.4 Encoding CLS Using Real-Time VBR ............................ 35
    6.5 Encoding CLS Using UBR ...................................... 35
    6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ..................... 35
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ...... 36
    7.1 Encoding Best Effort Service Using UBR ...................... 37
8.0 Security Considerations ......................................... 38
9.0 Acknowledgements ................................................ 38
Appendix 1  Abbreviations ........................................... 39
References .......................................................... 40
Authors' Addresses .................................................. 42
Full Copyright Statement ............................................ 43
        
1.0 Introduction
1.0 介绍

We consider the problem of providing IP Integrated Services [2] with an ATM subnetwork. This document is intended to be consistent with the rsvp protocol [3] for IP-level resource reservation, although it applies also in the general case where GS and CLS services are supported through other mechanisms. In the ATM network, we consider ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6]. The latter uses the more complete service model of the ATM Forum's TM 4.0 specification [7, 8].

我们考虑用ATM子网提供IP综合业务〔2〕的问题。本文件旨在与IP级资源预留的rsvp协议[3]保持一致,尽管它也适用于通过其他机制支持GS和CLS服务的一般情况。在ATM网络中,我们考虑ATM论坛UNI信令,版本3、3.1和4〔4, 5, 6〕。后者使用ATM论坛TM 4.0规范中更完整的服务模型[7,8]。

This is a complex problem with many facets. In this document, we focus on the service types, parameters and signalling elements needed for service interoperation. The resulting service mappings can be used to provide effective end-to-end Quality of Service (QoS) for IP traffic that traverses ATM networks.

这是一个多方面的复杂问题。在本文档中,我们重点讨论服务互操作所需的服务类型、参数和信令元素。由此产生的服务映射可用于为通过ATM网络的IP流量提供有效的端到端服务质量(QoS)。

The IP services considered are Guaranteed Service (GS) [9] and Controlled Load Service (CLS) [10]. We also discuss the default Best Effort Service (BE) in parallel with these. Our recommendations for BE are intended to be consistent with RFC 1755 [11], and [12], which define how ATM VCs can be used in support of normal BE IP service. The ATM services we consider are:

考虑的IP服务是保证服务(GS)[9]和控制负载服务(CLS)[10]。我们还同时讨论了默认的尽力而为服务(BE)。我们对BE的建议旨在与RFC 1755[11]和[12]一致,RFC 1755[11]和[12]定义了如何使用ATM VCs支持正常BE IP服务。我们考虑的ATM服务是:

CBR Constant Bit Rate rtVBR Real-time Variable Bit Rate nrtVBR Non-real-time Variable Bit Rate UBR Unspecified Bit Rate ABR Available Bit Rate

CBR恒定比特率rtVBR实时可变比特率nrtVBR非实时可变比特率UBR未指定比特率ABR可用比特率

In the case of UNI 3.x signalling, where these service are not all clearly distinguishable, we identify the appropriate available services.

在UNI 3.x信令的情况下,如果这些服务不是都可以清楚地区分,我们将确定适当的可用服务。

We recommend the following service mappings, since they follow most naturally from the service definitions:

我们建议使用以下服务映射,因为它们最自然地遵循服务定义:

        Guaranteed Service    ->     CBR or rtVBR
        Controlled Load       ->     nrtVBR or ABR (with a minimum
                                     cell rate)
        Best Effort           ->     UBR or ABR
        
        Guaranteed Service    ->     CBR or rtVBR
        Controlled Load       ->     nrtVBR or ABR (with a minimum
                                     cell rate)
        Best Effort           ->     UBR or ABR
        

For completeness, however, we provide detailed mappings for all service combinations in Sections 5, 6, 7 and identify how each meets or fails to meet the requirements of the higher level IP services. The reason for not restricting mappings to the most obvious or natural ones is that we cannot predict how widely available all of these services will be as ATM deployment evolves. A number of

但是,为了完整性,我们在第5、6、7节中提供了所有服务组合的详细映射,并确定每个组合如何满足或不满足更高级别IP服务的要求。不将映射限制为最明显或最自然的映射的原因是,随着ATM部署的发展,我们无法预测所有这些服务的可用性有多广。一些

differences in service definitions, such as the treatment of packets in excess of the flow traffic descriptor, make service mapping a relatively complicated subject.

服务定义的差异,例如对超过流流量描述符的数据包的处理,使得服务映射成为一个相对复杂的主题。

The remainder of this introduction provides a general discussion of the system configuration and other assumptions. Section 2 considers the relevant ATM protocol elements and the corresponding features of Guaranteed, Controlled Load and Best Effort services (the latter being the default "service"). Section 3 discusses a number of remaining features of the IP services and how they can be handled on an ATM subnetwork. Section 4 addresses the conversion of traffic descriptors to account for ATM-layer overheads. Section 5 gives the detailed VC setup parameters for Guaranteed Service, and considers the effect of using each of the ATM service categories. Section 6 provides a similar treatment for Controlled Load Service. Section 7 considers Best Effort service.

本简介的其余部分将对系统配置和其他假设进行一般性讨论。第2节考虑了相关的ATM协议元素以及保证、控制负载和尽力而为服务(后者是默认的“服务”)的相应特征。第3节讨论了IP服务的一些剩余功能,以及如何在ATM子网上处理这些功能。第4节讨论了如何将流量描述符转换为ATM层开销。第5节给出了保证服务的详细VC设置参数,并考虑了使用每个ATM服务类别的影响。第6节为受控负载服务提供了类似的处理方法。第7节考虑尽力而为的服务。

This document is only a part of the total solution to providing the interworking of IP integrated services with ATM subnetworks. The important issue of VC management, including flow aggregation, is considered in [13, 14, 15]. We do not consider how routing, QoS sensitive or not, interacts with the use of ATM VCs. We expect that a considerable degree of implementation latitude will exist, even within the guidelines presented here. Many aspects of interworking between IP and ATM will depend on economic factors, and will not be subject to standardization.

本文档只是提供IP综合业务与ATM子网互通的总体解决方案的一部分。在[13,14,15]中考虑了VC管理的重要问题,包括流聚合。我们不考虑路由,QoS敏感与否,与ATM VCS的使用交互。我们预计,即使在这里提出的准则范围内,也将存在相当大的执行自由度。IP和ATM之间互通的许多方面将取决于经济因素,而不是标准化。

1.1 General System Architecture
1.1 通用系统架构

We assume that the reader has a general working knowledge of IP, rsvp and ATM protocols. The network architecture we consider is illustrated in Figure 1. An IP-attached host may send unicast datagrams to another host, or may use an IP multicast address to send packets to all of the hosts which have "joined" the multicast "tree". In either case, a destination host may then use RSVP to establish resource reservation in routers along the internet path for the data flow.

我们假设读者具有IP、rsvp和ATM协议的一般工作知识。我们考虑的网络体系结构如图1所示。IP连接的主机可以向另一台主机发送单播数据报,或者可以使用IP多播地址向“加入”多播“树”的所有主机发送数据包。在这两种情况下,目标主机随后可以使用RSVP在路由器中沿因特网路径为数据流建立资源预留。

An ATM network lies in the path (chosen by the IP routing), and consists of one or more ATM switches. It uses SVCs to provide both resources and QoS within the ATM cloud. These connections are set up, added to (in the case of multipoint trees), torn down, and controlled by the edge devices, which act as both IP routers and ATM interfaces, capable of initiating and managing VCs across the ATM user-to-network (UNI) interface. The edge devices are assumed to be fully functional in both the IP int-serv/RSVP protocols and the ATM UNI protocols, as well as translating between them.

ATM网络位于路径中(由IP路由选择),由一个或多个ATM交换机组成。它使用SVC在ATM云中提供资源和QoS。这些连接由边缘设备设置、添加(在多点树的情况下)、拆除和控制,边缘设备充当IP路由器和ATM接口,能够通过ATM用户到网络(UNI)接口启动和管理VCs。假定边缘设备在IP int serv/RSVP协议和ATM UNI协议中以及在它们之间的转换中都是完全功能的。

                                 ATM Cloud
                            -----------------
        H ----\            (                 )       /------- H
        H ---- R -- R -- E-( X  --  X  --  X )-E -- R -- R -- H
        H ----/     |      (                 )       \
                    |       -----------------         \------ H
        H ----------R
        
                                 ATM Cloud
                            -----------------
        H ----\            (                 )       /------- H
        H ---- R -- R -- E-( X  --  X  --  X )-E -- R -- R -- H
        H ----/     |      (                 )       \
                    |       -----------------         \------ H
        H ----------R
        

Figure 1: Network Architecture with Hosts (H), Routers (R), Edge Devices (E) and ATM Switches (X).

图1:具有主机(H)、路由器(R)、边缘设备(E)和ATM交换机(X)的网络架构。

When considering the edge devices with respect to traffic flowing from source to destination, the upstream edge device is called the "ingress" point and the downstream device the "egress" point. The edge devices may be considered part of the IP internet or part of the ATM cloud, or both. They process RSVP messages, reserve resources, and maintain soft state (in the control path), and classify and schedule packets (in the data path). They also initiate ATM connections by signalling, and accept or refuse connections signalled to them. They police and schedule cells going into the ATM cloud. The service mapping function occurs when an IP-level reservation (RESV message) triggers the edge device to translate the RSVP service requirements into ATM VC (UNI) semantics.

当考虑从源到目的地的流量的边缘设备时,上游边缘设备称为“入口”点,下游设备称为“出口”点。边缘设备可能被视为IP互联网的一部分或ATM云的一部分,或两者兼而有之。它们处理RSVP消息、保留资源和维护软状态(在控制路径中),并分类和调度数据包(在数据路径中)。它们还通过发信号启动ATM连接,并接受或拒绝发信号给它们的连接。他们对进入ATM云中的信元进行监控和调度。当IP级别保留(RESV消息)触发边缘设备将RSVP服务需求转换为ATM VC(UNI)语义时,就会出现服务映射功能。

A range of VC management policies are possible, which determine whether a flow initiates a new VC or joins an existing one. VCs are managed according to a combination of standards and local policy rules, which are specific to either the implementation (equipment) or the operator (network service provider). Point-to-multipoint connections within the ATM cloud can be used to support general IP multicast flows. In ATM, a point to multipoint connection can be controlled by the source (or root) node, or a leaf initiated join (LIJ) feature in ATM may be used. The topic of VC management is considered at length in other ISSLL documents [13, 14, 15].

一系列VC管理策略是可能的,它们决定了流是启动新VC还是加入现有VC。VCs根据标准和本地政策规则的组合进行管理,这些规则针对实施(设备)或运营商(网络服务提供商)。ATM云中的点对多点连接可用于支持一般IP多播流。在ATM中,点对多点连接可以由源(或根)节点控制,或者可以使用ATM中的叶发起连接(LIJ)功能。其他ISSLL文件[13、14、15]详细讨论了风险投资管理的主题。

Figure 2 shows the functions of an edge device, summarizing the work not part of IP or ATM abstractly as an InterWorking Function (IWF), and segregating the control and data planes.

图2显示了边缘设备的功能,将不属于IP或ATM的工作抽象地总结为互通功能(IWF),并将控制平面和数据平面分离。

   IP                                                ATM
                         ____________________
                        |        IWF         |
                        |                    |
   admission and   <--> | service mapping    | <-->  ATM
   policy control       | VC management      |       signalling &
                        | address resolution |       admission
                        |....................|       control
                        |                    |
   classification,      |ATM Adaptation Layer|       cell
   policing &      <--> | Segmentation and   | <-->  scheduling/
   scheduling           |  Reassembly        |       shaping
                        | Buffering          |
                         ____________________
        
   IP                                                ATM
                         ____________________
                        |        IWF         |
                        |                    |
   admission and   <--> | service mapping    | <-->  ATM
   policy control       | VC management      |       signalling &
                        | address resolution |       admission
                        |....................|       control
                        |                    |
   classification,      |ATM Adaptation Layer|       cell
   policing &      <--> | Segmentation and   | <-->  scheduling/
   scheduling           |  Reassembly        |       shaping
                        | Buffering          |
                         ____________________
        

Figure 2: Edge Device Functions showing the IWF

图2:显示IWF的边缘设备功能

In the logical view of Figure 2, some functions, such as scheduling, are shown separately, since these functions are present on both the IP and ATM sides. However it may be possible in an integrated implementation to combine such functions.

在图2的逻辑视图中,一些功能(如调度)单独显示,因为这些功能同时存在于IP和ATM端。但是,在集成实现中,可以将这些功能组合在一起。

The service mapping and VC management functions can be highly interdependent. For example: (i) Multiple integrated-services flows may be aggregated to use one point-to-multipoint VC. In this case, we assume the IP flows are of the same service type and their parameters have been merged appropriately. (ii) The VC management function may choose to allocate extra resources in anticipation of further reservations or based on an empiric of changing TSpecs. (iii) There MUST exist a path for best effort flows and for sending the rsvp control messages. How this interacts with the establishment of VCs for QoS traffic may alter the desired characteristics of those VCs. See [13, 14, 15] for further details on VC management.

服务映射和VC管理功能可以高度相互依赖。例如:(i)可以聚合多个集成服务流以使用一点对多点VC。在这种情况下,我们假设IP流是相同的服务类型,并且它们的参数已被适当地合并。(ii)风险投资管理职能部门可选择分配额外资源,以预期进一步的预订或基于TSPEC变化的经验。(iii)必须有一条路径用于最大努力流和发送rsvp控制消息。这与为QoS流量建立VCs的交互方式可能会改变这些VCs的期望特性。有关VC管理的更多详细信息,请参见[13,14,15]。

Therefore, in discussing the service mapping problem, we will assume that the VC management function of the IWF can always express its result in terms of an IP-level service with some QoS and TSpec. The service mapping algorithm can then identify the appropriate VC parameters as if a new VC were to be created for this service. The VC management function can then use this information consistent with its own policy, which determines whether the resulting action uses new or existing VCs.

因此,在讨论服务映射问题时,我们将假设IWF的VC管理功能始终可以用具有一定QoS和TSpec的IP级别服务来表示其结果。然后,服务映射算法可以识别适当的VC参数,就好像要为此服务创建新的VC一样。然后,VC管理功能可以使用与其自身策略一致的信息,该策略确定最终操作使用的是新的还是现有的VC。

1.2 Related Documents
1.2 相关文件

Earlier ATM Forum documents combined signalling, traffic management and other areas into a single document, e.g., UNI 3.0 [4] and UNI 3.1 [5]. The 3.1 release was used to correct errors and fix alignment with the ITU. While UNI 3.0 and 3.1 are incompatible in terms of actual codepoints, the semantics are generally the same. Therefore, we will often refer to UNI 3.x to mean either version of the ATM protocol.

早期的ATM论坛文件将信令、流量管理和其他领域合并为一个文件,例如UNI 3.0[4]和UNI 3.1[5]。3.1版本用于纠正错误并修复与ITU的一致性。虽然UNI 3.0和3.1在实际代码点方面不兼容,但语义通常是相同的。因此,我们通常将UNI 3.x称为ATM协议的任一版本。

After 3.1, the ATM Forum released documents separately for each technical working group. The UNI Signalling 4.0 [6] and Traffic Management 4.0 [7] documents represent a consistent overall ATM protocol, and we will sometime refer to the combination as TM/UNI 4.0.

3.1之后,ATM论坛为每个技术工作组分别发布了文件。UNI信令4.0[6]和流量管理4.0[7]文档代表了一个一致的整体ATM协议,我们有时将其组合称为TM/UNI 4.0。

Within the IETF, related material includes the work of the rsvp [3], int-serv [2, 9, 10, 16, 17] and ion working groups [11, 12]. Rsvp defines the resource reservation protocol (which is analogous to signalling in ATM). Int-serv defines the behavior and semantics of particular services (analogous to the Traffic Management working group in the ATM Forum). Ion defines interworking of IP and ATM for traditional Best Effort service, and generally covers issues related to IP/ATM routing and addressing.

在IETF中,相关材料包括rsvp[3]、int serv[2,9,10,16,17]和ion工作组[11,12]的工作。Rsvp定义了资源预留协议(类似于ATM中的信令)。intserv定义了特定服务的行为和语义(类似于ATM论坛中的流量管理工作组)。Ion为传统的尽力而为服务定义了IP和ATM的互通,通常涵盖与IP/ATM路由和寻址相关的问题。

A large number of ATM signalling details are covered in RFC 1755 [10]; e.g., differences between UNI 3.0 and UNI 3.1, encapsulation, frame-relay interworking, etc. These considerations extend to IP over ATM with QoS as well. The description given in this document of IP Best Effort service (i.e. the default behavior) over ATM is intended to be consistent with RFC 1755 and it's extension for UNI 4.0 [11], and those documents are to be considered definitive. For non-best-effort services, certain IP/ATM features will diverge from the following RFC 1755. We have attempted to note such differences explicitly. (For example, best effort VCs may be taken down on timeout by either edge device, while QoS VCs are only removed by the upstream edge device when the corresponding rsvp reservation is deleted.)

RFC 1755[10]涵盖了大量ATM信令细节;e、 例如,UNI 3.0和UNI 3.1之间的差异、封装、帧中继互通等。这些考虑因素也扩展到具有QoS的IP over ATM。本文件中对ATM上IP尽力而为服务(即默认行为)的描述旨在与RFC 1755及其对UNI 4.0[11]的扩展保持一致,这些文件将被视为最终文件。对于非尽力而为的服务,某些IP/ATM功能将与以下RFC 1755有所不同。我们试图明确指出这些差异。(例如,任何一个边缘设备都可以在超时时关闭尽力而为的VCs,而只有在删除相应的rsvp保留时,上游边缘设备才会删除QoS VCs。)

Another related document is RFC 1821 [17], which represents an early discussion of issues involved with interoperating IP and ATM protocols for integrated services and QoS.

另一个相关文档是RFC1821[17],它代表了对集成服务和QoS的互操作IP和ATM协议所涉及问题的早期讨论。

2.0 Major Protocol Features for Traffic Management and QoS
2.0 用于流量管理和QoS的主要协议功能

The ATM Call Setup is sent by the ingress edge device to the ATM network to establish end-to-end (ATM) service. This setup contains the following information.

ATM呼叫设置由入口边缘设备发送到ATM网络,以建立端到端(ATM)服务。此设置包含以下信息。

Service Category/Broadband Bearer Capability AAL Parameters Broadband Low Layer Information Calling and Called Party Addressing Information Traffic Descriptors QoS Class and/or Parameters Additional Parameters of TM/UNI 4.0

服务类别/宽带承载能力AAL参数宽带低层信息呼叫和被叫方寻址信息流量描述符QoS等级和/或参数TM/UNI 4.0的附加参数

In this section, we discuss each of these items as they relate to creating ATM VCs suitable for GS, CLS and BE services. We do not discuss routing and addressing at all, since they are (at least presently) independent of QoS. Following the section on service categories, we discuss tagging and conformance definitions for IP and ATM. These do not appear explicitly as set-up parameters in the above list, since they are implied by the policing method used.

在本节中,我们将讨论与创建适用于GS、CLS和BE服务的ATM VCs相关的每个项目。我们根本不讨论路由和寻址,因为它们(至少目前)独立于QoS。在服务类别部分之后,我们将讨论IP和ATM的标记和一致性定义。在上面的列表中,这些参数不会显式显示为设置参数,因为它们由所使用的策略方法暗示。

2.1 Service Category and Bearer Capability
2.1 业务类别和承载能力

The highest level of abstraction distinguishing features of ATM VCs is in the service category or bearer capability. Service categories were introduced in TM/UNI 4.0; previously the bearer capability was used to discriminate at this level.

ATM VCs的最高抽象层次区别特征在于服务类别或承载能力。TM/UNI 4.0引入了服务类别;以前,承载能力用于在该级别进行区分。

These elements indicate the general properties of a VC: whether there is a real-time delay constraint, whether the traffic is constant or variable rate, the applicable traffic and QoS description parameters and (implicitly) the complexity of some supporting switch mechanisms (e.g., ABR).

这些元素表示VC的一般属性:是否存在实时延迟约束,流量是恒定的还是可变的,适用的流量和QoS描述参数,以及(隐含地)某些支持交换机制(例如ABR)的复杂性。

For UNI 3.0 and UNI 3.1, there are only two distinct options for bearer capabilities (in our context):

对于UNI 3.0和UNI 3.1,承载能力只有两种不同的选择(在我们的上下文中):

BCOB-A: constant rate, timing required, unicast/multipoint; BCOB-C: variable rate, timing not required, unicast/multipoint.

BCOB-A:恒定速率,需要定时,单播/多点;BCOB-C:可变速率,不需要定时,单播/多点。

A third capability, BCOB-X, can be used as a substitute for the above two capabilities, with its dependent parameters (traffic type and timing requirement) set appropriately. The distinction between the BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and BCOB-C constructs is whether the ATM network is to provide pure cell relay service or interwork with other technologies (with interoperable signalling), such as narrowband ISDN. Where this

第三种功能BCOB-X可用于替代上述两种功能,并适当设置其相关参数(流量类型和定时要求)。BCOB-X公式和“等效”(出于我们的目的)BCOB-A和BCOB-C结构之间的区别在于ATM网络是提供纯小区中继服务还是与其他技术(具有可互操作的信令)互通,如窄带ISDN。这是哪里

distinction is applicable, the appropriate code SHOULD be used (see [5] and related ITU specs, e.g., I.371).

如果有区别,应使用适当的代码(见[5]和相关的ITU规范,如I.371)。

In TM/UNI 4.0 the service categories are:

在TM/UNI 4.0中,服务类别包括:

Constant Bit Rate (CBR) Real-time Variable Bit Rate (rtVBR) Non-real-time Variable Bit Rate (nrtVBR) Unspecified Bit Rate (UBR) Available Bit Rate (ABR)

恒定比特率(CBR)实时可变比特率(rtVBR)非实时可变比特率(nrtVBR)未指定比特率(UBR)可用比特率(ABR)

The first two of these are real-time services, so that rtVBR is new to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR exists in all specifications, although it is called "best effort" in UNI 3.x. In either case it is indicated by the "best effort" indication flag (and the QoS Class set to 0).

前两个是实时服务,因此rtVBR是TM/UNI 4.0的新功能。ABR服务也是TM/UNI 4.0的新功能。UBR存在于所有规范中,尽管它在UNI 3.x中被称为“尽力而为”。在任何一种情况下,它都由“尽力而为”指示标志指示(并且QoS等级设置为0)。

The Service Category in TM/UNI 4.0 is encoded into the same signalled Information Element (IE) as the Bearer Capability in UNI 3.x, for the purpose of backward compatibilty. Thus, we use the convention of referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for TM/UNI 4.0 (where the bearer capability is implicit). When we refer to the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we are describing a UNI 3.x signalling message.

为了向后兼容,TM/UNI 4.0中的服务类别被编码到与UNI 3.x中的承载能力相同的信号信息元素(IE)中。因此,对于TM/UNI 4.0(承载能力是隐含的),我们使用引用服务类别(CBR、rtVBR、nrtVBR、UBR、ABR)的约定。当我们明确提到承载能力(BCOB-A、BCOB-C、BCOB-X)时,我们描述的是UNI 3.X信令消息。

In principle, it is possible to support any service through the use of BCOB-A/CBR. This is because the CBR service is equivalent to having a "pipe" of a specified bandwidth. However, it may be significantly more efficient to use the other ATM services where applicable and available [17].

原则上,通过使用BCOB-A/CBR可以支持任何服务。这是因为CBR服务相当于具有指定带宽的“管道”。然而,在适用和可用的情况下,使用其他ATM服务可能会大大提高效率[17]。

2.1.1 Service Categories for Guaranteed Service
2.1.1 保证服务的服务类别

There are two possible mappings for GS:

GS有两种可能的映射:

CBR (BCOB-A) rtVBR

CBR(BCOB-A)rtVBR

Real-time support is REQUIRED for GS. Thus in UNI 3.x, the Bearer Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used. In TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may encourage recovery of allocated bandwidth left unused by a source. It also accommodates more bursty sources with a larger token bucket burst parameter, and permits the use of tagging for excess traffic (see Section 2.2).

GS需要实时支持。因此,在UNI 3.x中,必须使用承载类BCOB-A(或等效的BCOB-x公式)。在TM/UNI 4.0中,CBR或rtVBR都是合适的。使用rtVBR可能会鼓励恢复源未使用的已分配带宽。它还可以容纳具有更大令牌桶突发参数的更多突发源,并允许对多余流量使用标记(见第2.2节)。

Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good matches for the GS service. These provide no delay estimates and cannot guarantee consistently low delay for every packet.

BCOB-C承载类和nrtVBR、UBR、ABR都不适合GS服务。它们提供无延迟估计,并且不能保证每个数据包都具有一致的低延迟。

For BCOB-A or CBR, specification of a peak cell rate (PCR) is REQUIRED by ATM standards. In these cases, PCR is the nominal clearing rate with a nominal jitter toleration (bucket size), CDVT.

对于BCOB-A或CBR,ATM标准要求指定峰值信元速率(PCR)。在这些情况下,PCR是具有标称抖动容忍度(桶大小)CDVT的标称清除率。

When rtVBR is specifed, two rates, PCR and SCR are REQUIRED (by ATM standards). This models bursty traffic with specified peak and sustainable rates. The corresponding ATM token bucket depth values are CDVT, and CDVT+BT, respectively.

当指定rtVBR时,需要两种速率,PCR和SCR(根据ATM标准)。该模型对具有指定峰值和可持续速率的突发流量进行建模。相应的ATM令牌桶深度值分别为CDVT和CDVT+BT。

2.1.2 Service Categories for Controlled Load
2.1.2 受控负载的服务类别

There are three possible good mappings for CLS:

CLS有三种可能的良好映射:

CBR (BCOB-A) nrtVBR (BCOB-C) ABR

CBR(BCOB-A)nrtVBR(BCOB-C)ABR

Note that under UNI 3.x, there are equivalent services to CBR and nrtVBR, but not ABR. The first, with a CBR/BCOB-A connection, provides a higher level of QoS than is necessary, but it may be convenient to simply allocate a fixed-rate "pipe", which we expect to be ubiquitously supported in ATM networks. However unless this is the only choice available, it would probably be wasteful of network resources.

注意,在UNI 3.x下,有与CBR和nrtVBR同等的服务,但没有ABR。第一种是CBR/BCOB-a连接,它提供了比必要的更高级别的QoS,但只需分配一个固定速率的“管道”可能会很方便,我们希望它在ATM网络中得到普遍支持。但是,除非这是唯一可用的选择,否则可能会浪费网络资源。

The nrtVBR/BCOB-C category is perhaps the best match, since it provides for allocation of bandwidth and buffers with an additional peak rate indication, similar to the CLS TSpec. Excess traffic can be handled by CLP bit tagging with VBR.

nrtVBR/BCOB-C类别可能是最好的匹配,因为它提供了带宽和缓冲区的分配,并带有额外的峰值速率指示,类似于CLS TSpec。使用VBR进行CLP位标记可以处理多余的流量。

The ABR category with a positive MCR aligns with the CLS idea of "best effort with a floor." The ATM network agrees to forward cells with a rate of at least MCR, which MUST be directly converted from the token bucket rate of the receiver TSpec. The bucket size parameter measures approximately the amount of buffer necessary at the IWF. This buffer serves to absorb the bursts allowed by the token bucket, since they cannot be passed directly into an ABR VC.

具有正MCR的ABR类别与CLS的“最大努力有底线”思想一致。ATM网络同意以至少MCR的速率转发信元,该速率必须直接从接收器TSpec的令牌桶速率转换而来。bucket size参数大致测量IWF所需的缓冲量。该缓冲区用于吸收令牌桶允许的突发,因为它们不能直接传递到ABR VC。

The rtVBR category can be used, although the edge device MUST then determine values for CTD and CDV. Since there are no corresponding IP-level parameters, their values are set as a matter of local policy.

可以使用rtVBR类别,但边缘设备必须确定CTD和CDV的值。由于没有相应的IP级别参数,因此根据本地策略设置其值。

The UBR category does not provide enough capability for Controlled Load. The point of CLS is to allow an allocation of resources. This is facilitated by the token bucket traffic descriptor, which is unavailable with UBR.

UBR类别没有为受控负载提供足够的能力。CLS的要点是允许资源分配。令牌桶流量描述符有助于实现这一点,该描述符在UBR中不可用。

2.1.3 Service Categories for Best Effort
2.1.3 尽力而为的服务类别

All of the service categories have the capability to carry Best Effort service, but the natural service category is UBR (or, in UNI 3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or rtVBR clearly could be used, and since the service is not real-time, a nrtVBR connection could also be used. In these cases the rate parameter used reflects a bandwidth allocation in support of the ingress edge device's best effort connectivity to the egress edge router. It would be normal for traffic from many source/destination pairs to be aggregated on this connection; indeed, since Best Effort is the default IP behavior, the individual flows are not normally identified or accounted for. CBR may be a preferred solution in the case where best effort traffic is sufficiently highly aggregated that a simple fixed-rate pipe is efficient. Both CBR and nrt-VBR provide explicit bandwidth allocation which may be useful for billing purposes. In the case of UBR, the network operator SHOULD allocate bandwidth for the overall service through the admission control function, although such allocation is not done explicitly per VC.

所有服务类别都有能力提供尽力而为的服务,但自然服务类别为UBR(或者,在UNI 3.x中为BCOB-C或BCOB-x,设置了尽力而为指示)。显然可以使用CBR或rtVBR,而且由于服务不是实时的,因此也可以使用nrtVBR连接。在这些情况下,所使用的速率参数反映了支持入口边缘设备到出口边缘路由器的最大努力连接的带宽分配。来自多个源/目的地对的流量在此连接上聚合是正常的;事实上,由于尽力而为是默认的IP行为,因此通常不会识别或说明各个流。如果尽力而为的流量聚合程度足够高,简单的固定速率管道是有效的,那么CBR可能是首选解决方案。CBR和nrt VBR都提供明确的带宽分配,这对于计费目的可能很有用。在UBR的情况下,网络运营商应通过准入控制功能为整个服务分配带宽,尽管这种分配不是按照VC明确完成的。

An ABR connection could similarly be used to support Best Effort traffic. Indeed, the support of data communications protocols such as TCP/IP is the explicit purpose for which ABR was designed. It is conceivable that a separate ABR connection would be made for each IP flow, although the normal case would probably have all IP Best Effort traffic with a common egress router sharing a single ABR connection.

ABR连接同样可用于支持尽力而为的通信。事实上,支持TCP/IP等数据通信协议是ABR设计的明确目的。可以想象,将为每个IP流建立单独的ABR连接,尽管在正常情况下,所有IP尽力而为流量都可能与共用一个ABR连接的公共出口路由器共享。

The rt-VBR service category may be considered less suitable, simply because both the real-time delay constraint and the use of SCR/BT add unnecessary complexity.

rt VBR服务类别可能被认为不太合适,因为实时延迟约束和SCR/BT的使用都增加了不必要的复杂性。

See specifications from the IETF ion working group [10, 11] for related work on support of Best Effort service with ATM.

参见IETF ion工作组[10,11]的规范,了解支持ATM最大努力服务的相关工作。

2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions
2.2 信元丢失优先级位、标记和一致性定义

Each ATM cell header carries a Cell Loss Priority (CLP) bit. Cells with CLP=1 are said to be "tagged" or "marked" and have lower priority. This tagging may be done by the source, to indicate relative priority within the VC, or by a switch, to indicate traffic in violation of policing parameters. Options involving the use of tagging are decided at call setup time.

每个ATM信元报头都带有信元丢失优先级(CLP)位。CLP=1的单元格被称为“标记”或“标记”,优先级较低。此标记可由源完成,以指示VC内的相对优先级,或由交换机完成,以指示违反监管参数的流量。涉及使用标签的选项在呼叫设置时决定。

A Conformance Definition is a rule that determines whether a cell is conforming to the traffic descriptor of the VC. The conformance definition is given in terms of a Generic Cell Rate Algorithm (GCRA), also known as a "leaky bucket" algorithm, for CBR and VBR services. The conformance definition also specifies rules for tagging traffic in excess of the {SCR, MBS} GCRA traffic descriptor. (Note, the term "compliance" in ATM is used to describe the behavior of a connection, as opposed to "conformance", which applies to a single cell.)

一致性定义是确定单元格是否符合VC的流量描述符的规则。一致性定义是根据CBR和VBR服务的通用信元速率算法(GCRA)给出的,也称为“漏桶”算法。一致性定义还指定了标记超过{SCR,MBS}GCRA流量描述符的流量的规则。(注意,ATM中的术语“一致性”用于描述连接的行为,而不是适用于单个信元的“一致性”。)

The network may tag cells that are non-conforming, rather than dropping them if the VC set-up requests tagging and the network supports the tagging option. When tagging is used and congestion occurs, a switch MUST attempt to discard tagged cells in preference to discarding CLP=0 cells. However, the mechanism for doing this is completely implementation specific. The behavior that best meets the requirements of IP Integrated Services is where tagged cells are treated as "best effort" in the sense that they are transported when bandwidth is available, queued when buffers are available, and dropped when resources are overcommitted. ATM standards, however, do not explicitly specify treatment of tagged traffic. Providers of GS and CLS service with ATM subnetworks SHOULD ascertain the actual behavior of ATM implementation with respect to tagged cells.

如果VC设置请求标记且网络支持标记选项,则网络可以标记不符合要求的单元格,而不是丢弃它们。当使用标记且发生拥塞时,交换机必须尝试放弃标记的单元格,而不是放弃CLP=0单元格。但是,执行此操作的机制完全是特定于实现的。最符合IP集成服务要求的行为是,标记的小区被视为“尽力而为”,即它们在带宽可用时传输,在缓冲区可用时排队,在资源过度使用时丢弃。然而,ATM标准并没有明确规定标记流量的处理。具有ATM子网的GS和CLS服务提供商应确定ATM实施与标记信元相关的实际行为。

Since GS and CLS services REQUIRE excess traffic to be treated as best effort, the tagging option SHOULD always be chosen (if supported) in the VC setup as a means of "downgrading" the cells comprising non-conformant packets. The term "best effort" can be interpreted in two ways. The first is as a service class that, for example, may be implemented as a separate queue. The other sense is more generic, meaning that the network makes a best effort to transport the traffic. A reasonable interpretation of this is that a network with no contending traffic would transport the packet, while a very congested network would drop the packet. A mechanism that tags best effort packets with lower loss priority (such as with the ATM CLP bit) would drop some of these packets, but would not reorder the remaining ones with respect to the conforming portion of the flow. The "best effort" mechanism for excess traffic does not necessarily have to be the same as that for best effort "service", as long as it fits this generic sense of best effort.

由于GS和CLS服务需要尽最大努力处理多余的流量,因此应始终在VC设置中选择标记选项(如果支持),作为“降级”包含不一致数据包的单元的一种方法。“最大努力”一词可以用两种方式解释。第一种是作为服务类,例如,可以作为单独的队列实现。另一种意义更为普遍,即网络尽最大努力传输流量。对此的合理解释是,没有竞争流量的网络将传输数据包,而非常拥挤的网络将丢弃数据包。标记具有较低丢失优先级的尽力而为数据包(例如使用ATM CLP位)的机制将丢弃其中一些数据包,但不会根据流的一致性部分对其余数据包重新排序。过剩流量的“尽力而为”机制不一定与尽力而为的“服务”机制相同,只要它符合这种一般意义上的尽力而为。

There are three conformance definitions of VBR service (for both rtVBR and nrtVBR) to consider. In VBR, only the conformance definition VBR.3 supports tagging and applies the GCRA with rate PCR to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the CLP=0 cells. This conformance definition SHOULD always be used with a VBR service supporting IP integrated services. For UBR service, conformance definition UBR.2 supports the use of tagging, but a CLP=1 cell does not imply non-conformance; rather, it may be used by the

VBR服务有三个一致性定义(对于RTVBR和NRTVBR)都要考虑。在VBR中,只有一致性定义VBR.3支持标记,并将带有速率PCR的GCRA应用于聚合CLP=0+1单元格,将带有速率SCR的另一个GCRA应用于CLP=0单元格。此一致性定义应始终与支持IP集成服务的VBR服务一起使用。对于UBR服务,一致性定义UBR.2支持使用标记,但CLP=1单元格并不意味着不一致;相反,它可能会被

network to indicate congestion.

网络拥塞指示。

In TM/UNI 4.0 tagging is not a feature of the conformance definitions for the CBR or ABR service categories. (Since conformance definitions are generally network specific, some implementations CBR or ABR may, in fact, use tagging in some way.) Wherever an ATM network does support tagging, in the sense of transporting CLP=1 cells on a "best effort" basis, it is a useful and preferable mechanism for handling excess traffic.

在TM/UNI 4.0中,标记不是CBR或ABR服务类别一致性定义的特征。(由于一致性定义通常是特定于网络的,因此CBR或ABR的一些实现实际上可能以某种方式使用标记。)只要ATM网络支持标记,在“尽力而为”的基础上传输CLP=1信元的意义上,它是处理多余通信量的有用且优选的机制。

It is always better for the IWF to tag cells when it can anticipate that the ATM network would do so. This is because the IWF knows the IP packet boundaries and can tag all of the cells corresponding to a packet. If left to the ATM layer UPC, the network would inevitably drop some of the cells of a packet while carrying others, which would then be dropped by the receiver. Therefore, the IWF, knowing the VC GCRA parameters, SHOULD always anticipate the cells which will be tagged by the ATM UPC and tag all of the cells uniformly across each affected packet. See Section 3.2 for further discussion of excess traffic.

当IWF可以预期ATM网络会这样做时,它总是更好地标记信元。这是因为IWF知道IP分组边界,并且可以标记与分组对应的所有小区。如果让ATM层UPC处理,网络将不可避免地丢弃数据包中的一些信元,同时携带其他信元,然后由接收方丢弃。因此,知道VC GCRA参数的IWF应始终预测将由ATM UPC标记的信元,并在每个受影响的分组上均匀标记所有信元。关于超额交通量的进一步讨论,请参见第3.2节。

2.3 ATM Adaptation Layer
2.3 ATM适配层

The AAL type 5 encoding SHOULD be used, as specified in RFC 1483 and RFC 1755. For AAL-5, specification of the maximum SDU size in both the forward and reverse directions is REQUIRED. Both GS and CLS specify a maximum packet size, M, as part of the TSpec and this value SHOULD be used (corrected for AAL headers) as the maximum SDU in each direction for unicast connections, and for unidirectional point-to-multipoint connections. When multiple flows are aggregated into a single VC, the M parameters of the receiver TSpecs are merged according to rules given in the GS and CLS specs.

按照RFC 1483和RFC 1755的规定,应使用AAL类型5编码。对于AAL-5,需要规定正向和反向的最大SDU尺寸。GS和CLS都指定了最大数据包大小M作为TSpec的一部分,该值应作为单播连接和单向点对多点连接的每个方向上的最大SDU使用(针对AAL报头进行了更正)。当多个流聚合到单个VC中时,根据GS和CLS规范中给出的规则合并接收器TSPEC的M个参数。

2.4 Broadband Low Layer Information
2.4 宽带低层信息

The B-LLI Information Element is transferred transparently by the ATM network between the edge devices and is used to specify the encapsulation method. Multiple B-LLI IEs may be sent as part of negotiation. The LLC/SNAP encapsulation [18] SHOULD be supported as the default, but "null" or "VC encapsulation" MAY also be allowed. Implementations SHOULD follow RFC 1577 [19] and RFC 1755 [10] for BLLI usage.

B-LLI信息元素通过ATM网络在边缘设备之间透明传输,并用于指定封装方法。作为协商的一部分,可以发送多个B-LLI。默认情况下应支持LLC/SNAP封装[18],但也允许使用“null”或“VC封装”。BLLI的使用应遵循RFC 1577[19]和RFC 1755[10]的规定。

2.5 Traffic Descriptors
2.5 流量描述符

The ATM traffic descriptor always contains a peak cell rate (PCR) (for each direction). For VBR services it also contains a sustainable cell rate (SCR) and maximum burst size (MBS). The SCR

ATM流量描述符始终包含峰值信元速率(PCR)(对于每个方向)。对于VBR服务,它还包含可持续的信元速率(SCR)和最大突发大小(MBS)。SCR

and MBS form a leaky bucket pair (rate, depth), while the bucket depth parameter for PCR is CDVT. Note that CDVT is not signalled explicitly, but is determined by the network operator, and can be viewed as a measure of the jitter imposed by the network.

MBS形成漏桶对(速率、深度),而PCR的桶深度参数为CDVT。请注意,CDVT没有明确发出信号,但由网络运营商确定,可以视为网络施加的抖动的度量。

Since CDVT is generally presumed to be small (equivalent to a few cells of token bucket depth), and cannot be set independently for each connection, it cannot be used to account for the burstiness permitted by b of the IP-layer TSpec. Additional buffering may be needed at the IWF to account for the depth of the token bucket.

由于CDVT通常被认为很小(相当于令牌桶深度的几个单元),并且不能为每个连接单独设置,因此不能使用它来说明IP层TSpec的b允许的突发性。在IWF处可能需要额外的缓冲来说明令牌桶的深度。

The ATM Burst Tolerance (BT) is equivalent to MBS (see TM 4.0 [6] for the exact equation). They are both expressions of the bucket depth parameter associated with SCR. The units of BT are time while the units of MBS are cells. Since both SCR and MBS are signalled, they can be computed directly from the IP layer traffic description. The specific manner in which resources are allocated from the traffic description is implementation specific. Note that when translating the traffic parameters, the segmentation overhead and minimum policed unit need to be taken into account (see Section 4.1 below).

ATM突发容忍度(BT)相当于MBS(关于确切的等式,请参见TM 4.0[6])。它们都是与SCR相关的铲斗深度参数的表达式。BT的单位是时间,MBS的单位是小区。由于SCR和MBS都有信号,因此可以直接从IP层流量描述计算它们。从流量描述中分配资源的具体方式是特定于实现的。请注意,在转换流量参数时,需要考虑分段开销和最小策略单元(见下文第4.1节)。

In ATM UNI Signalling 4.0 there are the notions of Alternative Traffic Descriptors and Minimal Traffic Descriptors. Alternative Traffic Descriptors enumerate other acceptable choices for traffic descriptors and are not considered here. Minimal Traffic Descriptors are used in "negotiation," which refers to the specific way in which an ATM connection is set up. To illustrate, roughly, taking PCR as an example: A minimal PCR and a requested PCR are signalled, the requested PCR being the usual item signalled, and the minimal PCR being the absolute minimum that the source edge device will accept. When both minimal and requested parameters are present, the intermediate switches along the path may reduce the requested PCR to a "comfortable" level. This choice is part of admission control, and is therefore implementation specific. If at any point the requested PCR falls below the minimal PCR then the call is cleared. Minimal Traffic Descriptors can be used to present an acceptable range for parameters and ensure a higher likelihood of call admission. In general, our discussion of connection parameters assumes the values resulting from successful connection setup.

在ATM UNI信令4.0中,有备用业务描述符和最小业务描述符的概念。备选流量描述符列举了其他可接受的流量描述符选择,此处不予以考虑。在“协商”中使用最小流量描述符,协商是指建立ATM连接的具体方式。大致以PCR为例进行说明:发出最小PCR和请求PCR的信号,请求PCR是发出信号的通常项目,最小PCR是源边缘设备将接受的绝对最小值。当存在最小参数和请求的参数时,沿路径的中间开关可将请求的PCR降低到“舒适”水平。此选择是准入控制的一部分,因此是特定于实现的。如果在任何时候请求的PCR低于最小PCR,则呼叫被清除。最小流量描述符可用于表示参数的可接受范围,并确保较高的呼叫接纳可能性。通常,我们对连接参数的讨论假设连接设置成功后产生的值。

The Best Effort indicator (used only with UBR) and Tagging indicators (see Section 2.2) are also part of the signalled information element (IE) containing the traffic descriptor. In the UNI 4.0 traffic descriptor IE there is an additional parameter, the Frame Discard indicator, which is discussed below in Section 2.7.

尽力而为指示器(仅与UBR一起使用)和标记指示器(见第2.2节)也是包含交通描述符的信号信息元素(IE)的一部分。在UNI 4.0流量描述符IE中,有一个附加参数,帧丢弃指示器,将在下面的第2.7节中讨论。

2.5.1 Translating Traffic Descriptors for Guaranteed Service
2.5.1 翻译保证服务的流量描述符

For Guaranteed Service the source TSpec contains peak rate, rate and and bucket depth parameters, p_s, r_s, b_s. The receiver TSpec contains corresponding parameters p_r, r_r, b_r. The (receiver) RSpec also has a rate, R. The two different TSpec rates are intended to support receiver heterogeneity, in the sense that receivers can accept different rates representing different subsets of the sender's traffic. Whenever rates from different receivers differ, the values MUST always be merged appropriately before being mapping into ATM parameters.

对于保证服务,源TSpec包含峰值速率、速率和桶深度参数p_s、r_s、b_s。接收机TSpec包含相应的参数p_r、r_r、b_r。(接收器)RSpec还具有速率R。这两个不同的TSpec速率旨在支持接收器异质性,即接收器可以接受代表发送方业务的不同子集的不同速率。当来自不同接收器的速率不同时,在映射到ATM参数之前,必须始终适当地合并这些值。

Note that when the sender and receiver TSpec rates r_s, r_r differ, there is no mechanism specified (in either rsvp or the int-serv specs) for indicating which subset of the traffic is to be transported. Implementation of this feature is therefore completely network specific. The policing and scheduling mechanisms may simply be parameterized with the (lower) receiver rate, resulting in the random loss of traffic sufficient to make up the difference in rates.

注意,当发送方和接收方TSpec速率r_s、r_r不同时,没有指定机制(在rsvp或int-serv规范中)来指示要传输的流量子集。因此,此功能的实现是完全特定于网络的。警务和调度机制可以简单地用(较低的)接收速率参数化,从而导致足以弥补速率差异的随机流量损失。

The receiver TSpec rate describes the traffic for which resources are to be reserved, and may be used for policing, while the RSpec rate (which cannot be smaller) is used (perhaps in an implementation specific way) to modify the allocated service bandwidth in order to reduce the delay.

接收机TSpec速率描述要为其保留资源的业务,并且可以用于监控,而RSpec速率(不能更小)用于(可能以特定于实现的方式)修改分配的服务带宽以减少延迟。

When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic descriptor parameters (PCR, SCR, MBS) can be set cannonically as:

当将保证服务映射到rtVBR VC时,ATM流量描述符参数(PCR、SCR、MBS)可以通过网络设置为:

PCR = p_r SCR = R MBS = b_r.

PCR=p_r SCR=r MBS=b_r。

There are a number of conditions that may lead to different choices. The following discussion is not intended to set hard requirements, but to provide some interpretation and guidance on the bounds of possible parameter mappings. The ingress edge device generally includes a buffer preceding the ATM network interface. This buffer can be used to absorb bursts that fall within the IP-level TSpec, but not within the ATM traffic descriptor. The minimal REQUIREMENT for guaranteed service is that the delay in this buffer MUST NOT exceed b/R, and the delays within the ATM network MUST be accurately accounted for in the values of Adspec parameters C and D advertised by the ingress router (see Section 3.3 below).

有许多条件可能导致不同的选择。以下讨论的目的不是设定严格的要求,而是对可能的参数映射的界限提供一些解释和指导。入口边缘设备通常包括ATM网络接口之前的缓冲器。此缓冲区可用于吸收IP级别TSpec内的突发,但不在ATM流量描述符内。保证服务的最低要求是,该缓冲区中的延迟不得超过b/R,并且ATM网络中的延迟必须在入口路由器公布的Adspec参数C和D值中准确说明(见下文第3.3节)。

If either an edge device buffer of size b_r exists or the ATM maximum burst size (MBS) parameter is at least b_r, then the various rate parameters will generally exhibit the following relationship:

如果存在大小为b_r的边缘设备缓冲区,或者ATM最大突发大小(MBS)参数至少为b_r,则各种速率参数通常将呈现以下关系:

        r_r <= SCR <= R <= PCR <= APB <= line rate
        
        r_r <= SCR <= R <= PCR <= APB <= line rate
        
        r_r <=       p_r       <= APB
        
        r_r <=       p_r       <= APB
        

APB refers to the General Characterization Parameter, AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion of the PATH message. APB reflects the narrowest bottleneck rate along the path, and so is always no larger than the local line rate. The receiver SHOULD choose a peak rate no greater than APB for the reservation to be accepted, although the source peak rate, p_s, could be higher, as the source does not know the value of APB. There is no advantage to allocating any rate above APB of course, so it is an upper bound for all the other parameters.

APB指的是一般特征参数,可用路径带宽,在路径消息的Adspec部分协商。APB反映了路径上最窄的瓶颈速率,因此始终不大于本地线路速率。接收方应选择不大于APB的峰值速率来接受预约,尽管源峰值速率p_s可能更高,因为源不知道APB的值。当然,分配高于APB的任何速率都没有好处,因此它是所有其他参数的上限。

We might normally expect to find R <= p_r, as would be necessary for the simple mapping of PCR = p_r, SCR = R given above. However, a receiver is free to choose R > p_r to lower the GS delay [8]. In this case, PCR cannot be set below R, because a burst of size b arriving into the buffer MUST be cleared at rate R to keep the first component of GS delay down to b/R. So here we will have PCR = R. It may seem that PCR = p_r would be sufficient to avoid buffer overflow, since data is generated at the source at a rate bounded by p_r. However, setting PCR < R, can result in the delay bound advertised by C and D not being met. Also, traffic is always subject to jitter in the network, and the arrival rate at a network element can exceed p_r for short periods of time.

我们通常可能期望找到R<=p\R,这对于上面给出的PCR=p\R,SCR=R的简单映射是必要的。然而,接收机可以自由选择R>p_R以降低GS延迟[8]。在这种情况下,PCR不能设置在R以下,因为到达缓冲区的大小为b的突发必须以R的速率清除,以使GS延迟的第一个分量保持在b/R以下。因此这里我们将使用PCR=R。PCR=p_R似乎足以避免缓冲区溢出,因为数据是以p_R限定的速率在源处生成的。但是,将PCR设置为<R,可能会导致不满足C和D公布的延迟限制。此外,流量在网络中总是受到抖动的影响,并且在一个网元上的到达率可以在短时间内超过p_r。

In the case R <= p_r, we may still choose PCR such that R <= PCR < p_r. The edge device buffer is then necessary (and sufficient) to absorb the bursts (limited to size b_r + C_sum + R D_sum) which arrive faster than they depart. For example, it may be the case that the cost of the ATM VC depends on PCR, while the cost of the Internet service reservation is not strongly dependent on the IP-level peak rate. The user may then have an incentive to set p_r to APB, while the operator of the IP/ATM edge router has an incentive to reduce PCR as much as possible. This may be a realistic concern, since the charging models of IP and ATM are historically different as far as usage sensitivity, and the value of p_r, if set close to APB, could be many times the nominal GS allocated rate of R. Thus, we can set PCR to R, with a buffer of size b_r + C_sum + R D_sum, with no loss of traffic, and no violation of the GS delay bound.

在R<=p\R的情况下,我们仍然可以选择PCR,使得R<=PCR<p\R。然后,边缘设备缓冲区是吸收突发(限于大小b_r+C_sum+r D_sum)所必需的(并且足够),这些突发到达的速度比它们离开的速度快。例如,ATM VC的成本可能取决于PCR,而Internet服务预订的成本并不强烈依赖于IP级峰值速率。然后,用户可能有动机将p_r设置为APB,而IP/ATM边缘路由器的运营商有动机尽可能减少PCR。这可能是一个现实问题,因为IP和ATM的计费模型在使用敏感性方面历史上是不同的,并且如果设置为接近APB,p_r的值可能是标称GS分配率r的许多倍。因此,我们可以将PCR设置为r,缓冲区大小为b_r+C_sum+r D_sum,而不会造成流量损失,并且没有违反GS延迟界限。

   A more subtle, and perhaps controversial case is where we set SCR to
   a value below R.  The major feature of the GS service is to allow a
   receiver to specify the allocated rate R to be larger than the rate
   r_r sufficient to transport the traffic, in order to lower the
   queueing delay (roughly) from b/r + C_TOT/r + D_TOT to b/R + C_TOT/R
   + D_TOT.  To effectively allocate bandwidth R to the flow, we set SCR
        
   A more subtle, and perhaps controversial case is where we set SCR to
   a value below R.  The major feature of the GS service is to allow a
   receiver to specify the allocated rate R to be larger than the rate
   r_r sufficient to transport the traffic, in order to lower the
   queueing delay (roughly) from b/r + C_TOT/r + D_TOT to b/R + C_TOT/R
   + D_TOT.  To effectively allocate bandwidth R to the flow, we set SCR
        

to match R. (Note it is unnecessary in any case to set SCR above R, so the relation, SCR <= R, is still true.) It is possible to set SCR to a value as low as r_r, without violating the delay bounds or overflowing the edge device buffer. With PCR = R, a burst of size b will be buffered and sent into the ATM network at rate R, so the last byte suffers delay only b/R. Any further traffic will be limited to rate r_r, which is SCR, so with the arriving and departing rates matched, its delay will also be no more than b/R.

匹配R。(注意,在任何情况下都没有必要将SCR设置为高于R,因此关系SCR<=R仍然为真。)可以将SCR设置为低至R_R的值,而不会违反延迟界限或溢出边缘设备缓冲区。当PCR=R时,大小为b的突发将被缓冲,并以速率R发送到ATM网络,因此最后一个字节仅受到延迟b/R。任何进一步的流量将被限制在速率R_R,即SCR,因此在到达和离开速率匹配的情况下,其延迟也将不超过b/R。

While this scenario meets the GS service requirements, the penalty for allocating SCR = r_r rather than R is that the delay in the ATM network will have a component of MBS/SCR, which will be b/r rather than b/R, contained in the D term advertised for the ATM sub-network (see further discussion in Section 3.3 below). It is also true that allocating r instead of R in a portion of the path is rather against the spirit of GS. As mentioned above, this mapping may however be useful in practice in the case where pricing in the ATM network leads to different incentives in the tradeoff between delay and bandwidth than those of the user who buys IP integrated services.

虽然该场景满足GS服务要求,但分配SCR=r_r而非r的代价是ATM网络中的延迟将有一个MBS/SCR组件,它将是b/r而不是b/r,包含在ATM子网的D术语中(见下文第3.3节的进一步讨论)。同样正确的是,在路径的一部分中分配r而不是r是与GS的精神背道而驰的。如上所述,在ATM网络中的定价导致延迟和带宽之间的权衡激励不同于购买IP综合服务的用户的情况下,这种映射在实践中可能是有用的。

Another point of view on parameter mapping suggests that SCR may merely reflect the traffic description, hence SCR = r_r, while the service requirement is expressed in the QoS parameter as CDV = b/R. Thus the ATM network may internally allocate bandwidth R, but it is free to use other methods as well to achieve the delay constraint. Mechanisms such as statistical flow/connection aggregation may be implemented in the ATM network and hidden from the user (or parameter mapping module in the edge router) which sees only the interface implemented in the signalled parameters.

关于参数映射的另一种观点认为,SCR可能仅反映流量描述,因此SCR=r_r,而服务需求在QoS参数中表示为CDV=b/r。因此,ATM网络可以在内部分配带宽r,但也可以自由使用其他方法来实现延迟约束。诸如统计流/连接聚合之类的机制可以在ATM网络中实现,并且对用户(或边缘路由器中的参数映射模块)隐藏,用户(或边缘路由器中的参数映射模块)只看到在信号参数中实现的接口。

Note that this discussion considers an edge device buffer size of b_r. In practice, it may be necessary for the AAL/segmentation module to buffer M bytes in converting packets to cells. Also an additional amount of buffer equal to C_sum + R D_sum is generally necessary to absorb jitter imposed by the upstream network [8].

注意,本讨论考虑的边缘设备缓冲区大小为b_r。在实践中,AAL/分段模块在将分组转换为小区时可能需要缓冲M字节。另外,通常需要一个等于C_sum+R D_sum的额外缓冲区来吸收上游网络施加的抖动[8]。

With ATM, it is possible to have little or no buffer in the edge router, because the ATM VC can be set to accept bursts at peak rate. This may be unusual, since the edge router normally has enough buffer to absorb bursts according to the TSpec token bucket parameters. We consider two cases. First, if PCR >= p_r, then MBS can be set to b_r and no buffering is necessary to absorb non-excessive bursts. The extra buffering needed to absorb jitter can also be transferred to MBS. This effectively moves the buffering across the UNI into the ATM network.

使用ATM时,边缘路由器中可能只有很少或没有缓冲区,因为ATM VC可以设置为以峰值速率接受突发。这可能是不寻常的,因为边缘路由器通常有足够的缓冲区来根据TSpec令牌桶参数吸收突发。我们考虑两种情况。首先,如果PCR>=p_r,那么MBS可以设置为b_r,并且不需要缓冲来吸收非过量的突发。吸收抖动所需的额外缓冲也可以传输到MBS。这有效地将缓冲区通过UNI移动到ATM网络中。

For completeness, we consider an edge router with no burst-absorbing buffers and an MBS parameter of approximately zero. In this case it is sufficient to set the rate parameters to PCR = SCR = max (R, p_r). This amounts to peak-rate allocation of bandwidth, which will not usually be very cost effective. This case may be relevant where the IP routers and ATM switches differ substantially in their buffering designs. IP-level users may typically specify much larger burst parameters than can be handled in the ATM subnet. Peak-rate bandwidth allocation provides a means to work around this problem. It is also true that intermediate tradeoffs can be formulated, where the burst-absorbing buffer is less than b bytes, and SCR is set above R and below p_r. Note that jitter-absorbing buffers (C_sum + R D_sum) can not be avoided, generally, by increasing ATM rates, unless SCR is set to exceed the physical line rate(s) into the edge device for the flow.

为了完整性,我们考虑边缘路由器没有突发吸收缓冲器和MBS参数约为零。在这种情况下,将速率参数设置为PCR=SCR=max(R,p_R)就足够了。这相当于带宽的峰值速率分配,这通常不是很划算。这种情况可能与IP路由器和ATM交换机在缓冲设计上有很大不同有关。IP级别的用户通常可以指定比ATM子网中处理的突发参数大得多的突发参数。峰值速率带宽分配提供了一种解决此问题的方法。也可以制定中间折衷方案,其中突发吸收缓冲区小于b字节,并且SCR设置为高于R和低于p_R。请注意,抖动吸收缓冲器(C_sum+R D_sum)通常不能通过增加ATM速率来避免,除非SCR设置为超过流的边缘设备的物理线速率。

For GS over CBR, the value of PCR may be mapped to the RSpec rate R, if the edge device has a buffer of size b_r + C_sum + R D_sum. With little or no burst buffering, the requirements resemble the zero-buffer case above, and we have PCR = max (R, p_r). Additional buffers sufficient to absorb network jitter, given by C_sum, D_sum, MUST always be provided in the edge router, or in the ATM network via MBS.

对于GS over CBR,如果边缘设备具有大小为b_R+C_sum+R D_sum的缓冲区,则PCR的值可映射到RSpec速率R。在很少或没有突发缓冲的情况下,需求类似于上面的零缓冲情况,我们有PCR=max(R,p_R)。边缘路由器或ATM网络中必须始终通过MBS提供足以吸收网络抖动的额外缓冲区(由C_sum、D_sum给出)。

2.5.2 Translating Traffic Descriptors for Controlled Load Service
2.5.2 转换受控负载服务的流量描述符

The Controlled Load service TSpec has a peak rate, p, a "token bucket" rate, r, and a corresponding token bucket depth parameter, b. The receiver TSpec values are used to determine resource allocation, and a simple mapping for the nrtVBR service category is given by,

受控负载服务TSpec具有峰值速率p、“令牌桶”速率r和相应的令牌桶深度参数b。接收器TSpec值用于确定资源分配,nrtVBR服务类别的简单映射如下所示:,

PCR = p_r SCR = r_r MBS = b_r.

PCR=p_r SCR=r_r MBS=b_r。

The discussions in the preceding section on using edge device buffers to reduce PCR and/or MBS apply generally to the CLS over nrtVBR case as well. Extra buffers to accommodate jitter accumulated (beyond the b_r burst size allowed at the source) MUST be provided. For CLS, there are no Adspec parameters C and D, so the dimensioning of such buffers is an implementation design issue.

上一节中关于使用边缘设备缓冲区减少PCR和/或MBS的讨论通常也适用于nrtVBR情况下的CLS。必须提供额外的缓冲区,以适应累积的抖动(超过源允许的b_r突发大小)。对于CLS,没有Adspec参数C和D,因此此类缓冲区的尺寸是一个实现设计问题。

For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate (MCR) parameter. Since there is no corresponding signalled bucket depth parameter, the edge device SHOULD have a buffer of at least b_r bytes, plus additional buffers to absorb jitter. With ABR, the ATM network can quickly throttle the actual transfer rate down to MCR, so a source transmitting above that rate can experience high loss at the

对于ABR VCs,TSpec速率r_r用于设置最小信元速率(MCR)参数。由于没有相应的信号桶深度参数,边缘设备应具有至少b_r字节的缓冲区,加上额外的缓冲区以吸收抖动。有了ABR,ATM网络可以快速地将实际传输速率限制在MCR以下,因此高于该速率传输的信源可能会在同一时间经历高损耗

ingress edge device when the ATM network becomes congested.

当ATM网络变得拥挤时,进入边缘设备。

For CBR, the TSpec rate r_r sets a lower bound on PCR, and again, the available buffering in the edge device SHOULD be adequate to accommodate possible bursts of b_r.

对于CBR,TSpec速率r_r在PCR上设置了一个下限,同样,边缘设备中的可用缓冲应该足以容纳可能的b_r突发。

The REQUIREMENT for CLS that network delays approximate "best-effort service under unloaded conditions", is interpreted here to mean that it would be sufficient to allocate bandwidth resources so that the last byte of a burst of size b_r sees a delay approximately b_r/r_r. For example, a network element with no cross-traffic, a work conserving scheduler and an output link rate of r_L, might provide delays in the range from M/r_L to b_r/r_L, that are much lower than b_r/r_r. While the access to the full link bandwidth (r_L), as reflected in this example, is a more literal interpretation of delay "under unloaded conditions" for a shared link, an ATM VC may only have access to bandwidth equal to its nominal allocation (some implementation specific function of SCR and PCR).

CLS要求网络延迟近似于“空载条件下的尽力而为服务”,这里的解释是,这意味着分配带宽资源足以使大小为b_r的突发的最后一个字节看到近似于b_r/r_r的延迟。例如,没有交叉通信的网元、节省工作的调度器和r_L的输出链路速率可能会提供从M/r_L到b_r/r_L的范围内的延迟,这远远低于b_r/r_L。尽管如本示例所反映的,对全链路带宽(r_L)的访问是对共享链路的“空载条件下”延迟的更字面的解释,但ATM VC可能只能访问等于其标称分配的带宽(SCR和PCR的某些特定实现功能)。

2.5.3 Translating Traffic Descriptors for Best Effort Service
2.5.3 翻译流量描述符以提供尽力而为的服务

For Best Effort service, there is no traffic description. The UBR service category allows negotiation of PCR simply to allow the source to discover the smallest physical bottleneck along the path. The ingress edge router may set PCR to the ATM line rate, and then when the VC setup is complete, the returned value indicates an upper bound on throughput. For UBR service, resources may be allocated for the overall service (i.e., not per-VC) using the (implementation specific) admission control features of the ATM switches.

对于尽力而为的服务,没有流量描述。UBR服务类别允许PCR协商,以允许源发现路径上最小的物理瓶颈。入口边缘路由器可将PCR设置为ATM线路速率,然后当VC设置完成时,返回值指示吞吐量上限。对于UBR服务,可以使用ATM交换机的(特定于实现的)准入控制特性为整个服务(即,不是每个VC)分配资源。

Often a service provider will statically configure large VCs with a certain bandwidth allocation to handle all best effort traffic between two edge routers. ABR, CBR or nrtVBR VCs are appropriate for this design, with traffic parameters set to comfortably accommodate the expected traffic load. See IETF ION specifications for IP over ATM signalling [10, 11].

通常,服务提供商会静态地配置具有特定带宽分配的大型VCs,以处理两个边缘路由器之间的所有尽力而为的流量。ABR、CBR或nrtVBR VCs适用于本设计,交通参数设置为舒适地适应预期交通负荷。参见IETF-ION规范中的IP over ATM信令[10,11]。

2.6 QoS Classes and Parameters
2.6 QoS类和参数

In UNI 3.x the quality of service is indicated by a single parameter called "QoS Class," which is essentially an index to a network specific table of values for the actual QoS parameters. In TM/UNI 4.0 three QoS parameters may be individually signalled, and the signalled values override those implied by the QoS Class, which is still present. These parameters are the Cell Loss Ratio (CLR), Cell Transfer Delay (CTD), and Cell Delay Variation (CDV) [6].

在UNI 3.x中,服务质量由一个称为“QoS等级”的参数表示,该参数本质上是网络特定的实际QoS参数值表的索引。在TM/UNI 4.0中,三个QoS参数可以单独发送信号,并且发送信号的值覆盖QoS类暗示的值,QoS类仍然存在。这些参数是信元丢失率(CLR)、信元传输延迟(CTD)和信元延迟变化(CDV)[6]。

A network provider may choose to associate other parameters, such as Severely Errored Cell Block Ratio, with a QoS Class definition, but these cannot be signalled individually. The ATM Forum UNI 3.0, 3.1 and TM 4.0 specs, following prior ITU specs, give vague qualitative definitions for QoS Classes 1 to 4. (QoS Class 0 is well-defined as "no QoS parameters defined".) Since our mapping is based on these specifications, we generally follow this guidance by setting the QoS Class value to 0 for UBR and ABR (as REQUIRED), 1 for CBR and rtVBR and 3 for nrtVBR. Note that the QoS Class follows the ATM service category, and not the IP service, to avoid combination that are unlikely to be supported. For example, if only nrtVBR is available for GS, then choosing QoS Class = 1 would probably result in connection failure. The QoS Class MUST NOT be interpreted as a way to add real-time behavior to an inherently non-real-time service.

网络提供商可以选择将其他参数(如严重错误的小区块比率)与QoS类定义相关联,但这些参数不能单独发出信号。ATM论坛UNI 3.0、3.1和TM 4.0规范遵循之前的ITU规范,对QoS等级1至4给出了模糊的定性定义。(QoS等级0定义为“未定义QoS参数”。)由于我们的映射基于这些规范,我们通常遵循本指南,将UBR和ABR的QoS等级值设置为0(根据需要),CBR和rtVBR的QoS等级值设置为1,nrtVBR的QoS等级值设置为3。请注意,QoS类遵循ATM服务类别,而不是IP服务,以避免不太可能支持的组合。例如,如果只有nrtVBR可用于GS,那么选择QoS Class=1可能会导致连接失败。QoS类不能被解释为向固有的非实时服务添加实时行为的方法。

The ITU has included a standard set of parameter values for a (small) number of QoS Classes in the latest version of Recommendation I.356 [21]. Network providers may choose to define further network-specific QoS Classes in addition to these. Note that the QoS class definitions in the new I.356 version might not align with the model we follow from the ATM Forum UNI specs. Apart from these definitions, there is no consistent agreement on QoS Class definitions among providers in practice.

ITU在建议I.356[21]的最新版本中包含了(少量)QoS类的标准参数值集。除此之外,网络提供商还可以选择定义更多特定于网络的QoS类。请注意,新I.356版本中的QoS类定义可能与我们在ATM论坛UNI规范中遵循的模型不一致。除了这些定义之外,在实践中,提供商之间对于QoS类定义没有一致的协议。

The ATM QoS parameters have no explicitly signalled IP layer counterparts. The values that are signalled in the ATM network are determined by the IP service definitions and knowledge of the underlying ATM network characteristics, as explained below.

ATM QoS参数没有明确的信号IP层对应物。ATM网络中的信号值由IP服务定义和底层ATM网络特性的知识确定,如下所述。

The ingress edge router SHOULD keep a table of QoS information for the set of egress routers that it may establish VCs with. This table may be simplified by using default values, but it will probably be good practice to maintain a table of current data for the most popular egress points. An edge device that initiates VC setup generally needs to have some way to propose initial value for CDV and CTD, even if they are changed by negotiation; so by positing such a table, we are not creating any new design burden. Cached information can be updated when VCs are successfully established, and to the extent that IP-layer reservations can wait for VCs to complete, the values can be refined through iterated negotiation.

入口边缘路由器应为其可能建立VCs的出口路由器集保留QoS信息表。该表可以通过使用默认值来简化,但最好为最常用的出口点维护一个当前数据表。启动VC设置的边缘设备通常需要有一些方法来提出CDV和CTD的初始值,即使它们通过协商进行了更改;因此,通过设置这样一个表,我们不会产生任何新的设计负担。当成功建立VCs时,可以更新缓存的信息,并且在IP层保留可以等待VCs完成的情况下,可以通过迭代协商来优化值。

Both GS and CLS REQUIRE that losses of packets due to congestion be minimized, so that the loss rate is approximately the same as for an unloaded network. The characteristic loss behavior of the physical medium not due to congestion (e.g., bit errors or fading on wireless channels) determines the order of the permitted packet loss rate. The ingress edge device MUST choose a value of CLR that provides the appropriate IP-level packet loss rate. The CLR value may be uniform

GS和CLS都要求将拥塞引起的数据包丢失降至最低,以便丢失率与未负载网络的丢失率大致相同。非拥塞(例如,无线信道上的误码或衰落)导致的物理介质的特征丢失行为决定了允许的分组丢失率的顺序。入口边缘设备必须选择提供适当IP级数据包丢失率的CLR值。CLR值可能是统一的

over all egress points in the ATM network, or may differ, e.g., when wireless or satellite ATM links are in some paths. The determination of CLR MUST account for the effects of packet size distribution and ATM Frame Discard mode (which can change the effective packet loss rate by orders of magnitude [22]).

在ATM网络中的所有出口点上,或者可能不同,例如,当无线或卫星ATM链路位于某些路径中时。CLR的确定必须考虑数据包大小分布和ATM帧丢弃模式的影响(这可以将有效数据包丢失率改变几个数量级[22])。

The ingress router will also tabulate values for the Minimum Path Latency (MPL) and estimated queueing delays (D_ATM) for each egress point. The latter will be used as part of the Adspec "D" parameter for GS, but its use here applies to CLS as well (when the VC setup includes delay parameters). MPL represents all constant (non-congestion related) delays, including propagation delay. D_ATM accounts for the variable component of delays in the ATM network. (It may depend on non-signalled parameters such as CDVT.) Given these quantities, a new VC can be set up with delay-related QoS parameters given by

入口路由器还将列出每个出口点的最小路径延迟(MPL)和估计排队延迟(D_ATM)值。后者将用作GS的Adspec“D”参数的一部分,但其在此处的使用也适用于CLS(当VC设置包括延迟参数时)。MPL表示所有恒定(非拥塞相关)延迟,包括传播延迟。D_ATM解释了ATM网络中延迟的可变成分。(这可能取决于非信号参数,如CDVT。)给定这些数量,可以使用以下公式给出的延迟相关QoS参数设置新的VC:

CDV = D_ATM CTD = D_ATM + MPL.

CDV=D_ATM CTD=D_ATM+MPL。

(CDV and CTD may be adjusted (increased) by the slack term in GS, see Section 3.3 below.)

(CDV和CTD可通过GS中的松弛项进行调整(增加),见下文第3.3节。)

It is interesting (and perhaps unfortunate) to note that in a typical GS/rtVBR service, the delay bound advertised can contain two components of b/R instead of one. Consider the simple case where SCR = R is the rate allocated to the flow in both IP routers and ATM switches along the path, and the buffer allocation is MBS = b. Parekh's theory [23], which is the basis of the GS delay formula [8] states that the b/R delay term occurs only once, because once a burst of size b has been served by a congested node at rate R, the packets will not arrive at a subsequent node as a single burst. However, we can't tell a priori if this bottleneck will occur in the ATM network or elsewhere in the IP network, so the declaration of CDV SHOULD account for it (i.e., CDV >= b/R). Once CDV is set, the ATM network can impose this delay, whether or not the traffic arrives in a burst. Since the delay b/R can also occur elsewhere, it cannot be removed from the first term of the GS delay formula. The ATM b/R delay component appears in the third term of the GS delay formula, D_tot. See Section 3.3 below for more on GS Adspec parameters. This effect may be mitigated when the ATM network employs more efficient statistical resource allocation schemes.

有趣的是(也许是不幸的)注意到,在典型的GS/rtVBR服务中,公布的延迟边界可以包含b/R的两个组件,而不是一个。考虑SCR=R是两个IP路由器和ATM交换机沿路径分配给流的速率的简单情况,并且缓冲器分配是MBS=B。Parekh的理论[23]是GS延迟公式[8]的基础,该理论指出b/R延迟项仅出现一次,因为一旦拥塞节点以速率R为大小为b的突发服务,数据包将不会作为单个突发到达后续节点。然而,我们无法预先判断这个瓶颈是否会发生在ATM网络或IP网络的其他地方,因此CDV的声明应该考虑到它(即CDV>=b/R)。一旦设置了CDV,ATM网络就可以施加这种延迟,不管流量是否以突发方式到达。由于延迟b/R也可能发生在其他地方,因此不能从GS延迟公式的第一项中删除。ATM b/R延迟分量出现在GS延迟公式的第三项D_tot中。有关GS Adspec参数的更多信息,请参见下文第3.3节。当ATM网络采用更有效的统计资源分配方案时,可以减轻这种影响。

2.7 Additional Parameters -- Frame Discard Mode
2.7 其他参数--帧丢弃模式

TM/UNI 4.0 allows the user to choose a mode where the ATM network is aware, for the purpose of congestion management, of PDUs larger than an ATM cell (i.e., AAL PDUs that correspond in our context to IP packets). This facilitates implementation of algorithms such as partial packet discard, where a dropped cell causes subsequent cells in the same AAL-5 PDU to be dropped as well. Several other applicable buffer management schemes have been proposed [22, 24].

TM/UNI 4.0允许用户选择一种模式,在这种模式下,为了拥塞管理的目的,ATM网络能够识别大于ATM信元的PDU(即,在我们的上下文中与IP数据包相对应的AAL PDU)。这有助于实现诸如部分分组丢弃之类的算法,其中丢弃的小区导致同一AAL-5 PDU中的后续小区也被丢弃。已经提出了几种其他适用的缓冲区管理方案[22,24]。

Frame discard can improve the efficiency and performance of end-to-end protocols such as TCP, since the remaining cells of a damaged PDU are generally useless to the receiver. For IP over ATM, Frame Discard MUST always be indicated, if available.

帧丢弃可以提高端到端协议(如TCP)的效率和性能,因为受损PDU的剩余单元通常对接收器无用。对于ATM上的IP,必须始终指示帧丢弃(如果可用)。

3.0 Additional IP-Integrated Services Protocol Features
3.0 附加的IP集成服务协议功能
3.1 Path Characterization Parameters for IP Integrated Services with ATM
3.1 基于ATM的IP综合业务路径特征参数

This section discusses the setting of General Characterization Parameters (GCPs) at an ATM egress edge router. GCPs are signalled from IP source to IP destination, and modified by intermediate nodes using the Adspec portion of PATH messages in rsvp. The GS-specific Adspec parameters are discussed below in Section 3.3. These parameters are denoted as <x,y> where x is the service and y is the parameter number. Service number 1 indicates default or general parameter values. Please refer to [25] for definitions and details.

本节讨论在ATM出口边缘路由器上设置通用特征参数(GCP)。GCP从IP源发信号到IP目的地,并由中间节点使用rsvp中路径消息的Adspec部分进行修改。下文第3.3节讨论了GS特定Adspec参数。这些参数表示为<x,y>,其中x是服务,y是参数编号。服务编号1表示默认或常规参数值。有关定义和详细信息,请参考[25]。

The IS break bit <1,2> MUST, of course, be left alone by implementations following these guidelines (as they are presumably IS-aware). Similarly, the router MUST always increment IS_HOPS <1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2> respectively, MUST be set if the support of the service is inadequate. In general GS is adequately supported by CBR (BCOB-A) and rtVBR service categories, and not adequately supported by UBR, ABR and nrtVBR because delays are not controlled. CLS may be adequately supported by all service categories except UBR (or Best Effort in UNI 3.x). See Sections 5, 6 for further discussion.

当然,IS中断位<1,2>必须由遵循这些准则的实现来处理(正如他们可能知道的那样)。类似地,路由器必须始终增加跳数<1,4>。如果服务支持不足,则必须分别设置GS和CLS服务特定的中断位<2,2>和<5,2>。一般来说,GS由CBR(BCOB-A)和rtVBR服务类别充分支持,而UBR、ABR和nrtVBR服务类别不充分支持GS,因为延迟不受控制。除UBR(或UNI 3.x中的Best Effort)外,所有服务类别均可充分支持CLS。进一步讨论见第5、6节。

For GS, the ATM network MUST meet the delay performance advertised through the Adspec parameters, MPL, C, and D. If it cannot predictably meet these requirements, the GS break bit MUST be set. Similarly both break bits MUST be set if reservations are honored, but sufficient resources to avoid congestion loss are not allocated in practice. If the service break bits are not set, then the corresponding service hop counters, <2,4>, <5,4>, MUST be incremented.

对于GS,ATM网络必须满足通过Adspec参数MPL、C和D公布的延迟性能。如果无法预期满足这些要求,则必须设置GS中断位。类似地,如果遵守保留,则必须设置两个中断位,但实际上没有分配足够的资源来避免拥塞损失。如果未设置服务中断位,则必须增加相应的服务跃点计数器<2,4>,<5,4>。

The Available Path Bandwidth (APB) parameters <x,6> indicate the minimum physical bottleneck rate along the path. This may be discoverable in an ATM network as the negotiated PCR value for any UBR VC along the same path. This value MUST be corrected for AAL, ATM and physical-layer headers, as necessary, to reflect the effective IP datagram bandwidth. With ATM, it is possible that there is some policy limitation on the value of PCR, below the physical link bottleneck. In this case, the advertised value of APB (in general, and for each service if the values of APB signalled are service specific) MUST reflect this limit, since excess traffic beyond this rate will be dropped. (Note that there is no tagging of traffic in excess of PCR for TM/UNI 4.0.) These values SHOULD generally be cached by the ingress router for the set of egress routers with which it typically needs to establish VCs. The APB parameters are only adjusted down, to reflect the minimum as the composed value.

可用路径带宽(APB)参数<x,6>表示路径上的最小物理瓶颈率。这可以在ATM网络中发现,作为沿同一路径的任何UBR VC的协商PCR值。必要时,必须针对AAL、ATM和物理层报头更正此值,以反映有效的IP数据报带宽。在ATM中,在物理链路瓶颈之下,可能存在对PCR值的一些策略限制。在这种情况下,APB的公布值(一般而言,如果APB的信号值是特定于服务的,则每个服务的APB值)必须反映此限制,因为超过此速率的多余流量将被丢弃。(注意,对于TM/UNI 4.0,没有超过PCR的流量标记。)对于通常需要建立VCs的一组出口路由器,这些值通常应由入口路由器缓存。APB参数仅向下调整,以将最小值反映为合成值。

In the case of a multipoint VC, several parameters can be different for each egress point, e.g., because the characteristics of the physical links of the VC branches differ. When this occurs, the IWF at the egress routers MUST correct these values in PATH messages as they exit the ATM network. (We use the word "correct" because the ingress router SHOULD set the parameters to a value that is appropriate for the largest number of branches, or a value that would do the least harm if the egress routers failed to correct such parameters for each branch.) This is the only case where the egress router needs to operate on rsvp control messages. (A similar correction MUST be implemented for any non-rsvp set-up mechanism). The parameters for which such correction is REQUIRED are the Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the Path MTU (although for ATM/AAL-5 this may typically be constant), and the ATM-specific components of the GS Adspec parameters C_ATM and D_ATM.

在多点VC的情况下,每个出口点的几个参数可能不同,例如,因为VC分支的物理链路的特性不同。发生这种情况时,出口路由器上的IWF必须在路径消息退出ATM网络时更正这些值。(我们使用“正确”一词是因为入口路由器应将参数设置为适用于最大分支数的值,或者如果出口路由器未能为每个分支更正此类参数,则设置为危害最小的值。)这是出口路由器需要对rsvp控制消息进行操作的唯一情况。(必须对任何非rsvp设置机制进行类似的纠正)。需要进行此类校正的参数包括可用路径带宽(APB)、最小路径延迟(MPL)、路径MTU(尽管对于ATM/AAL-5,这通常是恒定的),以及GS Adspec参数C_ATM和D_ATM的ATM特定组件。

The ingress router table SHOULD store values for the ATM-network MPL <x,7> for the various egress points. The composed values <x,8> are formed by addition and forwarded along the path. In the cases where ATM routing chooses different paths, depending on the service category, for VCs to a given egress point, the table will generally reflect different values for each service. If the ATM network is very large and complex, it may become difficult to predict the routes that VCs will take once they are set up. This could be a significant source of misconfiguration, resulting in discrepancies between GS delay advertisements and actual results. The RSpec Slack term may be useful in mitigating this problem.

入口路由器表应存储各种出口点的ATM网络MPL<x,7>的值。合成值<x,8>通过加法形成并沿路径转发。在ATM路由选择不同路径的情况下,根据服务类别,VCs到给定出口点的路径不同,该表通常会反映每个服务的不同值。如果ATM网络非常庞大和复杂,那么一旦建立起来,就很难预测VCs将采取的路线。这可能是错误配置的一个重要来源,导致GS延迟广告与实际结果之间存在差异。RSpec松弛项可能有助于缓解此问题。

AAL-5 will support any message size up to 65,535 bytes, so setting the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for

AAL-5将支持最大为65535字节的任何消息大小,因此将AAL SDU设置为接收器TSpec M参数值(加上8个字节用于

the LLC/SNAP header) will generally not be an issue. In the PATH Adspec, however, the PATH_MTU parameter <x,10> for each service SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19].

LLC/SNAP标题)通常不会成为问题。然而,在PATH Adspec中,每个服务的PATHMTU参数<x,10>应设置为9188字节,这是AAL-5的默认MTU[19]。

3.2 Handling of Excess Traffic
3.2 过剩交通的处理

For IP Integrated Services, network elements will transport traffic in excess of the TSpec parameters whenever physical resources (bandwidth, buffers and processing) are available. (In CLS a "network element MUST attempt to forward the excess traffic on a best-effort basis" under certain conditions; and in GS a traffic policers "SHOULD relegate non-conforming datagrams to best effort".) While excess traffic SHOULD be supported on a best effort basis, it MUST NOT interfere with the QoS (delay and loss) of conforming CLS and GS traffic, nor with normal service of non-reserved best effort traffic.

对于IP综合业务,只要物理资源(带宽、缓冲区和处理)可用,网元将传输超过TSpec参数的流量。(在CLS中,“网元必须在一定条件下尽最大努力转发多余的流量”;在GS a中,流量策略“应将不一致的数据报降级为尽最大努力”。)虽然应尽最大努力支持多余的流量,但不得干扰QoS(延迟和丢失)符合CLS和GS流量,也不符合非保留尽力而为流量的正常服务。

There are several solutions with ATM: the most attractive is to use a VBR service category (with an appropriate conformance definition) and tag excess traffic as low priority using the CLP bit. This avoids reordering of the flow, but necessitates careful design of the egress router scheduler. To avoid reordering, the excess traffic can be queued with conforming traffic. A threshold SHOULD be used to ensure that conforming traffic is not unnecessarily delayed by the excess. Also, for GS, the extra delay that would be incurred due to excess traffic in the queue ahead of conforming packets would have to be accurately reflected in the delay advertisement. Note that the ingress router SHOULD tag all cells of each non-conforming packet, rather than letting the ATM network apply tagging due to ATM-level non-conformance.

ATM有几种解决方案:最有吸引力的是使用VBR服务类别(具有适当的一致性定义),并使用CLP位将多余流量标记为低优先级。这避免了流的重新排序,但需要仔细设计出口路由器调度器。为了避免重新排序,多余的流量可以与一致的流量一起排队。应使用一个阈值,以确保符合要求的流量不会因过量而不必要地延迟。此外,对于GS,由于一致性分组之前的队列中的过多通信量而产生的额外延迟必须准确地反映在延迟广告中。请注意,入口路由器应标记每个不一致数据包的所有信元,而不是由于ATM级别不一致而让ATM网络应用标记。

There is no requirement in ATM standards that tagged cells, marked either by the user or by policing, be transported if possible. Therefore, the operator of an edge router supporting IP-IS SHOULD ascertain the actual behavior of the ATM equipment in the path, which may span multiple administrative domains in the ATM network. If tagged cells are simply dropped at some point, regardless of load, then the operator may consider setting the break bit, at least for CLS service.

ATM标准中没有要求在可能的情况下运输由用户或警察标记的标记信元。因此,支持IP-IS的边缘路由器的运营商应确定路径中ATM设备的实际行为,该路径可能跨越ATM网络中的多个管理域。如果标记的单元在某个点被简单地丢弃,不管负载如何,那么操作员可以考虑设置中断位,至少对于CLS服务而言。

The other solutions generally involve a separate VC to carry the excess. A distinct VC can be set up for each VC supporting a GS or CLS flow, or, if many flows are aggregated into a single QoS VC, then another VC can handle the excess traffic for that set of flows. A VC can be set up to handle all excess traffic from the ingress router to the egress point. Since the QoS of the excess traffic is not particularly constrained, the design is quite flexible. However, using a separate VC may cause misordering of packets within a flow.

其他解决方案通常涉及一个单独的VC来承担多余部分。可以为支持GS或CLS流的每个VC设置不同的VC,或者,如果许多流聚合为单个QoS VC,则另一个VC可以处理该流集的多余流量。可以设置VC来处理从入口路由器到出口点的所有多余流量。由于多余流量的QoS没有受到特别的限制,因此设计非常灵活。但是,使用单独的VC可能会导致流中的数据包顺序错误。

The service category for the excess-traffic VC may typically be UBR or ABR, although one could use CBR or nrtVBR if the excess traffic were predictable enough to know what rate to allocate. (This wouldn't normally be expected for excess traffic, though.)

过量流量VC的服务类别通常可以是UBR或ABR,但是如果过量流量足够可预测,可以使用CBR或nrtVBR来知道分配的速率。(不过,这通常不会出现在流量过剩的情况下。)

Whether a separate VC is used may be influenced by the design of the router scheduler. The CLS spec suggests two possible implementations: one where excess traffic shares the Best Effort class scheduler allocation, but at lower priority than other best effort traffic. The other, where a separate allocation is made. The first would allow excess traffic to use the same VC as normal best effort traffic, and the second would suggest a separate VC.

路由器调度器的设计可能会影响是否使用单独的VC。CLS规范建议了两种可能的实现:一种是多余的流量共享尽力而为类调度器分配,但优先级低于其他尽力而为流量。另一种是单独分配。第一种方法允许多余的流量使用与正常尽力而为流量相同的VC,第二种方法建议使用单独的VC。

TM/UNI 4.0. does not support tagging of traffic in excess of PCR. Although UNI 3.x does have a separate PCR parameter for CLP=0 cells only, we do not recommend using this feature for reasons of interoperability with TM/UNI 4.0 equipment. This restricts CBR VCs to use solutions other than tagging. The value of PCR can be set higher than necessary for conformant traffic, in an effort to support excess traffic on the same VC. In some cases this may be a viable solution, such as when there is little additional cost imposed for a high PCR. If PCR can be set as high as APB, then the excess traffic is fully accommodated.

TM/uni4.0。不支持标记超过PCR的流量。尽管UNI 3.x仅对CLP=0细胞有单独的PCR参数,但出于与TM/UNI 4.0设备互操作性的原因,我们不建议使用此功能。这限制了CBR VCs使用除标记以外的解决方案。PCR的值可以设置为高于一致流量所需的值,以支持同一VC上的过量流量。在某些情况下,这可能是一个可行的解决方案,例如当高PCR几乎没有额外成本时。如果PCR可以设置为APB的高,则可以完全容纳多余的流量。

3.3 Use of Guaranteed Service Adspec Parameters and Slack Term
3.3 保证服务Adspec参数和松弛项的使用

The Adspec is used by the Guaranteed Service to allow a receiver to calculate the worst-case delay associated with a GS flow. Three quantities, C, D, and MPL, are accumulated (by simple addition of components corresponding to each network element) in the PATH message from source to receiver. The resulting delay values can be different for each unique receiver. The maximum delay is computed as

保证服务使用Adspec来允许接收器计算与GS流相关联的最坏情况延迟。三个量C、D和MPL(通过简单地添加对应于每个网元的组件)在从源到接收器的路径消息中累积。对于每个唯一的接收器,产生的延迟值可能不同。最大延迟计算为:

        delay <=  b_r/R + C_TOT/R + D_TOT + MPL
        
        delay <=  b_r/R + C_TOT/R + D_TOT + MPL
        

The Minimum Path Latency (MPL) includes propagation delay, while b_r/R accounts for bursts due to the source and C and D include other queueing, scheduling and serialization delays. (We neglect the effect of maximum packet size and peak rate here; see the GS specification [8] for a more detailed equation.) The service rate requested by the receiver, R, can be greater than the TSpec rate, r_r, resulting in lower delay. The burst size, b_r, is the leaky bucket parameter from the receiver TSpec.

最小路径延迟(MPL)包括传播延迟,而b_r/r考虑源引起的突发,C和D包括其他排队、调度和序列化延迟。(此处我们忽略了最大数据包大小和峰值速率的影响;有关更详细的等式,请参见GS规范[8])接收器请求的服务速率R可以大于TSpec速率R,从而降低延迟。突发大小b_r是来自接收器TSpec的泄漏桶参数。

The values of C and D that a router advertises depend on both the router packet scheduler and the characteristics of the subnet attached to the router. Each router (or the source host) takes responsibility for its downstream subnet in its advertisement. For

路由器播发的C和D值取决于路由器数据包调度程序和连接到路由器的子网的特性。每个路由器(或源主机)负责其播发中的下游子网。对于

example, if the subnet is a simple point-to-point link, the subnet-specific parts of C and D need to account for the link transmission rate and MTU. An ATM subnet is generally more complex.

例如,如果子网是简单的点到点链路,则子网特定的C和D部分需要考虑链路传输速率和MTU。ATM子网通常更复杂。

For this discussion, we consider only the ATM subnet-specific components, denoted C_ATM and D_ATM. The ATM network can be represented as a "pure delay" element, where the variable queueing delay, given by CVD is captured in D_ATM, and C_ATM is set to zero. It is possible to use C_ATM only when the ATM service rate equals R. This may be the case, for example with a CBR VC with PCR = R.

对于这个讨论,我们只考虑ATM子网特定组件,表示CY-ATM和DY-ATM。ATM网络可以表示为“纯延迟”元素,其中CVD给出的可变排队延迟在D_ATM中捕获,C_ATM设置为零。只有当ATM服务速率等于R时,才有可能使用C_ATM。这可能是一种情况,例如,对于PCR=R的CBR VC。

Usually it will be simpler to just advertise the total delay variation (CDV) in D_ATM.

通常,在D_ATM中只公布总延迟变化(CDV)会更简单。

As discussed in Section 2.6, the edge router keeps a table with values of MPL and D_ATM for each egress router it needs to share VCs with. The value of D_ATM contributes to the D parameter advertised by the edge router, and SHOULD accurately reflect the CDV that the router will get in a VC when it is set up. Factors that affect CDV, such as statistical multiplexing in the ATM network, SHOULD be taken into account when compiling data for the router's table. In case of uncertainty, D_ATM can be set to an upper bound. When an RESV message arrives, causing a VC to be set up, the requested values for CTD and CDV can be relaxed using the slack term in the receiver RSpec:

如第2.6节所述,边缘路由器为其需要与之共享VCs的每个出口路由器保留一个包含MPL和D_ATM值的表。D_ATM的值有助于边缘路由器公布的D参数,并应准确反映路由器在设置时将在VC中获得的CDV。在为路由器表编译数据时,应考虑影响CDV的因素,例如ATM网络中的统计多路复用。在不确定的情况下,D_ATM可以设置为上限。当RESV消息到达,导致设置VC时,可以使用接收器RSpec中的松弛项放松CTD和CDV的请求值:

CTD = D_ATM + MPL + S_ATM CDV = D_ATM + S_ATM.

CTD=D_ATM+MPL+S_ATM CDV=D_ATM+S_ATM。

The term S_ATM is the portion of the slack term applied to the ATM portion of the path. Recall that the slack term [8] is positive when the receiver can afford more delay than that computed from the Adspec. The ATM edge device may take part (or all) of the slack term, S. The distribution of delay slack among the nodes and subnets is network specific.

术语S_ATM是应用于路径的ATM部分的松弛术语的一部分。回想一下,当接收器能够承受比从Adspec计算出的延迟更多的延迟时,松弛项[8]为正。ATM边缘设备可以参与部分(或全部)松弛项S。节点和子网之间的延迟松弛分布是特定于网络的。

Note that with multipoint VCs the egress edge router may need to correct advertised values of C and D. See discussion in Section 3.1.

请注意,对于多点VCs,出口边缘路由器可能需要更正公布的C和D值。请参阅第3.1节中的讨论。

4.0 Miscellaneous Items
4.0 杂项资料
4.1 Units Conversion
4.1 单位换算

All rates and token bucket depth parameters that are mapped from IP-level parameters to ATM parameters MUST be corrected for the effects of added headers and the segmentation of packets into cells. At the IP layer, token bucket depths and rates are measured in bytes and bytes/sec, respectively, whereas for ATM, they are measured in cells

所有从IP级别参数映射到ATM参数的速率和令牌桶深度参数必须针对添加的报头和分组到信元的分段的影响进行校正。在IP层,令牌桶深度和速率分别以字节和字节/秒为单位测量,而对于ATM,它们以信元为单位测量

and cells/sec.

和细胞/秒。

Each IP Packet is wrapped into an AAL-5 PDU, having a number of additional header bytes (8 for LLC/SNAP and perhaps others, e.g. 12 for MPOA, etc.), and an 8-byte AAL-5 trailer. The AAL-5 PDU is then segmented into multiple ATM cells, each having a 5-byte cell header followed by a 48-byte cell payload. The number of cells used to carry an IP packet with

每个IP数据包被包装到一个AAL-5 PDU中,该PDU具有多个额外的报头字节(对于LLC/SNAP为8个,可能还有其他字节,例如对于MPOA为12个,等等),以及一个8字节的AAL-5尾部。AAL-5 PDU然后被分割成多个ATM信元,每个信元都有一个5字节的信元头,后跟一个48字节的信元有效负载。用于承载IP数据包的单元数

B = number of IP-packet Bytes, H = number of AAL-5 header bytes (LLC/SNAP etc.) C = number of cells,

B=IP数据包字节数,H=AAL-5报头字节数(LLC/SNAP等)C=单元数,

is roughly

大致上

C = B/48,

C=B/48,

and more precisely

更准确地说

        C = floor[(H + B + 8 + 47)/48]
        
        C = floor[(H + B + 8 + 47)/48]
        

where floor[] is rounds down to the nearest integer. The '8' accounts for the AAL-5 trailer and the '47' accounts for the last cell which may be only partially filled.

其中floor[]向下舍入为最接近的整数。“8”表示AAL-5拖车,而“47”表示最后一个单元格,该单元格只能部分填充。

5.0 Summary of ATM VC Setup Parameters for Guaranteed Service
5.0 保证服务的ATM VC设置参数摘要

This section describes how to create ATM VCs appropriately matched for Guaranteed Service. The key points are that real-time timing is REQUIRED, that the data flow may have a variable rate, and that demotion of non-conforming traffic to best effort is REQUIRED to be in agreement with the definition of GS. For this reason, we prefer an rtVBR service in which tagging is supported. Another good match is to use CBR with special handling of any non-conforming traffic, e.g., through another VC, since a CBR VC will not accommodate traffic in excess of PCR.

本节介绍如何创建与保证服务相匹配的ATM VCs。关键点是需要实时定时,数据流可能具有可变速率,并且需要将不符合要求的流量降级为尽力而为,以符合GS的定义。因此,我们更喜欢支持标记的rtVBR服务。另一个很好的匹配是使用CBR对任何不合格流量进行特殊处理,例如通过另一个VC,因为CBR VC不会容纳超过PCR的流量。

Note, these encodings assume point to multipoint connections, where the backward channel is not used. If the IP session is unicast only, then a point-to-point VC may be used and the IWF may make use of the backward channel, with QoS parameters set appropriately for the service provided.

注意,这些编码假定点对多点连接,其中不使用反向通道。如果IP会话仅是单播的,则可以使用点对点VC,并且IWF可以利用反向信道,并且针对所提供的服务适当地设置QoS参数。

We provide a mapping for all combinations of IP service and ATM service category, and comments indicating whether or not each combination meets the requirements of the IP-IS service.

我们为IP服务和ATM服务类别的所有组合提供映射,并提供说明每个组合是否满足IP-IS服务要求的注释。

5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
5.1 使用实时VBR编码GS(ATM论坛TM/UNI 4.0)

RtVBR with conformance definition VBR.3 [6] MEETS the requirements of GS.

符合性定义VBR.3[6]的RtVBR符合GS的要求。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes SSCS Type 0 (Null SSCS)

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 1 Backward PCR CLP=0+1 0 Forward SCR CLP=0 Note 1 Backward SCR CLP=0 0 Forward MBS (CLP=0) Note 1 Backward MBS (CLP=0) 0 BE indicator NOT included Forward Frame Discard bit 1 Backward Frame Discard bit 1 Tagging Forward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)

流量描述符前向PCR CLP=0+1注1后向PCR CLP=0+1 0前向SCR CLP=0注1后向SCR CLP=0前向MBS(CLP=0)注1后向MBS(CLP=0)0 BE指示器不包括前向帧丢弃位1后向帧丢弃位1标记前向位1(请求标记)标记后向位1(请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 2 ATM Transfer Capability 9 (Real time VBR) Note 3 Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注2 ATM传输能力9(实时VBR)注3易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 4 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注4 ISO/IEC TR 9577 IPI 204

QoS Class QoS Class Forward 1 Note 5 QoS Class Backward 1 Note 5

QoS等级QoS等级前向1注5 QoS等级后向1注5

Extended QoS Parameters Note 6 Acceptable Forward CDV Acceptable Forward CLR Forward Max CTD

扩展QoS参数注6可接受的前向CDV可接受的前向CLR前向最大CTD

Note 1: See discussion in Section 2.5.1.

注1:见第2.5.1节中的讨论。

Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is chosen the ATC field MUST be absent. Note 3: The ATC value 19 is not used. The value 19 implies that the CLR objective applies to the aggregate CLP=0+1 stream and that does not give desirable treatment of excess traffic. Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 6: See discussion in Section 2.6.

注2:也可以使用值3(BCOB-C)。如果选择承载类别C,则ATC字段必须不存在。注3:不使用ATC值19。值19意味着CLR目标适用于聚合CLP=0+1流,并且不会对过剩流量进行理想的处理。注4:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注5:参考ITU Rec.I.356[21]了解新的QoS等级定义。注6:见第2.6节中的讨论。

5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0)
5.2 使用CBR编码GS(ATM论坛TM/UNI 4.0)

A CBR VC MEETS the requirements of GS. The main advantage of this is that CBR is widely supported; the disadvantage is that data flows might not fill the pipe (utilization loss) and there is no tagging option available. Excess traffic MUST be handled using a separate VC.

CBR VC符合GS的要求。其主要优点是CBR得到广泛支持;缺点是数据流可能无法填充管道(利用率损失),并且没有可用的标记选项。必须使用单独的VC处理多余的流量。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes SSCS Type 0 (Null SSCS)

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 1 Backward PCR CLP=0+1 0 BE indicator NOT included Forward Frame Discard bit 1 Backward Frame Discard bit 1 Tagging Forward bit 0 (Tagging not requested) Tagging Backward bit 0 (Tagging not requested)

流量描述符前向PCR CLP=0+1注1后向PCR CLP=0+1 0 BE指示器不包括前向帧丢弃位1后向帧丢弃位1标记前向位0(未请求标记)标记后向位0(未请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 2 ATM Transfer Capability 5 (CBR) Note 3 Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注2 ATM传输能力5(CBR)注3易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 4 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注4 ISO/IEC TR 9577 IPI 204

QoS Class QoS Class Forward 1 Note 5 QoS Class Backward 1 Note 5

QoS等级QoS等级前向1注5 QoS等级后向1注5

Extended QoS Parameters Note 6 Acceptable Forward CDV Acceptable Forward CLR Forward Max CTD

扩展QoS参数注6可接受的前向CDV可接受的前向CLR前向最大CTD

Note 1: See discussion in Section 2.5.1. Note 2: Value 1 (BCOB-A) can also be used. If Bearer Class A is chosen the ATC field MUST be absent. Note 3: The ATC value 7 is not used. The value 7 implies CLR objective applies to the aggregate CLP=0+1 stream and that does not give desirable treatment of excess traffic. Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 6: See discussion in Section 2.6.

注1:见第2.5.1节中的讨论。注2:也可以使用值1(BCOB-A)。如果选择承载类别A,则ATC字段必须不存在。注3:不使用ATC值7。值7意味着CLR目标适用于聚合CLP=0+1流,并且不会对过剩流量进行理想的处理。注4:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注5:参考ITU Rec.I.356[21]了解新的QoS等级定义。注6:见第2.6节中的讨论。

5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
5.3 使用非实时VBR编码GS(ATM论坛TM/UNI 4.0)

NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for GS. If GS/nrtVBR is used and network utilization is low, the delay may be `reasonable', but will not be controlled. The encoding of GS with nrtVBR is the same as that for CLS using nrtVBR. See Section 6.1 below.

NrtVBR不提供延迟保证,不建议用于GS。如果使用GS/nrtVBR且网络利用率较低,则延迟可能“合理”,但不会受到控制。使用nrtVBR的GS编码与使用nrtVBR的CLS编码相同。见下文第6.1节。

5.4 Encoding GS Using ABR (ATM Forum TM/UNI 4.0)
5.4 使用ABR编码GS(ATM论坛TM/UNI 4.0)

GS using ABR is a very unlikely combination, and DOES NOT meet the service requirements of GS. The objective of the ABR service is to provide "low" loss rates. The delay objectives for ABR SHOULD be expected to be very loose. If ABR were used for GS, the VC parameters would follow as for CLS over ABR. See Section 6.2.

GS使用ABR是一种极不可能的组合,不符合GS的服务要求。ABR服务的目标是提供“低”损失率。ABR的延迟目标应该非常宽松。如果将ABR用于GS,则VC参数将与ABR上的CLS相同。见第6.2节。

5.5 Encoding GS Using UBR (ATM Forum TM/UNI 4.0)
5.5 使用UBR编码GS(ATM论坛TM/UNI 4.0)

The UBR service is the lowest common denominator of the services. It cannot provide delay or loss guarantees, and therefore DOES NOT meet the requirements of GS. However if it is used for GS, it will be encoded in the same way as Best Effort over UBR, with the exception that the Forward PCR would be determined from the peak rate of the receiver TSpec. See Section 7.1.

UBR服务是服务的最低公分母。它不能提供延迟或损失担保,因此不符合GS的要求。然而,如果它用于GS,它将以与UBR上的最大努力相同的方式进行编码,但前向PCR将根据接收器TSpec的峰值速率确定。见第7.1节。

5.6 Encoding GS Using ATM Forum UNI 3.0/3.1 Specifications
5.6 使用ATM论坛UNI 3.0/3.1规范编码GS

It is not recommended to support GS using UNI 3.x VBR mode because the BCOB-C Bearer Class does not represent real-time behavior. Also, Appendix F of the UNI 3.1 specification precludes the specification of traffic type "VBR" with the timing requirement "End to End timing Required" in conjunction with Bearer Class X.

不建议使用UNI 3.x VBR模式支持GS,因为BCOB-C承载类不代表实时行为。此外,UNI 3.1规范的附录F排除了带有“需要端到端定时”定时要求以及承载等级X的“VBR”交通类型规范。

A CBR VC MEETS the requirements of GS. The following table specifies the support of GS using CBR.

CBR VC符合GS的要求。下表规定了使用CBR对GS的支持。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Mode 1 (Message mode) Note 1 SSCS Type 0 (Null SSCS)

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节模式1(消息模式)注1 SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0 Note 2 Backward PCR CLP=0 0 Forward PCR CLP=0+1 Note 2 Backward PCR CLP=0+1 0 BE indicator NOT included Tagging Forward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)

流量描述符前向PCR CLP=0注2后向PCR CLP=0前向PCR CLP=0+1注2后向PCR CLP=0+1 BE指示器不包括标记前向位1(请求标记)标记后向位1(请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 3 Traffic Type 001 (Constant Bit Rate) Timing Requirements 01 (Timing Required) Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注3业务类型001(恒定比特率)定时要求01(需要定时)易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 4 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注4 ISO/IEC TR 9577 IPI 204

QoS Class Note 5 QoS Class Forward 1 QoS Class Backward 1

QoS等级注5 QoS等级前向1 QoS等级后向1

Note 1: Only included for UNI 3.0. Note 2: See discussion in Section 2.5.1. PCR CLP=0 SHOULD be set

注1:仅包括UNI 3.0。注2:见第2.5.1节中的讨论。应设置PCR CLP=0

identical to PCR CLP=0+1. Although this could potentially allow a CBR VC to carry excess traffic as tagged cells, it is not recommended since it is not supported in UNI 4.0 Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic Type and Timing Requirements fields are not included. Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 5: QoS Parameters are implied by the QoS Class.

与PCR CLP=0+1相同。尽管这可能会允许CBR VC作为标记单元承载过多的流量,但不建议这样做,因为UNI 4.0不支持它。注3:也可以使用值1(BCOB-a)。如果使用BCOB-A,则不包括交通类型和时间要求字段。注4:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注5:QoS参数由QoS类暗示。

6.0 Summary of ATM VC Setup Parameters for Controlled Load Service
6.0 受控负载服务的ATM VC设置参数摘要

This section describes how to create ATM VCs appropriately matched for Controlled Load Service. CLS traffic is partly delay tolerant and has variable rate. NrtVBR and ABR (TM/UNI 4.0 only) are the best choices for supporting CLS.

本节介绍如何创建与受控负载服务相匹配的ATM VCs。CLS流量具有部分延迟容忍能力,并且具有可变速率。NrtVBR和ABR(仅限TM/UNI 4.0)是支持CLS的最佳选择。

Note, these encodings assume point to multipoint connections where the backward channel is not used. If the IP session is unicast only, then a point-to-point VC may be used and the IWF may make use of the backward channel, with QoS parameters set appropriately for the service provided.

注意,这些编码假定不使用反向通道的点对多点连接。如果IP会话仅是单播的,则可以使用点对点VC,并且IWF可以利用反向信道,并且针对所提供的服务适当地设置QoS参数。

We provide a mapping for all combinations of IP service and ATM service category, and comments indicating whether or not each combination meets the requirements of the IP-IS service.

我们为IP服务和ATM服务类别的所有组合提供映射,并提供说明每个组合是否满足IP-IS服务要求的注释。

6.1 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
6.1 使用非实时VBR编码CLS(ATM论坛TM/UNI 4.0)

NrtVBR MEETS the requirements for CLS.

NrtVBR符合CLS的要求。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes SSCS Type 0 (Null SSCS)

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 1 Backward PCR CLP=0+1 0 Forward SCR CLP=0 Note 1 Backward SCR CLP=0 0 Forward MBS (CLP=0) Note 1 Backward MBS (CLP=0) 0 BE indicator NOT included Forward Frame Discard bit 1 Backward Frame Discard bit 1

流量描述符前向PCR CLP=0+1注1后向PCR CLP=0+1 0前向SCR CLP=0注1后向SCR CLP=0 0前向MBS(CLP=0)注1后向MBS(CLP=0)0 BE指示器不包括前向帧丢弃位1后向帧丢弃位1

Tagging Forward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)

标记前向位1(请求标记)标记后向位1(请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 2 ATM Transfer Capability 10 (Non-real time VBR) Note 3 Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注2 ATM传输能力10(非实时VBR)注3易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 4 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注4 ISO/IEC TR 9577 IPI 204

QoS Class QoS Class Forward 3 Note 5 QoS Class Backward 3 Note 5

QoS等级QoS等级前向3注5 QoS等级后向3注5

Extended QoS Parameters Note 6 Acceptable Forward CDV Acceptable Forward CLR Forward Max CTD

扩展QoS参数注6可接受的前向CDV可接受的前向CLR前向最大CTD

Note 1: See discussion in Section 2.5.2. Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is used, the ATC field MUST be absent. Note 3: The ATC value 11 is not used. The value 11 implies CLR objective applies to the aggregate CLP=0+1 stream and that does not give desirable treatment of excess traffic. Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 6: See discussion in Section 2.6.

注1:见第2.5.2节中的讨论。注2:也可以使用值3(BCOB-C)。如果使用承载类别C,则ATC字段必须不存在。注3:不使用ATC值11。值11意味着CLR目标适用于聚合CLP=0+1流,并且不会对过剩流量进行理想的处理。注4:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注5:参考ITU Rec.I.356[21]了解新的QoS等级定义。注6:见第2.6节中的讨论。

6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0)
6.2 使用ABR编码CLS(ATM论坛TM/UNI 4.0)

ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec rate.

当MCR设置为CLS TSpec速率时,ABR满足CLS的要求。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节

SSCS Type 0 (Null SSCS)

SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 1 Backward PCR CLP=0+1 0 Forward MCR CLP=0+1 Note 1 Backward MCR CLP=0+1 0 BE indicator NOT included Forward Frame Discard bit 1 Backward Frame Discard bit 1 Tagging Forward bit 0 (Tagging not requested) Tagging Backward bit 0 (Tagging not requested)

流量描述符前向PCR CLP=0+1注1后向PCR CLP=0+1 0前向MCR CLP=0+1注1后向MCR CLP=0+1 0 BE指示器不包括前向帧丢弃位1后向帧丢弃位1标记前向位0(未请求标记)标记后向位0(未请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 2 ATM Transfer Capability 12 (ABR) Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 00 (Point-to-Point)

宽带承载能力承载等级16(BCOB-X)注2 ATM传输能力12(ABR)易受限幅00(不易受限)用户平面配置00(点对点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 3 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注3 ISO/IEC TR 9577 IPI 204

QoS Class QoS Class Forward 0 Note 4 QoS Class Backward 0 Note 4

QoS类QoS类前向0注4 QoS类后向0注4

Extended QoS Parameters Note 5 Acceptable Forward CDV Acceptable Forward CLR Forward Max CTD

扩展QoS参数注5可接受的前向CDV可接受的前向CLR前向最大CTD

ABR Setup Parameters Note 6 ABR Additional Parameters Note 6

ABR设置参数注6 ABR附加参数注6

Note 1: See discussion in Section 2.5.2. Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is chosen the ATC field MUST be absent. Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 5: See discussion in Section 2.6.

注1:见第2.5.2节中的讨论。注2:也可以使用值3(BCOB-C)。如果选择承载类别C,则ATC字段必须不存在。注3:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注4:参考ITU Rec.I.356[21]了解新的QoS等级定义。注5:见第2.6节中的讨论。

Note 6: The ABR-specific parameters are beyond the scope of this document. These generally depend on local implementation and not on values mapped from IP level service parameters (except for MCR). See [6, 11] for further information.

注6:ABR特定参数超出本文件范围。这些通常取决于本地实现,而不取决于从IP级别服务参数映射的值(MCR除外)。有关更多信息,请参见[6,11]。

6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0)
6.3 使用CBR编码CLS(ATM论坛TM/UNI 4.0)

Although CBR does not explicitly take into account the variable rate of source data, it may be convenient to use ATM connectivity between edge routers to provide a simple "pipe" service, as a leased line replacement. Since no tagging option is available with CBR, excess traffic MUST be handled using a separate VC. Under this condition, CBR MEETS the requirements of CLS.

虽然CBR没有明确考虑源数据的可变速率,但使用边缘路由器之间的ATM连接提供简单的“管道”服务,作为租用线路的替代,可能会很方便。由于CBR没有可用的标记选项,因此必须使用单独的VC处理多余的流量。在此条件下,CBR满足CLS的要求。

To use CBR for CLS, the same encoding for GS over CBR (Section 5.2) would be used. See discussion in Section 2.5.2.

为将CBR用于CLS,将使用与GS over CBR相同的编码(第5.2节)。见第2.5.2节中的讨论。

6.4 Encoding CLS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
6.4 使用实时VBR编码CLS(ATM论坛TM/UNI 4.0)

The encoding of CLS using rtVBR implies a hard limit on the end-to-end delay in the ATM network. This creates more complexity in the VC setup than the CLS service requires, and is therefore not a preferred combination, although it DOES MEET the requirements of CLS.

使用rtVBR对CLS进行编码意味着对ATM网络中的端到端延迟进行硬限制。这在VC设置中比CLS服务要求的复杂度更高,因此不是首选组合,尽管它确实满足CLS的要求。

If rtVBR is used to encode CLS, then the encoding is essentially the same as that for GS. See discussions in Section 5.1 and Section 2.5.2.

如果使用rtVBR对CLS进行编码,则编码基本上与GS相同。见第5.1节和第2.5.2节中的讨论。

6.5 Encoding CLS Using UBR (ATM Forum TM/UNI 4.0)
6.5 使用UBR编码CLS(ATM论坛TM/UNI 4.0)

This encoding gives no QoS guarantees and DOES NOT MEET the requirements of CLS. If used, it is coded in the same way as for BE over UBR (Section 7.1), except that the PCR would be determined from the peak rate of the receiver TSpec.

这种编码不提供QoS保证,也不符合CLS的要求。如果使用,其编码方式与BE over UBR相同(第7.1节),但PCR将根据接收器TSpec的峰值速率确定。

6.6 Encoding CLS Using ATM Forum UNI 3.0/3.1 Specifications
6.6 使用ATM论坛UNI 3.0/3.1规范编码CLS

This encoding is equivalent to the nrtVBR service category. It MEETS the requirements of CLS.

此编码相当于nrtVBR服务类别。它符合CLS的要求。

AAL Type 5 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Mode 1 (Message mode) Note 1 SSCS Type 0 (Null SSCS)

AAL类型5 rcvr TSpec的正向CPCS-SDU大小参数M+8字节rcvr TSpec的反向CPCS-SDU大小参数M+8字节模式1(消息模式)注1 SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 2 Backward PCR CLP=0+1 0 Forward SCR CLP=0 Note 2 Backward SCR CLP=0 0 Forward MBS (CLP=0) Note 2 Backward MBS (CLP=0) 0 BE indicator NOT included Tagging Forward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)

流量描述符前向PCR CLP=0+1注2后向PCR CLP=0+1 0前向SCR CLP=0注2后向SCR CLP=0前向MBS(CLP=0)注2后向MBS(CLP=0)0 BE指示器不包括标记前向位1(请求标记)标记后向位1(请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 3 Traffic Type 010 (Variable Bit Rate) Timing Requirements 00 (No Indication) Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注3业务类型010(可变比特率)定时要求00(无指示)易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) User Information Layer 3 Protocol 11 (ISO/IEC TR 9577) Note 4 ISO/IEC TR 9577 IPI 204

宽带低层信息用户信息第2层协议12(ISO 8802/2)用户信息第3层协议11(ISO/IEC TR 9577)注4 ISO/IEC TR 9577 IPI 204

QoS Class QoS Class Forward 3 Note 5 QoS Class Backward 3 Note 5

QoS等级QoS等级前向3注5 QoS等级后向3注5

Note 1: Only included for UNI 3.0. Note 2: See discussion in Section 2.5.2. Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic Type and Timing Requirements fields are not included. Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. QoS Parameters are implied by the QoS Class.

注1:仅包括UNI 3.0。注2:见第2.5.2节中的讨论。注3:也可以使用值3(BCOB-C)。如果使用BCOB-C,则不包括交通类型和时间要求字段。注4:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。注5:参考ITU Rec.I.356[21]了解新的QoS等级定义。QoS参数由QoS类暗示。

7.0 Summary of ATM VC Setup Parameters for Best Effort Service
7.0 尽最大努力服务的ATM VC设置参数摘要

This section is provided for completeness only. The IETF ION working group documents on ATM signalling support for IP over ATM [10, 11] provide definitive specifications for Best Effort IP service over ATM.

本节仅用于完整性。IETF ION工作组关于ATM上IP信令支持的文件[10,11]为ATM上的尽力而为IP服务提供了明确的规范。

The best-matched ATM service category to IP Best Effort is UBR. We provide the setup details for this case below. The BE service does not involve reservation of resources. ABR and nrtVBR are also well suited to BE service. See discussion in Section 2.1.3.

与IP尽力而为最匹配的ATM服务类别是UBR。我们将在下面提供此案例的设置详细信息。BE服务不涉及资源预约。ABR和nrtVBR也非常适合作为服务。见第2.1.3节中的讨论。

Note, VCs supporting best effort service are usually point to point, rather than point to multipoint, and the backward channels of VCs are used. In cases where VCs are set up to support best effort multicast sessions, multipoint VCs can be used and the backward channels would be not have resources reserved. Related situations include transport of excess traffic on IP-multicast QoS sessions, or to support the subset of multicast end systems that have not made rsvp reservations. See the discussion on VC management in [12].

注意,支持尽力而为服务的VCs通常是点对点,而不是点对多点,并且使用VCs的反向通道。在将VCs设置为支持尽力而为的多播会话的情况下,可以使用多点VCs,并且向后通道将不会保留资源。相关情况包括在IP多播QoS会话上传输多余流量,或支持未进行rsvp预留的多播终端系统子集。参见[12]中关于风险投资管理的讨论。

7.1 Encoding Best Effort Service Using UBR (ATM Forum TM/UNI 4.0)
7.1 使用UBR编码尽力而为服务(ATM论坛TM/UNI 4.0)

AAL Type 5 Forward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5) Backward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5) SSCS Type 0 (Null SSCS)

AAL类型5前向CPCS-SDU大小9188字节(AAL-5的默认MTU)后向CPCS-SDU大小9188字节(AAL-5的默认MTU)SSC类型0(空SSC)

Traffic Descriptor Forward PCR CLP=0+1 Note 1 Backward PCR CLP=0+1 0 BE indicator included Forward Frame Discard bit 1 Backward Frame Discard bit 1 Tagging Forward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)

流量描述符前向PCR CLP=0+1注1后向PCR CLP=0+1 0 BE指示器包括前向帧丢弃位1后向帧丢弃位1标记前向位1(请求标记)标记后向位1(请求标记)

Broadband Bearer Capability Bearer Class 16 (BCOB-X) Note 2 ATM Transfer Capability 10 (Non-real time VBR) Susceptible to Clipping 00 (Not Susceptible) User Plane Configuration 01 (Point-to-Multipoint)

宽带承载能力承载等级16(BCOB-X)注2 ATM传输能力10(非实时VBR)易受限幅00(不易受限)用户平面配置01(点对多点)

Broadband Low Layer Information User Information Layer 2 Protocol 12 (ISO 8802/2) Note 3

宽带低层信息用户信息第2层协议12(ISO 8802/2)注3

QoS Class QoS Class Forward 0 QoS Class Backward 0

QoS类QoS类前向0 QoS类后向0

Note 1: See discussion in Section 2.5.3. Note 2: Value 3 (BCOB-C) can also be used.

注1:见第2.5.3节中的讨论。注2:也可以使用值3(BCOB-C)。

If Bearer Class C is used, the ATC field MUST be absent Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755.

如果使用承载类别C,则ATC字段必须不存在注3:对于支持GS或CLS的QoS VCs,应指定第3层协议。对于BE VCs,它可以不指定,允许按照RFC 1755由多个协议共享VC。

8.0 Security Considerations
8.0 安全考虑

IP Integrated Services (including rsvp) and ATM are both complex resource reservation protocols, and SHOULD be expected to have complex feature interactions.

IP综合业务(包括rsvp)和ATM都是复杂的资源预留协议,应该具有复杂的功能交互。

Differences in IP and ATM billing styles could cause unforeseen problems since RESV messages can set up VCs. For example, an end-user paying a flat rate for (non-rsvp aware) internet service may send an rsvp RESV message that encounters a (perhaps distant) ATM network with a usage-sensitive billing model. Insufficient authentication could result in services being accidentally billed to an innocent third party, intentional theft of service, or malicious denial of service attacks where high volumes of reservations consume transport or processing resources at the edge devices.

IP和ATM计费方式的差异可能导致无法预见的问题,因为RESV消息可以设置VCs。例如,为(非rsvp感知的)因特网服务支付统一费率的最终用户可以发送rsvp RESV消息,该消息遇到具有使用敏感计费模型的(可能是遥远的)ATM网络。身份验证不足可能会导致服务意外地向无辜的第三方计费、故意窃取服务或恶意拒绝服务攻击,因为大量保留会消耗边缘设备上的传输或处理资源。

The difference in styles of handling excess traffic could result in denial of service attacks where the ATM network uses transport resources (bandwidth, buffers) or connection processing resources (switch processor cycles) in an attempt to accommodate excess traffic that was admitted by the internet service.

处理过量流量的方式不同可能导致拒绝服务攻击,其中ATM网络使用传输资源(带宽、缓冲区)或连接处理资源(交换机处理器周期)试图容纳internet服务允许的过量流量。

Problems associated with translation of resource reservations at edge devices are probably more complex and susceptible to abuse when the IP-ATM edge is also an administrative boundary between service providers. Note also that administrative boundaries can exist within the ATM cloud, i.e., the ingress and egress edge devices are operated by different service providers.

当IP-ATM边缘也是服务提供商之间的管理边界时,与边缘设备上的资源保留转换相关的问题可能更复杂,更容易被滥用。还请注意,管理边界可以存在于ATM云中,即入口和出口边缘设备由不同的服务提供商操作。

Note, the ATM Forum Security Working Group is currently defining ATM-level security features such as data encryption and signalling authentication. See also the security issues raised in the rsvp specification [3].

注意,ATM论坛安全工作组目前正在定义ATM级别的安全功能,如数据加密和信令认证。另请参见rsvp规范[3]中提出的安全问题。

9.0 Acknowledgements
9.0 致谢

The authors received much useful input from the members of the ISSLL working group. In particular, thanks to Drew Perkins and Jon Bennett of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh of Bellcore.

作者从ISSLL工作组的成员那里得到了许多有用的意见。特别要感谢Fore Systems的Drew Perkins和Jon Bennett、IBM的Roch Guerin、Bellcore的Susan Thomson和Sudha Ramesh。

Appendix 1 Abbreviations

附录1缩略语

AAL ATM Adaptation Layer ABR Available Bit Rate APB Available Path Bandwidth (int-serv GCP) ATC ATM Transfer Capability ATM Asynchronous Transfer Mode B-LLI Broadband Low Layer Information BCOB Broadband Connection-Oriented Bearer Capability BCOB-{A,C,X} Bearer Class A, C, or X BE Best Effort BT Burst Tolerance CBR Constant Bit Rate CDV Cell Delay Variation CDVT Cell Delay Variation Tolerance CLP Cell Loss Priority (bit) CLR Cell Loss Ratio CLS Controlled Load Service CPCS Common Part Convergence Sublayer CTD Cell Transfer Delay EOM End of Message GCP General Characterization Parameter GCRA Generic Cell Rate Algorithm GS Guaranteed Service IE Information Element IETF Internet Engineering Task Force ION IP Over Non-broadcast multiple access networks IP Internet Protocol IPI Initial Protocol Identifier IS Integrated Services ISSLL Integrated Services over Specific Link Layers ITU International Telecommunication Union IWF Interworking Function LIJ Leaf Initiated Join LLC Logical Link Control MBS Maximum Burst Size MCR Minimum Cell Rate MPL Minimum Path Latency MTU Maximum Transfer Unit nrtVBR Non-real-time VBR PCR Peak Cell Rate PDU Protocol Data Unit PVC Permanent Virtual Connection QoS Quality of Service RESV Reservation Message (of rsvp protocol) RFC Request for Comments RSVP Resource Reservation Protocol RSpec Reservation Specification

AAL ATM适配层ABR可用比特率APB可用路径带宽(int serv GCP)ATC ATM传输能力ATM异步传输模式B-LLI宽带低层信息BCOB宽带连接导向承载能力BCOB-{A,C,X}承载类别A,C,或X BE尽力而为BT突发容差CBR恒定比特率CDV小区延迟变化CDVT小区延迟变化容差CLP小区丢失优先级(Bit)CLR信元丢失率CLS受控负载服务CPCS公共部分收敛子层CTD信元传输延迟EOM报文结束GCP一般特征参数GCRA通用信元速率算法GS保证服务IE信息元素IETF Internet工程任务组ION IP Over Non-broadcast multiple access Network IP Internet协议IPI初始协议标识符是综合服务ISSLL特定链路层上的综合服务ITU国际电信联盟IWF互通功能LIJ Leaf Initiated Join LLC逻辑链路控制MBS最大突发大小MCR最小信元速率MPL最小路径延迟MTU最大传输单元nrtVBR非实时VBR PCR峰值信元速率PDU协议数据单元PVC永久虚拟连接QoS服务质量RESV保留消息(rsvp协议的)RFC请求注释rsvp资源保留协议RSpec保留规范

rtVBR Real-time VBR SCR Sustainable Cell Rate SDU Service Data Unit SNAP Subnetwork Attachment Point SSCS Service-Specific Convergence Sub-layer SVC Switched Virtual Connection TCP Transport Control Protocol TM Traffic Management TSpec Traffic Specification UBR Unspecified Bit Rate UNI User-Network Interface UPC Usage Parameter Control (ATM traffic policing function) VBR Variable Bit Rate VC (ATM) Virtual Connection

rtVBR实时VBR SCR可持续小区速率SDU服务数据单元SNAP子网连接点SSCS服务特定汇聚子层SVC交换虚拟连接TCP传输控制协议TM流量管理TSpec流量规范UBR未指定比特率单用户网络接口UPC使用参数控制(ATM流量监控功能)VBR可变比特率VC(ATM)虚拟连接

REFERENCES

参考资料

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[2] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.

[2] Braden,R.,Clark,D.,和S.Shenker,“互联网体系结构中的综合服务:概述”,RFC16331994年6月。

[3] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[3] Braden,R.,Zhang,L.,Berson,S.,Herzog,S.,和S.Jamin,“资源预留协议(RSVP)-第1版功能规范”,RFC 22052997年9月。

[4] The ATM Forum, "ATM User-Network Interface Specification, Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.

[4] ATM论坛,“ATM用户网络接口规范,3.0版”,普伦蒂斯大厅,新泽西州恩格尔伍德悬崖,1993年。

[5] The ATM Forum, "ATM User-Network Interface Specification, Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.

[5] ATM论坛,“ATM用户网络接口规范,3.1版”,普伦蒂斯大厅,新泽西州上鞍河,1995年。

[6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification, Version 4.0", July 1996. Available at ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.

[6] ATM论坛,“ATM用户网络接口(UNI)信令规范,版本4.0”,1996年7月。可在ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.

[7] The ATM Forum, "ATM Traffic Management Specification, Version 4.0", April 1996. Available at ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.

[7] ATM论坛,“ATM流量管理规范,4.0版”,1996年4月。可在ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.

[8] M. W. Garrett, "A Service Architecture for ATM: From Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6-14, May 1996.

[8] M.W.Garrett,“ATM服务架构:从应用到调度”,IEEE网络杂志,第10卷,第3期,第6-14页,1996年5月。

[9] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[9] Shenker,S.,Partridge,C.和R.Guerin,“保证服务质量规范”,RFC 2212,1997年9月。

[10] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.

[10] Wroclawski,J.,“受控负荷网元服务规范”,RFC2211,1997年9月。

[11] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.

[11] Perez,M.,Liaw,F.,Mankin,A.,Hoffman,E.,Grossman,D.,和A.Malis,“ATM上IP的ATM信令支持”,RFC 17551995年2月。

[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", RFC 2331, April 1998.

[12] Maher,M.“ATM上IP的ATM信令支持-UNI信令4.0更新”,RFC 2331,1998年4月。

[13] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998.

[13] Crawley,E.,Berger,L.,Berson,S.,Baker,F.,Borden,M.,和J.Krawczyk,“ATM上的综合服务和RSVP框架”,RFC 2382,1998年8月。

[14] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.

[14] Berger,L.“ATM上的RSVP实施要求”,RFC 2380,1998年8月。

[15] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.

[15] Berger,L.,“ATM上的RSVP实施指南”,BCP 24,RFC 2379,1998年8月。

[16] Shenker, S., and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.

[16] Shenker,S.和J.Wroclawski,“网元服务规范模板”,RFC 22161997年9月。

[17] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.

[17] Wroclawski,J.,“RSVP与IETF综合服务的使用”,RFC 2210,1997年9月。

[18] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Real-time Services in an IP-ATM Network Architecture", RFC 1821, August 1995.

[18] Borden,M.,Crawley,E.,Davie,B.,和S.Batsell,“IP-ATM网络架构中的实时服务集成”,RFC 18211995年8月。

[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.

[19] Heinanen,J.,“ATM适配层5上的多协议封装”,RFC 1483,1993年7月。

[20] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January 1994.

[20] Laubach,M.,“ATM上的经典IP和ARP”,RFC 1577,1994年1月。

[21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer performance", International Telecommunication Union, Geneva, October 1996.

[21] 国际电联建议I.356,“B-ISDN ATM层信元传输性能”,国际电信联盟,日内瓦,1996年10月。

[22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Networks", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633-41, May 1995.

[22] A.Romanow,S.Floyd,“ATM网络上TCP流量的动力学”,IEEE J.Sel。《公社地区》,第13卷,第4期,第633-41页,1995年5月。

[23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2, pp. 137-150, April 1994.

[23] A.K.Parekh,R.G.Gallager,“综合业务网络中流量控制的广义处理器共享方法:多节点情况”,IEEE/ACM Trans。《网络》,第2卷,第2期,第137-150页,1994年4月。

[24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, No. 4, August 1995.

[24] S.Floyd,V.Jacobson,“分组网络的链路共享和资源管理模型”,IEEE/ACM Trans。《网络》,第3卷,第4期,1995年8月。

[25] S. Shenker and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.

[25] S.Shenker和J.Wroclawski,“综合业务网络元件的一般特征参数”,RFC 2215,1997年9月。

Authors' Addresses

作者地址

Mark W. Garrett Bellcore 445 South Street Morristown, NJ 07960 USA

美国新泽西州莫里斯镇南街445号马克·W·加雷特·贝尔科,邮编:07960

   Phone: +1 201 829-4439
   EMail: mwg@bellcore.com
        
   Phone: +1 201 829-4439
   EMail: mwg@bellcore.com
        

Marty Borden Bay Networks 42 Nagog Park Acton MA, 01720 USA

Marty Borden Bay Networks 42 Nagog Park Acton MA,美国01720

   Phone: +1 508 266-1011
   EMail: mborden@baynetworks.com
        
   Phone: +1 508 266-1011
   EMail: mborden@baynetworks.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。