[要約] RFC 2381は、制御された負荷サービスとATMの保証されたサービスの相互運用性に関するものであり、その目的は、これらのサービスを統合するためのガイドラインを提供することです。
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.
Copyright（C）The Internet Society（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.
このドキュメントでは、インターネットと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）、およびATMフォーラムUNI仕様のバージョン3.0、3.1、4.0のIP統合サービスプロトコルをサポートしています。 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.)
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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
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]を提供する問題を検討します。このドキュメントは、GSレベルとCLSサービスが他のメカニズムを通じてサポートされる一般的なケースにも適用されますが、IPレベルのリソース予約用のrsvpプロトコル[3]との一貫性を目的としています。 ATMネットワークでは、ATMフォーラムUNIシグナリング、バージョン3.0、3.1、および4.0 [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に関する推奨事項は、通常のBE IPサービスのサポートでATM VCを使用する方法を定義するRFC 1755 [11]、および[12]と一貫することを目的としています。検討している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
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 differences in service definitions, such as the treatment of packets in excess of the flow traffic descriptor, make service mapping a relatively complicated subject.
ただし、完全を期すために、セクション5、6、7ですべてのサービスの組み合わせの詳細なマッピングを提供し、それぞれがより高いレベルのIPサービスの要件をどのように満たすか、満たすことができないかを識別します。マッピングを最も明白なものまたは自然なものに制限しない理由は、ATMの展開が進むにつれて、これらのサービスすべてがどれだけ広く利用可能になるかを予測できないためです。フロートラフィック記述子を超えるパケットの処理など、サービス定義にいくつかの違いがあるため、サービスマッピングは比較的複雑な問題になります。
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サブネットワークの相互作用を提供するためのソリューション全体の一部にすぎません。フロー集約を含むVC管理の重要な問題は、[13、14、15]で検討されています。 QoSに敏感かどうかに関係なく、ルーティングがATM VCの使用とどのように相互作用するかは考慮していません。ここに示したガイドラインの範囲内であっても、かなりの程度の実装の自由度が存在すると予想されます。 IPとATM間のインターワーキングの多くの側面は、経済的要因に依存し、標準化の対象にはなりません。
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ルーティングによって選択された）パス内にあり、1つ以上のATMスイッチで構成されています。 SVCを使用して、ATMクラウド内でリソースとQoSの両方を提供します。これらの接続は、IPルータとATMインターフェイスの両方として機能し、ATMユーザー間でVCを開始および管理できるエッジデバイスによってセットアップ、追加（マルチポイントツリーの場合）、切断、および制御されます。ネットワーク（UNI）インターフェイス。エッジデバイスは、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
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管理ポリシーが可能です。 VCは、実装（機器）またはオペレーター（ネットワークサービスプロバイダー）に固有の標準とローカルポリシールールの組み合わせに従って管理されます。 ATMクラウド内のポイントツーマルチポイント接続を使用して、一般的なIPマルチキャストフローをサポートできます。 ATMでは、ポイントツーマルチポイント接続をソース（またはルート）ノードで制御できます。または、ATMのリーフ開始結合（LIJ）機能を使用できます。 VC管理のトピックは、他の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の一部ではない作業をInterworking Function（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 |
____________________
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）1つのポイントツーマルチポイントVCを使用するために、複数の統合サービスフローを集約できます。この場合、IPフローは同じサービスタイプであり、それらのパラメーターは適切にマージされていると想定しています。 （ii）VC管理機能は、さらなる予約を見越して、またはTSpecの変更の経験に基づいて、追加のリソースを割り当てることを選択できます。 （iii）ベストエフォートフローとrsvp制御メッセージを送信するためのパスが存在する必要があります。これがQoSトラフィックのVCの確立とどのように相互作用するかによって、それらのVCの望ましい特性が変わる場合があります。 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を使用するかどうかが決まります。
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フォーラムは、シグナリング、トラフィック管理、およびその他の領域を1つのドキュメントにまとめたものです（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]およびイオンワーキンググループ[11、12]の作業が含まれます。 Rsvpは、リソース予約プロトコルを定義します（これは、ATMのシグナリングに類似しています）。 Int-servは、特定のサービスの動作とセマンティクスを定義します（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.)
多くのATMシグナリングの詳細はRFC 1755 [10]でカバーされています。たとえば、UNI 3.0とUNI 3.1の違い、カプセル化、フレームリレーインターワーキングなど。これらの考慮事項は、QoSを使用したIP over ATMにも適用されます。このドキュメントでのATMを介したIPベストエフォートサービス（つまり、デフォルトの動作）の説明は、RFC 1755との一貫性を意図しており、UNI 4.0 [11]の拡張であり、これらのドキュメントは最終的なものと見なされます。ベストエフォート以外のサービスの場合、特定のIP / ATM機能は次のRFC 1755から逸脱します。このような違いに明示的に注意を払いました。 （たとえば、ベストエフォートVCは、タイムアウト時にいずれかのエッジデバイスによって停止される可能性がありますが、QoS VCは、対応するrsvp予約が削除されたときに上流のエッジデバイスによってのみ削除されます。）
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.
別の関連文書はRFC 1821 [17]で、統合サービスとQoSのための相互運用IPおよびATMプロトコルに関連する問題の初期の議論を表しています。
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 VCの作成に関連するこれらの各項目について説明します。ルーティングとアドレッシングは（少なくとも現在のところ）QoSに依存しないため、ここでは説明しません。サービスカテゴリのセクションに続いて、IPおよびATMのタグ付けと準拠の定義について説明します。これらは、使用されるポリシング方式によって暗示されるため、上記のリストではセットアップパラメータとして明示的には表示されません。
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 VCの機能を区別する最高レベルの抽象化は、サービスカテゴリまたはベアラ機能にあります。サービスカテゴリは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の場合、ベアラー機能（ここでは）には2つの異なるオプションしかありません。
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 distinction is applicable, the appropriate code SHOULD be used (see [5] and related ITU specs, e.g., I.371).
3つ目の機能であるBCOB-Xは、上記の2つの機能の代わりに使用でき、その依存パラメーター（トラフィックタイプとタイミング要件）を適切に設定します。 BCOB-Xの定式化と（同等の）BCOB-AおよびBCOB-C構成との違いは、ATMネットワークが純粋なセルリレーサービスを提供するか、他のテクノロジーとのインターワーク（相互運用可能なシグナリングを使用）を提供するかなどです。狭帯域ISDNとして。この区別が適用される場合は、適切なコードを使用する必要があります（SHOULD）（[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).
これらの最初の2つはリアルタイムサービスであるため、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]。
There are two possible mappings for GS:
GSには2つの可能なマッピングがあります。
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では、Bearer Class 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の2つのレートが必要になります（ATM標準による）。これは、指定されたピークおよび持続可能なレートでバースト性トラフィックをモデル化します。対応するATMトークンバケットの深さの値は、それぞれCDVTおよびCDVT + BTです。
There are three possible good mappings for CLS:
CLSには3つの適切なマッピングがあります。
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はありません。 1つ目は、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のトークンバケットレートから直接変換する必要があります。バケットサイズパラメータは、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.
エッジデバイスはCTDおよびCDVの値を決定する必要がありますが、rtVBRカテゴリを使用できます。対応する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では使用できないトークンバケットトラフィック記述子によって促進されます。
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の場合、ネットワークオペレータはアドミッションコントロール機能を通じてサービス全体に帯域幅を割り当てる必要があります（SHOULD）。ただし、そのような割り当ては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が設計された明確な目的です。通常のケースでは、単一のABR接続を共有する共通の出口ルーターですべてのIPベストエフォートトラフィックが発生する可能性がありますが、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.
ATMでのベストエフォートサービスのサポートに関する関連作業については、IETFイオンワーキンググループ[10、11]の仕様を参照してください。
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サービス用の「リーキーバケット」アルゴリズムとも呼ばれるGeneric Cell Rate Algorithm（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実装の実際の動作を確認する必要があります（SHOULD）。
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設定で選択する必要があります（SHOULD）。 「ベストエフォート」という用語は2つの方法で解釈できます。 1つ目は、たとえば、個別のキューとして実装できるサービスクラスとしてです。もう1つの意味はより一般的です。つまり、ネットワークはトラフィックの転送に最善を尽くします。これを合理的に解釈すると、トラフィックが競合していないネットワークはパケットを転送し、非常に輻輳しているネットワークはパケットをドロップします。 （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 network to indicate congestion.
考慮すべきVRTサービス（rtVBRとnrtVBRの両方）の3つの適合定義があります。 VBRでは、適合定義VBR.3のみがタグ付けをサポートし、レートPCRのGCRAを集約CLP = 0 + 1セルに適用し、レートSCRの別のGCRAをCLP = 0セルに適用します。この適合定義は、常にIP統合サービスをサポートするVBRサービスで使用する必要があります（SHOULD）。 UBRサービスの場合、適合定義UBR.2はタグ付けの使用をサポートしますが、CLP = 1セルは不適合を意味しません。むしろ、それは混雑を示すためにネットワークによって使用されるかもしれません。
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.
ATMネットワークがセルをタグ付けすることが予想できる場合、IWFは常にセルにタグを付ける方が適切です。これは、IWFがIPパケットの境界を認識しており、パケットに対応するすべてのセルにタグを付けることができるためです。 ATM層のUPCに任せると、ネットワークは必然的にパケットの一部のセルをドロップする一方で、他のセルを搬送し、その後、レシーバーによってドロップされます。したがって、VC GCRAパラメータを知っているIWFは、ATM UPCによってタグ付けされるセルを常に予測し、影響を受ける各パケットにわたってすべてのセルに均一にタグ付けする必要があります（SHOULD）。過剰なトラフィックの詳細については、セクション3.2を参照してください。
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エンコーディングを使用する必要があります（SHOULD）。AAL-5の場合、順方向と逆方向の両方での最大SDUサイズの指定が必要です。 GSとCLSはどちらもTSpecの一部として最大パケットサイズMを指定します。この値は、ユニキャスト接続および単方向ポイントツーマルチポイント接続の各方向の最大SDUとして使用する必要があります（AALヘッダーで修正）。複数のフローが単一のVCに集約される場合、レシーバーTSpecのMパラメーターは、GSおよびCLS仕様で指定されたルールに従ってマージされます。
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 IEがネゴシエーションの一部として送信される場合があります。 LLC / SNAPカプセル化[18]はデフォルトとしてサポートされるべきです（SHOULD）が、「null」または「VCカプセル化」も許可される場合があります。実装は、BLLIの使用に関してRFC 1577 [19]およびRFC 1755 [10]に従う必要があります。
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 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.
ATMトラフィック記述子には、常に（各方向の）ピークセルレート（PCR）が含まれています。 VBRサービスの場合は、持続可能なセルレート（SCR）と最大バーストサイズ（MBS）も含まれます。 SCRと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で説明します。
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があります。2つの異なる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 <= 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は、PATHメッセージのAdspec部分でネゴシエートされる一般的な特性化パラメーターAVAILABLE_PATH_BANDWIDTHを参照します。 APBは、パスに沿った最も狭いボトルネックレートを反映しているため、常にローカルラインレートを超えません。ソースはAPBの値を知らないため、ソースのピークレートp_sはより高くなる可能性がありますが、受信者は予約を受け入れるためにAPB以下のピークレートを選択する必要があります（SHOULD）。もちろん、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.
上記のPCR = p_r、SCR = Rの単純なマッピングに必要となるため、通常、R <= p_rが見つかると予想します。ただし、受信機はGS遅延を下げるためにR> p_rを自由に選択できます[8]。この場合、バッファに到着するサイズbのバーストをレートRでクリアして、GS遅延の最初のコンポーネントをb / Rに抑える必要があるため、PCRをR未満に設定することはできません。したがって、ここではPCR = Rになります。データはp_rによって制限されたレートでソースで生成されるため、バッファオーバーフローを回避するにはPCR = 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の場合でも、R <= PCR <p_rとなるようなPCRを選択できます。エッジデバイスバッファは、バーストよりも速く到着するバースト（サイズb_r + C_sum + R D_sumに制限されます）を吸収するために必要（かつ十分）です。たとえば、ATM VCのコストはPCRに依存し、インターネットサービス予約のコストはIPレベルのピークレートに強く依存しない場合があります。次に、ユーザーはp_rをAPBに設定するインセンティブを持ち、IP / ATMエッジルーターのオペレーターはPCRを可能な限り削減するインセンティブを持っています。 IPとATMの課金モデルは使用感度まで歴史的に異なっており、p_rの値がAPBの近くに設定されている場合、Rの公称GS割り当てレートの何倍にもなる可能性があるため、これは現実的な懸念事項になる可能性があります。 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 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.
SCRをR未満の値に設定する場合は、より微妙で、おそらく議論の余地があります。GSサービスの主な機能は、受信者が割り当てられたレートRを、トラフィックを転送するのに十分なレートr_rよりも大きくなるように指定できることです。キューイング遅延を（大まかに）b / r + C_TOT / r + D_TOTからb / R + C_TOT / R + D_TOTに下げるため。帯域幅Rをフローに効果的に割り当てるために、SCRをRに一致するように設定します（SCRをRより上に設定する必要はありません。したがって、SCR <= Rの関係は依然として真です。）SCRを設定することが可能です。遅延範囲に違反したり、エッジデバイスバッファーをオーバーフローしたりせずに、r_r程度の低い値に設定します。 PCR = Rの場合、サイズbのバーストがバッファリングされ、レートRでATMネットワークに送信されるため、最後のバイトの遅延はb / Rのみになります。それ以降のトラフィックはSCRであるレートr_rに制限されるため、到着レートと出発レートが一致しているため、その遅延も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サービスの要件を満たしていますが、RではなくSCR = 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トークンバケットパラメータに従ってバーストを吸収するのに十分なバッファがあるため、これは異常な場合があります。 2つのケースを考えます。まず、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より下に設定されている場合、中間のトレードオフを定式化できることも事実です。 SCRがフローのエッジデバイスへの物理的なラインレートを超えるように設定されていない限り、ジッター吸収バッファー（C_sum + R D_sum）は、通常、ATMレートを上げることによって回避できないことに注意してください。
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）になります。 C_sum、D_sumによって与えられるネットワークジッタを吸収するのに十分な追加のバッファーは、常にエッジルーター、またはMBSを介してATMネットワークに提供する必要があります。
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,
Controlled Loadサービスの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の削減に関する説明は、一般にCRT over nrtVBRの場合にも当てはまります。蓄積されたジッター（ソースで許可されている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 ingress edge device when the ATM network becomes congested.
ABR VCの場合、TSpecレートr_rを使用して最小セルレート（MCR）パラメータを設定します。対応する信号バケット深度パラメーターがないため、エッジデバイスには、少なくともb_rバイトのバッファーと、ジッターを吸収するための追加のバッファーが必要です（SHOULD）。 ABRを使用すると、ATMネットワークは実際の転送速度をMCRにすばやく下げることができるため、その速度を超えて送信する送信元は、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_rよりはるかに低くなります。この例に反映されているように、フルリンク帯域幅（r_L）へのアクセスは、共有リンクの「無負荷状態」での遅延のより文字どおりの解釈ですが、ATM VCはその公称割り当て（ SCRおよびPCRのいくつかの実装固有の機能）。
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].
多くの場合、サービスプロバイダーは、2つのエッジルーター間のすべてのベストエフォートトラフィックを処理するために、特定の帯域幅割り当てで大規模なVCを静的に構成します。 ABR、CBR、またはnrtVBR VCはこの設計に適しており、予想されるトラフィック負荷に快適に対応するようにトラフィックパラメーターが設定されています。 IP over ATMシグナリングのIETF ION仕様を参照してください[10、11]。
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では、3つの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パラメータが定義されていない」と明確に定義されています）。これらの仕様では、一般にこのガイダンスに従い、QBRクラス値をUBRおよびABR（必須）に対して0、CBRおよびrtVBRに対して1、nrtVBRに対して3に設定します。 QoSクラスは、サポートされる可能性が低い組み合わせを避けるために、IPサービスではなく、ATMサービスカテゴリに従います。たとえば、GSで使用できるのがnrtVBRだけの場合、QoSクラス= 1を選択すると接続が失敗する可能性があります。 QoSクラスは、本質的に非リアルタイムのサービスにリアルタイムの動作を追加する方法として解釈してはなりません（MUST NOT）。
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は、Recommendation 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.
入力エッジルーターは、VCを確立できる出力ルーターのセットのQoS情報のテーブルを保持する必要があります（SHOULD）。このテーブルはデフォルト値を使用して簡略化できますが、最も人気のある出力ポイントの現在のデータのテーブルを維持することをお勧めします。 VCセットアップを開始するエッジデバイスは、ネゴシエーションによって変更された場合でも、通常、CDVおよびCTDの初期値を提案する何らかの方法が必要です。そのため、このようなテーブルを配置することで、新しい設計負担は生じません。キャッシュされた情報は、VCが正常に確立されたときに更新できます。また、IPレイヤー予約がVCの完了を待機できる範囲で、反復ネゴシエーションによって値を調整できます。
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 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]).
GSとCLSの両方で、輻輳によるパケットの損失を最小限に抑え、損失率が無負荷ネットワークの場合とほぼ同じになるようにする必要があります。輻輳によるものではない物理媒体の特徴的な損失動作（たとえば、ビットエラーまたはワイヤレスチャネルのフェージング）により、許可されるパケット損失率の順序が決まります。入力エッジデバイスは、適切なIPレベルのパケット損失率を提供するCLRの値を選択する必要があります。 CLR値は、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のコンポーネントが1つではなく2つ含まれている可能性があることに注意することは興味深い（そしておそらく残念なことです）。 SCR = Rがパスに沿ったIPルータとATMスイッチの両方のフローに割り当てられたレートであり、バッファ割り当てがMBS = bである単純なケースを考えてみます。 GS遅延式[8]の基礎であるパレクの理論[23]は、サイズbのバーストがレートRで輻輳したノードによって処理されると、パケットが単一のバーストとして後続のノードに到着しません。ただし、このボトルネックがATMネットワークまたはIPネットワークの他の場所で発生するかどうかをアプリオリに判断することはできないため、CDVの宣言でそれを考慮する必要があります（つまり、CDV> = b / R）。 CDVが設定されると、ATMネットワークは、トラフィックがバーストで到着するかどうかにかかわらず、この遅延を課すことができます。遅延b / Rは他の場所でも発生する可能性があるため、GS遅延式の最初の項から削除することはできません。 ATM b / R遅延コンポーネントは、GS遅延式の第3項、D_totに現れます。 GS Adspecパラメータの詳細については、以下のセクション3.3を参照してください。この影響は、ATMネットワークがより効率的な統計リソース割り当て方式を採用している場合に軽減される可能性があります。
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セルよりも大きいPDU（つまり、ここではIPパケットに対応するAAL PDU）をATMネットワークが認識するモードを選択できます。これにより、部分的なパケット廃棄などのアルゴリズムの実装が容易になります。この場合、ドロップされたセルにより、同じ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.
破損したPDUの残りのセルは一般に受信者にとって役に立たないため、フレーム廃棄はTCPなどのエンドツーエンドプロトコルの効率とパフォーマンスを向上させることができます。 IP over ATMの場合、可能であれば、フレーム破棄を常に指定する必要があります。
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のPATHメッセージのAdspec部分を使用して中間ノードによって変更されます。 GS固有のAdspecパラメータについては、以下のセクション3.3で説明します。これらのパラメーターは、<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>は、これらのガイドラインに従う実装によって単独で残される必要があります（これらはおそらくISに対応しているため）。同様に、ルーターは常にIS_HOPS <1,4>をインクリメントする必要があります。サービスのサポートが不十分な場合は、GSおよびCLSサービス固有のブレークビット、それぞれ<2,2>および<5,2>を設定する必要があります。一般に、GSはCBR（BCOB-A）およびrtVBRサービスカテゴリで適切にサポートされており、遅延が制御されていないため、UBR、ABR、およびnrtVBRでは適切にサポートされていません。 CLSは、UBR（またはUNI 3.xのベストエフォート）を除くすべてのサービスカテゴリで適切にサポートされます。詳細については、セクション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.
Available Path Bandwidth（APB）パラメータ<x、6>は、パスに沿った最小の物理的なボトルネックレートを示します。これは、同じパス上の任意のUBR VCのネゴシエートされたPCR値として、ATMネットワークで検出される場合があります。この値は、有効なIPデータグラム帯域幅を反映するために、必要に応じて、AAL、ATM、および物理層ヘッダーに対して修正する必要があります。 ATMでは、物理リンクのボトルネックを下回る、PCRの値にいくつかのポリシー制限がある可能性があります。この場合、APBのアドバタイズされた値（一般に、および通知されたAPBの値がサービス固有である場合は各サービスに対して）は、このレートを超える過剰なトラフィックがドロップされるため、この制限を反映する必要があります。 （TM / UNI 4.0では、PCRを超えるトラフィックのタグ付けは行われないことに注意してください。）これらの値は、通常、VCを確立する必要がある一連の出力ルーターの入力ルーターによってキャッシュされる必要があります（SHOULD）。 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ネットワークを出るときに、PATHメッセージのこれらの値を修正する必要があります。 （「正しい」という言葉を使用します。これは、入力ルーターがパラメーターを最大数のブランチに適した値、または出力ルーターが各ブランチのそのようなパラメーターを修正できなかった場合に最も害が少ない値に設定する必要があるためです。 。）これは、出力ルーターがrsvp制御メッセージを操作する必要がある唯一のケースです。 （同様の修正は、非rsvpセットアップメカニズムに対して実装する必要があります）。このような修正が必要なパラメータは、Available Path Bandwidth（APB）、Minimum Path Latency（MPL）、Path MTU（ただし、ATM / AAL-5の場合、これは通常一定である可能性があります）、およびATM固有のコンポーネントです。 GS AdspecパラメータC_ATMおよびD_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>の値を格納する必要があります（SHOULD）。合成された値<x、8>は加算によって形成され、パスに沿って転送されます。 ATMルーティングが、特定の出力ポイントへのVCに対して、サービスカテゴリに応じて異なるパスを選択する場合、通常、テーブルは各サービスの異なる値を反映します。 ATMネットワークが非常に大きく複雑な場合、VCが設定されると、VCがたどるルートを予測するのが困難になる可能性があります。これは設定ミスの重大な原因である可能性があり、GS遅延アドバタイズメントと実際の結果との間に不一致が生じます。 RSpec Slack用語は、この問題を軽減するのに役立つ場合があります。
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 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].
AAL-5は最大65,535バイトのメッセージサイズをサポートするため、AAL SDUをレシーバーのTSpec Mパラメータ値（LLC / SNAPヘッダーに8バイトを追加）に設定しても、通常は問題になりません。ただし、PATH Adspecでは、各サービスのPATH_MTUパラメータ<x、10>は、AAL-5のデフォルトMTUである9188バイトに設定する必要があります[19]。
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では、トラフィックポリサーは「非準拠のデータグラムをベストエフォートに委任する必要があります」。過剰なトラフィックはサポートする必要があります（SHOULD）。ベストエフォートベースでは、準拠するCLSおよびGSトラフィックのQoS（遅延と損失）や、予約されていないベストエフォートトラフィックの通常のサービスを妨害してはなりません（MUST NOT）。
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ビットを使用して過剰なトラフィックに低優先度のタグを付けることです。これにより、フローの並べ替えが回避されますが、出力ルータースケジューラの慎重な設計が必要になります。並べ替えを回避するために、超過トラフィックは適合トラフィックとともにキューに入れることができます。しきい値は、適合トラフィックが超過によって不必要に遅延されないようにするために使用する必要があります（SHOULD）。また、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仕様では、2つの可能な実装が提案されています。1つは、過剰トラフィックがベストエフォートクラススケジューラの割り当てを共有しますが、他のベストエフォートトラフィックよりも優先度が低い場合です。もう1つは、個別の割り当てが行われる場所です。 1つ目は、過剰なトラフィックが通常のベストエフォートトラフィックと同じVCを使用できるようにし、2つ目は別の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 / UNI 4.0。 PCRを超えるトラフィックのタグ付けはサポートしていません。 UNI 3.xにはCLP = 0セルのみの個別のPCRパラメータがありますが、TM / UNI 4.0機器との相互運用性の理由から、この機能の使用はお勧めしません。これにより、CBR VCがタグ付け以外のソリューションを使用することが制限されます。 PCRの値は、同じVC上の過剰なトラフィックをサポートするために、適合トラフィックに必要な値よりも高く設定できます。場合によっては、高PCRに課される追加コストがほとんどない場合など、これが実行可能な解決策になることがあります。 PCRをAPBと同じ高さに設定できる場合、過剰なトラフィックは完全に処理されます。
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フローに関連する最悪の場合の遅延を計算できるようにします。ソースからレシーバーへのPATHメッセージには、C、D、およびMPLの3つの量が（各ネットワーク要素に対応するコンポーネントを追加するだけで）蓄積されます。結果の遅延値は、一意の受信機ごとに異なる場合があります。最大遅延は次のように計算されます
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_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 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の値は、ルーターパケットスケジューラとルーターに接続されているサブネットの特性の両方に依存します。各ルーター（または送信元ホスト）は、そのアドバタイズでダウンストリームサブネットを担当します。たとえば、サブネットが単純なポイントツーポイントリンクの場合、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.
この説明では、C_ATMおよびD_ATMで示される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で説明したように、エッジルータは、VCを共有する必要がある各出力ルータのMPLとD_ATMの値を含むテーブルを保持しています。 D_ATMの値は、エッジルーターによってアドバタイズされるDパラメーターに影響し、セットアップ時にルーターがVCに入るCDVを正確に反映する必要があります（SHOULD）。 ATMネットワークでの統計的多重化など、CDVに影響する要素は、ルーターのテーブルのデータをコンパイルするときに考慮されるべきです（SHOULD）。不確実な場合は、D_ATMを上限に設定できます。 RESVメッセージが到着してVCがセットアップされると、CTDおよびCDVの要求値は、受信側RSpecのスラック項を使用して緩和できます。
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.
マルチポイントVCでは、出力エッジルーターがCおよびDのアドバタイズされた値を修正する必要がある場合があることに注意してください。セクション3.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 and cells/sec.
IPレベルのパラメーターからATMパラメーターにマップされるすべてのレートとトークンバケットの深さパラメーターは、追加されたヘッダーとパケットのセルへのセグメント化の影響を修正する必要があります。 IP層では、トークンバケットの深さとレートはそれぞれバイトとバイト/秒で測定されますが、ATMではセルとセル/秒で測定されます。
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にラップされ、多数の追加ヘッダーバイト（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]
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」は部分的にのみ埋められる最後のセルを表します。
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 VCを作成する方法について説明します。重要な点は、リアルタイムのタイミングが必要であること、データフローの速度が可変であること、および非準拠トラフィックをベストエフォートに降格することがGSの定義と一致している必要があることです。このため、タグ付けがサポートされているrtVBRサービスをお勧めします。 CBR VCはPCRを超えるトラフィックに対応しないため、別の適切な方法は、CBRを、たとえば別のVCを介して、非準拠トラフィックの特別な処理で使用することです。
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サービスの要件を満たしているかどうかを示すコメントを提供します。
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フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトSSCSタイプ0（Null SSCS）
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 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）も使用できます。 Bearer Class Cが選択されている場合、ATCフィールドは存在しない必要があります。注3：ATC値19は使用されません。値19は、CLRの目的が集約CLP = 0 + 1ストリームに適用され、過剰なトラフィックを適切に処理しないことを意味します。注4：GSまたはCLSをサポートするQoS VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、指定しないままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注5：Cf ITU Rec。新しいQoSクラスの定義については、I.356 [21]。注6：2.6項の説明を参照してください。
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フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトSSCSタイプ0（Null SSCS）
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インジケーターは含まれません）
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）も使用できます。 Bearer Class Aが選択されている場合、ATCフィールドは存在しない必要があります。注3：ATC値7は使用されません。値7は、CLR目標が集約CLP = 0 + 1ストリームに適用され、過剰なトラフィックの望ましい処理を提供しないことを意味します。注4：GSまたはCLSをサポートするQoS VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、指定しないままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注5：Cf ITU Rec。新しいQoSクラスの定義については、I.356 [21]。注6：2.6項の説明を参照してください。
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を参照してください。
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.
ABRを使用するGSはほとんどあり得ない組み合わせであり、GSのサービス要件を満たしていません。 ABRサービスの目的は、「低い」損失率を提供することです。 ABRの遅延目標は非常に緩やかであることが期待されるべきです（SHOULD）。 ABRがGSに使用された場合、VCパラメータはCLS over ABRの場合と同様に続きます。セクション6.2を参照してください。
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に使用する場合は、フォワードPCRが受信側TSpecのピークレートから決定されることを除いて、UBRよりもベストエフォートと同じ方法でエンコードされます。セクション7.1を参照してください。
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.
BCOB-Cベアラークラスはリアルタイムの動作を表さないため、UNI 3.x VBRモードを使用してGSをサポートすることは推奨されません。また、UNI 3.1仕様の付録Fでは、トラフィックタイプ「VBR」の仕様に、ベアラクラスXと組み合わせたタイミング要件「エンドツーエンドのタイミングが必要」が含まれていません。
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フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトモード1（メッセージモード）注1 SSCSタイプ0（ヌルSSCS）
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 0フォワードPCR CLP = 0 + 1注2バックワードPCR CLP = 0 + 1 0 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 VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、指定しないままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注5：QoSパラメータは、QoSクラスによって暗示されます。
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 VCを作成する方法について説明します。 CLSトラフィックは部分的に遅延耐性があり、可変レートを持っています。 CRTをサポートするには、NrtVBRとABR（TM / UNI 4.0のみ）が最適です。
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サービスの要件を満たしているかどうかを示すコメントを提供します。
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フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトSSCSタイプ0（Null SSCS）
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 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 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）も使用できます。 Bearer Class Cを使用する場合、ATCフィールドは存在しない必要があります。注3：ATC値11は使用されません。値11は、CLR目標が集約CLP = 0 + 1ストリームに適用され、過剰なトラフィックの望ましい処理を提供しないことを意味します。注4：GSまたはCLSをサポートするQoS VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、指定しないままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注5：Cf ITU Rec。新しいQoSクラスの定義については、I.356 [21]。注6：2.6項の説明を参照してください。
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 SSCS Type 0 (Null SSCS)
AALタイプ5フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトSSCSタイプ0（Null SSCS）
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）も使用できます。 Bearer Class Cが選択されている場合、ATCフィールドは存在しない必要があります。注3：GSまたはCLSをサポートするQoS VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、これを未指定のままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注4：Cf ITU Rec。新しいQoSクラスの定義については、I.356 [21]。注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]を参照してください。
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.
CLSにCBRを使用するには、GS over CBR（セクション5.2）と同じエンコーディングが使用されます。セクション2.5.2の説明を参照してください。
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ネットワークのエンドツーエンドの遅延に対するハード制限を意味します。これは、CLSサービスが必要とするよりも複雑なVCセットアップを作成するため、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の説明を参照してください。
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の要件を満たしません。使用する場合は、UBR over BE（セクション7.1）と同じ方法でコーディングされますが、PCRは受信機のTSpecのピークレートから決定されます。
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フォワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトバックワードCPCS-SDUサイズパラメータMのrcvr TSpec + 8バイトモード1（メッセージモード）注1 SSCSタイプ0（ヌルSSCS）
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 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 VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、指定しないままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。注5：Cf ITU Rec。新しいQoSクラスの定義については、I.356 [21]。 QoSパラメータはQoSクラスによって暗示されます。
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.
このセクションは、完全を期すためにのみ提供されています。 ATM over IPのATMシグナリングサポートに関するIETF IONワーキンググループのドキュメント[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もBEサービスに適しています。セクション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].
ベストエフォートサービスをサポートするVCは通常、ポイントツーマルチポイントではなくポイントツーポイントであり、VCのバックワードチャネルが使用されます。ベストエフォートマルチキャストセッションをサポートするようにVCが設定されている場合、マルチポイントVCを使用でき、逆方向チャネルにはリソースが予約されていません。関連する状況には、IPマルチキャストQoSセッションでの過剰なトラフィックの転送、またはrsvp予約を行っていないマルチキャストエンドシステムのサブセットをサポートすることが含まれます。 [12]のVC管理に関する説明を参照してください。
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）SSCSタイプ0（ヌルSSCS）
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.
Bearer Class Cを使用する場合、ATCフィールドは存在しない必要があります。注3：GSまたはCLSをサポートするQoS VCの場合、レイヤー3プロトコルを指定する必要があります（SHOULD）。 BE VCの場合、未指定のままにして、RFC 1755に従って、VCを複数のプロトコルで共有することができます。
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はどちらも複雑なリソース予約プロトコルであり、複雑な機能の相互作用が必要です（SHOULD）。
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.
RESVメッセージはVCを設定できるため、IPとATMの課金スタイルの違いにより、予期しない問題が発生する可能性があります。たとえば、エンドユーザーが（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ネットワークでは、インターネットサービスによって許可された過剰なトラフィックに対応するために、トランスポートリソース（帯域幅、バッファー）または接続処理リソース（スイッチプロセッササイクル）を使用します。 。
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]で提起されたセキュリティ問題も参照してください。
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 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
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セル損失優先度（ビット）CLRセル損失率CLS制御ロードサービスCPCS共通部分収束サブレイヤーCTDセル転送遅延EOMメッセージの終わりGCPの一般的な特性パラメータGCRA汎用セルレートアルゴリズムGS保証サービスIE情報要素IETFインターネットエンジニアリングタスクフォースION IP over Non-broadcast multiple access networks IPインターネットプロトコル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 Cont rol MBS最大バーストサイズMCR最小セルレートMPL最小パスレイテンシMTU最大転送単位nrtVBR非リアルタイムVBR PCRピークセルレートPDUプロトコルデータユニットPVC恒久仮想接続QoSサービス品質RESV予約メッセージ（rsvpプロトコルの）RFC要求RSVP Resource Reservation Protocol RSpec Reservation Specification 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ビットレートUNIユーザーネットワークインターフェイス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、「Integrated Services in the Internet Architecture：an Overview」、RFC 1633、1994年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、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[4] The ATM Forum, "ATM User-Network Interface Specification, Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.
[4] ATMフォーラム、「ATM User-Network Interface Specification、Version 3.0」、Prentice Hall、Englewood Cliffs NJ、1993。
[5] The ATM Forum, "ATM User-Network Interface Specification, Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.
[5] ATMフォーラム、「ATM User-Network Interface Specification、Version 3.1」、Prentice Hall、Upper Saddle River NJ、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 User-Network Interface（UNI）Signaling Specification、Version 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 Network Mag。、Vol。 10、No。3、pp。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。、「Controlled-Load Network Element Serviceの仕様」、RFC 2211、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 Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", RFC 2331, April 1998.
[12] Maher、M。、「IP over ATMの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、「A Framework for Integrated Services and RSVP over ATM」、RFC 2382、1998年8月。
[14] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[14] Berger、L。、「RSVP over ATMの実装要件」、RFC 2380、1998年8月。
[15] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
[15] Berger、L。、「RSVP over ATM実装ガイドライン」、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、「Network Element Service Specification Template」、RFC 2216、1997年9月。
[17] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[17] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、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 1821、1995年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。、「Classical IP and ARP over ATM」、RFC 1577、1994年1月。
[21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer performance", International Telecommunication Union, Geneva, October 1996.
[21] ITU勧告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。 Commun。、Vol。 13、No。4、pp.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。ネットワーキング、Vol。 2、No。2、pp.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.フロイド、V。ジェイコブソン、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE / ACM Trans。ネットワーキング、Vol。 3、No。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、「Integrated Service Network ElementsのGeneral Characterization Parameters」、RFC 2215、1997年9月。
Authors' Addresses
著者のアドレス
Mark W. Garrett Bellcore 445 South Street Morristown, NJ 07960 USA
Mark W. Garrett Bellcore 445 South Street Morristown、NJ 07960 USA
Phone: +1 201 829-4439
EMail: mwg@bellcore.com
Marty Borden Bay Networks 42 Nagog Park Acton MA, 01720 USA
マーティボーデンベイネットワークス42 Nagg Park Octane Ma、017 To Us
Phone: +1 508 266-1011
EMail: mborden@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。