[要約] RFC 2815は、IEEE 802ネットワーク上での統合サービスマッピングに関する標準化されたプロトコル仕様です。このRFCの目的は、異なるサービスを提供するネットワーク機器間での統合サービスのマッピングを可能にすることです。
Network Working Group M. Seaman
Request for Comments: 2815 Telseon
Category: Standards Track A. Smith
Extreme Networks
E. Crawley
Unisphere Solutions
J. Wroclawski
MIT LCS
May 2000
Integrated Service Mappings on IEEE 802 Networks
IEEE 802ネットワークの統合サービスマッピング
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.
このドキュメントでは、IEEE 802ネットワークセグメントから構築されたIETF統合サービスのマッピングについて、IEEE 802.1D Macブリッジ（スイッチ）によって相互接続される可能性があります。関連するIEEE 802テクノロジーの固有の機能、特に802.1-1998キューイング機能をスイッチで使用して、制御された負荷と保証サービスをサポートするためのパラメーターマッピングについて説明します。
These mappings are one component of the Integrated Services over IEEE 802 LANs framework.
これらのマッピングは、IEEE 802 LANSフレームワークを介した統合サービスの1つのコンポーネントです。
Table of Contents
目次
1 Introduction ............................................... 2
2 Flow Identification and Traffic Class Selection ............ 3
3 Choosing a flow's IEEE 802 user_priority class ............. 5
3.1 Context of admission control and delay bounds ............ 6
3.2 Default service mappings ................................. 7
3.3 Discussion ............................................... 9
4 Computation of integrated services characterization parameters
by IEEE 802 devices .....................................10
4.1 General characterization parameters ......................10
4.2 Parameters to implement Guaranteed Service ...............11
4.3 Parameters to implement Controlled Load ..................11
4.4 Parameters to implement Best Effort ......................12
5 Merging of RSVP/SBM objects ................................12
6 Applicability of these service mappings ....................13
7 References .................................................14
8 Security Considerations ....................................15
9 Acknowledgments ............................................15
10 Authors' Addresses ........................................16
11 Full Copyright Statement ..................................17
The IEEE 802.1 Interworking Task Group has developed a set of enhancements to the basic MAC Service provided in Bridged Local Area Networks (a.k.a. "switched LANs"). As a supplement to the original IEEE MAC Bridges standard, IEEE 802.1D-1990 [802.1D-ORIG], the updated IEEE 802.1D-1998 [802.1D] proposes differential traffic class queuing in switches. The IEEE 802.1Q specification [802.1Q] extends the capabilities of Ethernet/802.3 media to carry a traffic class indicator, or "user_priority" field, within data frames.
IEEE 802.1インターワーキングタスクグループは、Bridgedローカルエリアネットワーク（別名「LANS」）で提供される基本MACサービスの一連の拡張機能を開発しました。元のIEEE Mac Bridges StandardのサプリメントであるIEEE 802.1D-1990 [802.1D-Orig]として、更新されたIEEE 802.1D-1998 [802.1d]は、スイッチでの微分交通クラスのキューイングを提案しています。IEEE 802.1q仕様[802.1q]は、データフレーム内のトラフィッククラスインジケーター、または「user_priority」フィールドを運ぶために、イーサネット/802.3メディアの機能を拡張します。
The availability of this differential traffic queuing, together with additional mechanisms to provide admission control and signaling, allows IEEE 802 networks to support a close approximation of the IETF Integrated Services capabilities [CL][GS]. This document describes methods for mapping the service classes and parameters of the IETF model into IEEE 802.1D network parameters. A companion document [SBM] describes a signaling protocol for use with these mappings. It is recommended that readers be familiar with the overall framework in which these mappings and signaling protocol are expected to be used; this framework is described fully in [IS802FRAME].
この差動トラフィックキューイングの可用性は、入学制御とシグナリングを提供する追加のメカニズムとともに、IEEE 802ネットワークがIETF統合サービス機能[CL] [GS]の密接な近似をサポートできるようにします。このドキュメントでは、IETFモデルのサービスクラスとパラメーターをIEEE 802.1Dネットワークパラメーターにマッピングする方法について説明します。コンパニオンドキュメント[SBM]は、これらのマッピングで使用するシグナル伝達プロトコルについて説明しています。読者は、これらのマッピングとシグナル伝達プロトコルが使用されると予想される全体的なフレームワークに精通することをお勧めします。このフレームワークは、[is802frame]で完全に説明されています。
Within this document, Section 2 describes the method by which end systems and routers bordering the IEEE Layer-2 cloud learn what traffic class should be used for each data flow's packets. Section 3 describes the approach recommended to map IP-level traffic flows to IEEE traffic classes within the Layer 2 network. Section 4 describes the computation of Characterization Parameters by the layer 2 network. The remaining sections discuss some particular issues with the use of the RSVP/SBM signaling protocols, and describe the applicability of all of the above to different layer 2 network topologies.
このドキュメント内で、セクション2では、IEEE Layer-2クラウドに隣接するエンドシステムとルーターが、各データフローのパケットに使用するトラフィッククラスを学習する方法について説明します。セクション3では、IPレベルのトラフィックフローをレイヤー2ネットワーク内のIEEEトラフィッククラスにマッピングするように推奨されるアプローチについて説明します。セクション4では、レイヤー2ネットワークによる特性評価パラメーターの計算について説明します。残りのセクションでは、RSVP/SBMシグナル伝達プロトコルの使用に関するいくつかの特定の問題について説明し、上記のすべての異なるレイヤー2ネットワークトポロジへの適用性について説明します。
One model for supporting integrated services over specific link layers treats layer-2 devices very much as a special case of routers. In this model, switches and other devices along the data path make packet handling decisions based on the RSVP flow and filter specifications, and use these specifications to classify the corresponding data packets. The specifications could either be used directly, or could be used indirectly by mapping each RSVP session onto a layer-2 construct such as an ATM virtual circuit.
特定のリンクレイヤー上の統合サービスをサポートするための1つのモデルは、レイヤー2デバイスをルーターの特別なケースとして非常に処理します。このモデルでは、データパスに沿ったスイッチやその他のデバイスは、RSVPフローとフィルター仕様に基づいてパケット処理決定を行い、これらの仕様を使用して対応するデータパケットを分類します。仕様は、直接使用するか、各RSVPセッションをATM仮想回路などのレイヤー2コンストラクトにマッピングすることで間接的に使用できます。
This approach is inappropriate for use in the IEEE 802 environment. Filtering to the per-flow level becomes expensive with increasing switch speed; devices with such filtering capabilities are likely to have a very similar implementation complexity to IP routers, and may not make use of simpler mechanisms such as 802.1D user priority.
このアプローチは、IEEE 802環境での使用には不適切です。フローごとのレベルへのフィルタリングは、スイッチ速度が向上すると高価になります。このようなフィルタリング機能を備えたデバイスは、IPルーターと非常に類似した実装の複雑さを持つ可能性が高く、802.1dユーザーの優先度などのより単純なメカニズムを使用しない場合があります。
The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and this document use an "aggregated flow" approach based on use of layer-2 traffic classes. In this model, each arriving flow is assigned to one of the available classes for the duration of the flow and traverses the 802 cloud in this class. Traffic flows requiring similar service are grouped together into a single class, while the system's admission control and class selection rules ensure that the service requirements for flows in each of the classes are met. In many situations this is a viable intermediate point between no QoS control and full router-type integrated services. The approach can work effectively even with switches implementing only the simplest differential traffic classification capability specified in the 802.1D model. In the aggregated flow model, traffic arriving at the boundary of a layer-2 cloud is tagged by the boundary device (end host or border router) with an appropriate traffic class, represented as an 802.1D "user_priority" value. Two fundamental questions are "who determines the correspondence between IP-level traffic flows and link-level classes?" and "how is this correspondence conveyed to the boundary devices that must mark the data frames?"
IEEE 802 LANSフレームワーク[IS802Frame]およびこのドキュメントを介した統合サービスは、レイヤー2トラフィッククラスの使用に基づく「集計フロー」アプローチを使用します。このモデルでは、各到着フローは、フローの期間中に利用可能なクラスの1つに割り当てられ、このクラスの802クラウドを通過します。同様のサービスを必要とするトラフィックフローが単一のクラスにグループ化され、システムの入場制御およびクラスの選択ルールは、各クラスのフローのサービス要件が満たされることを保証します。多くの状況では、これはQoSコントロールなしとフルルータータイプの統合サービスの間の実行可能な中間点です。このアプローチは、802.1Dモデルで指定された最も単純な微分トラフィック分類機能のみを実装するスイッチでも効果的に機能します。集約されたフローモデルでは、レイヤー2クラウドの境界に到達するトラフィックは、802.1Dの「user_priority」値として表される適切なトラフィッククラスを使用して、境界デバイス（エンドホストまたはボーダールーター）によってタグ付けされます。2つの基本的な質問は、「IPレベルのトラフィックフローとリンクレベルのクラスの対応を誰が決定するのですか？」です。「この通信は、データフレームをマークする必要がある境界デバイスにどのように伝えられますか？」
One approach to answering these questions would be for the meanings of the classes to be universally defined. This document would then standardize the meanings of a set of classes; e.g., 1 = best effort, 2 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms peak delay target, etc. The meanings of these universally defined classes could then be encoded directly in end stations, and the flow-to-class mappings computed directly in these devices.
これらの質問に答えるための1つのアプローチは、クラスの意味が普遍的に定義されることです。このドキュメントは、一連のクラスの意味を標準化します。たとえば、1 =最善の努力、2 = 100 msピーク遅延ターゲット、3 = 10 msピーク遅延ターゲット、4 = 1ミリ秒のピーク遅延ターゲットなど。これらの普遍的に定義されたクラスの意味は、エンドステーションで直接エンコードできます。これらのデバイスで直接計算されたクラス間マッピング。
This universal definition approach would be simple to implement, but is too rigid to map the wide range of possible user requirements onto the limited number of available 802.1D classes. The model described in [IS802FRAME] uses a more flexible mapping: clients ask "the network" which user_priority traffic class to use for a given traffic flow, as categorized by its flow-spec and layer-2 endpoints. The network provides a value back to the requester that is appropriate considering the current network topology, load conditions, other admitted flows, etc. The task of configuring switches with this mapping (e.g., through network management, a switch-switch protocol or via some network-wide QoS-mapping directory service) is an order of magnitude less complex than performing the same function in end stations. Also, when new services (or other network reconfigurations) are added to such a network, the network elements will typically be the ones to be upgraded with new queuing algorithms etc. and can be provided with new mappings at this time.
このユニバーサル定義アプローチは実装が簡単ですが、利用可能な802.1Dクラスの限られた数に可能なユーザー要件の幅広い範囲をマッピングするにはあまりにも硬すぎます。[IS802Frame]で説明されているモデルは、より柔軟なマッピングを使用します。クライアントは、フロースペックとレイヤー2エンドポイントに分類されるように、「ネットワーク」を「ネットワーク」に尋ねます。ネットワークは、現在のネットワークトポロジ、負荷条件、その他の入院フローなどを考慮して適切なリクエスターに戻る値を提供します。ネットワーク全体のQoSマッピングディレクトリサービス）は、エンドステーションで同じ機能を実行するよりも複雑ではない桁です。また、新しいサービス（または他のネットワーク再構成）がそのようなネットワークに追加されると、ネットワーク要素は通常、新しいキューイングアルゴリズムなどでアップグレードされるものであり、現時点では新しいマッピングを提供できます。
In the current model it is assumed that all data packets of a flow are assigned to the same traffic class for the duration of the flow: the characteristics of the MAC service, as defined by Clause 6 of [802.1D], then ensure the ordering of the data packets of the flow between adjacent Layer 3 routers. This is usually desirable to avoid potential re-ordering problems as discussed in [IS802FRAME] and [CL]. Note that there are some scenarios where it might be desirable to send conforming data traffic in one traffic class and non-conforming traffic for the same flow in a different, lower traffic class: such a division into separate traffic classes is for future study. When a new session or "flow" requiring QoS support is created, a client must ask "the network" which traffic class (IEEE 802 user_priority) to use for a given traffic flow, so that it can label the packets of the flow as it places them into the network. A request/response protocol is needed between client and network to return this information. The request can be piggy-backed onto an admission control request and the response can be piggy-backed onto an admission control acknowledgment. This "one pass" assignment has the benefit of completing the admission control transaction in a timely way and reducing the exposure to changing conditions that could occur if clients cached the knowledge for extensive periods. A set of extensions to the RSVP protocol for communicating this information have been defined [SBM].
現在のモデルでは、フローのすべてのデータパケットは、[802.1d]条項6で定義されているように、フローの期間中、フローの期間中、同じトラフィッククラスに割り当てられていると想定されています。隣接するレイヤー3ルーター間のフローのデータパケットの。これは通常、[IS802Frame]および[CL]で説明されているように、潜在的な再注文の問題を回避するために望ましいです。1つのトラフィッククラスで適合データトラフィックを送信することが望ましいシナリオがあり、異なる低いトラフィッククラスで同じフローの不適合トラフィックを送信することが望ましい場合があることに注意してください。QoSサポートを必要とする新しいセッションまたは「フロー」が作成された場合、クライアントは、特定のトラフィックフローに使用するトラフィッククラス（IEEE 802ユーザー_priority）を「ネットワーク」に尋ねる必要があります。それらをネットワークに入れます。この情報を返すには、クライアントとネットワークの間でリクエスト/応答プロトコルが必要です。リクエストは、入場制御リクエストにピギーバックすることができ、応答はアミズミコントロールの謝辞に貯金箱に支援することができます。この「ワンパス」割り当てには、入場制御トランザクションをタイムリーに完了し、クライアントが広範な知識をキャッシュした場合に発生する可能性のある変化する条件への暴露を減らすという利点があります。この情報を通信するためのRSVPプロトコルの一連の拡張機能が定義されています[SBM]。
The network (i.e., the first network element encountered downstream from the client) must then answer the following questions:
ネットワーク（つまり、クライアントから下流に遭遇した最初のネットワーク要素）は、次の質問に答えなければなりません。
1. Which of the available traffic classes would be appropriate for this flow?
1. このフローに適した利用可能なトラフィッククラスのどれはどれですか？
In general, a newly arriving flow might be assigned to a number of classes. For example, if 10ms of delay is acceptable, the flow could potentially be assigned to either a 10ms delay class or a 1ms delay class. This packing problem is quite difficult to solve if the target parameters of the classes are allowed to change dynamically as flows arrive and depart. It is quite simple if the target parameters of each class is held fixed, and the class table is simply searched to find a class appropriate for the arriving flow. This document adopts the latter approach.
一般に、新しく到着するフローが多くのクラスに割り当てられる場合があります。たとえば、10msの遅延が許容される場合、フローを10ms遅延クラスまたは1MS遅延クラスのいずれかに割り当てる可能性があります。このパッキングの問題は、クラスのターゲットパラメーターが到着して出発するにつれて動的に変化することが許可されている場合、解決するのが非常に困難です。各クラスのターゲットパラメーターが固定されている場合、クラステーブルが単純に検索されて、到着フローに適したクラスを見つける場合は非常に簡単です。このドキュメントは、後者のアプローチを採用しています。
2. Of the appropriate traffic classes, which if any have enough capacity available to accept the new flow?
2. 適切なトラフィッククラスのうち、新しいフローを受け入れるのに十分な能力がある場合はどれですか？
This is the admission control problem. It is necessary to compare the level of traffic currently assigned to each class with the available level of network resources (bandwidth, buffers, etc), to ensure that adding the new flow to the class will not cause the class's performance to go below its target values. This problem is compounded because in a priority queuing system adding traffic to a higher-priority class can affect the performance of lower-priority classes. The admission control algorithm for a system using the default 802 priority behavior must be reasonably sophisticated to provide acceptable results.
これが入学制御の問題です。現在、各クラスに割り当てられているトラフィックのレベルを利用可能なネットワークリソース（帯域幅、バッファなど）と比較する必要があります。クラスに新しいフローを追加しても、クラスのパフォーマンスがターゲットを下回らないようにします。値。この問題は、優先順位のあるキューイングシステムで、より優先度の高いクラスにトラフィックを追加すると、より低優先度クラスのパフォーマンスに影響を与える可能性があるため、さらに悪化します。デフォルトの802優先順位の動作を使用したシステムの入場制御アルゴリズムは、許容可能な結果を提供するために合理的に洗練されている必要があります。
If an acceptable class is found, the network returns the chosen user_priority value to the client.
許容可能なクラスが見つかった場合、ネットワークは選択したユーザー_Priority値をクライアントに返します。
Note that the client may be an end station, a router at the edge of the layer 2 network, or a first switch acting as a proxy for a device that does not participate in these protocols for whatever reason. Note also that a device e.g., a server or router may choose to implement both the "client" as well as the "network" portion of this model so that it can select its own user_priority values. Such an implementation would generally be discouraged unless the device has a close tie-in with the network topology and resource allocation policies. It may, however, work acceptably in cases where there is known over-provisioning of resources.
クライアントは、エンドステーション、レイヤー2ネットワークの端にあるルーター、または何らかの理由でこれらのプロトコルに参加しないデバイスのプロキシとして機能する最初のスイッチであることに注意してください。また、デバイスは、サーバーまたはルーターなどのデバイスが、独自のuser_priority値を選択できるように、このモデルの「クライアント」と「ネットワーク」部分の両方を実装することを選択できることに注意してください。このような実装は、デバイスがネットワークトポロジとリソース割り当てポリシーと密接に結びついていない限り、一般に落胆するでしょう。ただし、リソースの過剰導入が既知の場合には、許容できるように機能する場合があります。
This section describes the method by which IP-level flows are mapped into appropriate IEEE user_priority classes. The IP-level services considered are Best Effort, Controlled Load, and Guaranteed Service.
このセクションでは、IPレベルのフローが適切なIEEE User_Priorityクラスにマッピングされる方法について説明します。考慮されるIPレベルのサービスは、最善の努力、制御された負荷、および保証されたサービスです。
The major issue is that admission control requests and application requirements are specified in terms of a multidimensional vector of parameters e.g., bandwidth, delay, jitter, service class. This multidimensional space must be mapped onto a set of traffic classes whose default behavior in L2 switches is unidimensional (i.e., strict priority default queuing). This priority queuing alone can provide only relative ordering between traffic classes. It can neither enforce an absolute (quantifiable) delay bound for a traffic class, nor can it discriminate amongst Int-Serv flows within the aggregate in a traffic class. Therefore, it cannot provide the absolute control of packet loss and delay required for individual Int-Serv flows.
主要な問題は、入場管理の要求とアプリケーションの要件が、帯域幅、遅延、ジッター、サービスクラスなどのパラメーターの多次元ベクトルの観点から指定されていることです。この多次元空間は、L2スイッチのデフォルトの動作が一次元（つまり、厳密な優先順位のデフォルトキューイング）であるトラフィッククラスのセットにマッピングする必要があります。この優先キューイングだけで、トラフィッククラス間で相対的な順序のみを提供できます。トラフィッククラスにバインドされている絶対的な（定量化可能な）遅延を実施することも、トラフィッククラス内の集合体内のINT-SERVフローを区別することもできません。したがって、個々のINT-Servフローに必要なパケット損失と遅延の絶対的な制御を提供することはできません。
To provide absolute control of loss and delay three things must occur:
損失の絶対的な制御を提供し、遅延を遅らせるには、3つのことが発生する必要があります。
(1) The amount of bandwidth available to the QoS-controlled flows must be known, and the number of flows admitted to the network (allowed to use the bandwidth) must be limited.
(1) QoS制御されたフローで利用可能な帯域幅の量を知っておく必要があり、ネットワークに認められているフローの数（帯域幅を使用することが許可）を制限する必要があります。
(2) A traffic scheduling mechanism is needed to give preferential service to flows with lower delay targets.
(2) 遅延ターゲットを低くするための優先サービスを提供するには、トラフィックスケジューリングメカニズムが必要です。
(3) Some mechanism must ensure that best-effort flows and QoS controlled flows that are exceeding their Tspecs do not damage the quality of service delivered to in-Tspec QoS controlled flows. This mechanism could be part of the traffic scheduler, or it could be a separate policing mechanism.
(3) 一部のメカニズムは、TSPECを超えているベストエフォルトフローとQoS制御フローが、QoS制御されたフローに提供されるサービスの品質を損なわないことを保証する必要があります。このメカニズムは、トラフィックスケジューラの一部である可能性があるか、別のポリシングメカニズムである可能性があります。
For IEEE 802 networks, the first function (admission control) is provided by a Subnet Bandwidth Manager, as discussed below. We use the link-level user_priority mechanism at each switch and bridge to implement the second function (preferential service to flows with lower delay targets). Because a simple priority scheduler cannot provide policing (function three), policing for IEEE networks is generally implemented at the edge of the network by a layer-3 device. When this policing is performed only at the edges of the network it is of necessity approximate. This issue is discussed further in [IS802FRAME].
IEEE 802ネットワークの場合、以下で説明するように、最初の関数（入学制御）がサブネットの帯域幅マネージャーによって提供されます。各スイッチとブリッジでリンクレベルのuser_priorityメカニズムを使用して、2番目の関数を実装します（遅延ターゲットを備えたフローへの優先サービス）。単純な優先度スケジューラはポリシング（機能3）を提供できないため、IEEEネットワークのポリシングは通常、レイヤー3デバイスによってネットワークの端に実装されます。このポリシングがネットワークの端でのみ実行される場合、必然的に概算します。この問題については、[IS802Frame]でさらに説明します。
As described above, it is the combination of priority-based scheduling and admission control that creates quantified delay bounds. Thus, any attempt to quantify the delay bounds expected by a given traffic class has to made in the context of the admission control elements. Section 6 of the framework [IS802FRAME] provides for two different models of admission control - centralized or distributed Bandwidth Allocators.
上記のように、定量化された遅延境界を作成するのは、優先度ベースのスケジューリングと入場制御の組み合わせです。したがって、特定のトラフィッククラスによって予想される遅延境界を定量化しようとする試みは、入場制御要素のコンテキストで行わなければなりません。フレームワーク[IS802Frame]のセクション6では、集中または分散帯域幅のアロケーターという2つの異なる入学制御モデルを提供します。
It is important to note that in this approach it is the admission control algorithm that determines which of the Int-Serv services is being offered. Given a set of priority classes with delay targets, a relatively simple admission control algorithm can place flows into classes so that the bandwidth and delay behavior experienced by each flow corresponds to the requirements of the Controlled-Load service, but cannot offer the higher assurance of the Guaranteed service. To offer the Guaranteed service, the admission control algorithm must be much more stringent in its allocation of resources, and must also compute the C and D error terms required of this service.
このアプローチでは、どのようなINT-SERVサービスが提供されているかを決定するのは、入場制御アルゴリズムであることに注意することが重要です。遅延ターゲットを備えた一連の優先クラスが与えられると、比較的単純な入場制御アルゴリズムがクラスに流れを配置して、各フローが経験する帯域幅と遅延動作が制御されたロードサービスの要件に対応するようにしますが、より高い保証を提供することはできません。保証されたサービス。保証されたサービスを提供するには、Andiming Control Algorithmはリソースの割り当てがはるかに厳しいものでなければならず、このサービスに必要なCおよびDエラー項も計算する必要があります。
A delay bound can only be realized at the admission control element itself so any delay numbers attached to a traffic class represent the delay that a single element can allow for. That element may represent a whole L2 domain or just a single L2 segment.
遅延境界は、入場制御要素自体でのみ実現することができるため、トラフィッククラスに添付された遅延数は、単一の要素が許すことができる遅延を表します。その要素は、L2ドメイン全体または単一のL2セグメント全体を表す場合があります。
With either admission control model, the delay bound has no scope outside of a L2 domain. The only requirement is that it be understood by all Bandwidth Allocators in the L2 domain and, for example, be exported as C and D terms to L3 devices implementing the Guaranteed Service. Thus, the end-to-end delay experienced by a flow can only be characterized by summing along the path using the usual RSVP mechanisms.
いずれかの入場制御モデルでは、遅延バウンドにはL2ドメインの外側の範囲がありません。唯一の要件は、L2ドメイン内のすべての帯域幅アロケーターによって理解され、たとえば、保証されたサービスを実装するL3デバイスにCおよびD項としてエクスポートされることです。したがって、流れが経験するエンドツーエンドの遅延は、通常のRSVPメカニズムを使用してパスに沿って合計することによってのみ特徴付けます。
Table 1 presents the default mapping from delay targets to IEEE 802.1 user_priority classes. However, these mappings must be viewed as defaults, and must be changeable.
表1は、遅延ターゲットからIEEE 802.1ユーザー_Priorityクラスへのデフォルトマッピングを示しています。ただし、これらのマッピングはデフォルトと見なされる必要があり、変更可能でなければなりません。
In order to simplify the task of changing mappings, this mapping table is held by *switches* (and routers if desired) but generally not by end-station hosts. It is a read-write table. The values proposed below are defaults and can be overridden by management control so long as all switches agree to some extent (the required level of agreement requires further analysis).
マッピングの変更のタスクを簡素化するために、このマッピングテーブルは *スイッチ *（および必要に応じてルーター）によって保持されますが、通常はエンドステーションホストではありません。読み取りワイトのテーブルです。以下に提案されている値はデフォルトであり、すべてのスイッチがある程度一致する限り、管理制御によってオーバーライドできます（必要なレベルの契約にはさらなる分析が必要です）。
In future networks this mapping table might be adjusted dynamically and without human intervention. It is possible that some form of network-wide lookup service could be implemented that serviced requests from clients e.g., traffic_class = getQoSbyName("H.323 video") and notified switches of what traffic categories they were likely to encounter and how to allocate those requests into traffic classes. Alternatively, the network's admission control mechanisms might directly adjust the mapping table to maximize the utilization of network resources. Such mechanisms are for further study.
将来のネットワークでは、このマッピングテーブルは、人間の介入なしに動的に調整される場合があります。クライアントからのサービスリクエストなど、何らかの形のネットワーク全体のルックアップサービスを実装できる可能性があります。たとえば、Traffic_class = getQosbyName（ "H.323ビデオ"）が遭遇する可能性があるトラフィックカテゴリとそれらを割り当てる方法を通知した可能性があります。トラフィッククラスへのリクエスト。あるいは、ネットワークの入場制御メカニズムは、マッピングテーブルを直接調整して、ネットワークリソースの利用を最大化する場合があります。このようなメカニズムは、さらなる研究のためのものです。
The delay bounds numbers proposed in Table 1 are for per-Bandwidth Allocator element delay targets and are derived from a subjective analysis of the needs of typical delay-sensitive applications e.g., voice, video. See Annex H of [802.1D] for further discussion of the selection of these values. Although these values appear to address the needs of current video and voice technology, it should be noted that there is no requirement to adhere to these values and no dependence of IEEE 802.1 on these values.
表1で提案されている遅延境界数は、帯域幅ごとのアロケーター要素遅延ターゲット用であり、典型的な遅延敏感なアプリケーションのニーズの主観的分析から派生しています。これらの値の選択についての詳細については、[802.1d]の付録Hを参照してください。これらの値は現在のビデオおよび音声技術のニーズに対応しているように見えますが、これらの値に順守するための要件はなく、これらの値にIEEE 802.1の依存性がないことに注意する必要があります。
user_priority Service
user_priorityサービス
0 Default, assumed to be Best Effort 1 reserved, "less than" Best Effort 2 reserved 3 reserved 4 Delay Sensitive, no bound 5 Delay Sensitive, 100ms bound 6 Delay Sensitive, 10ms bound 7 Network Control
0デフォルト、最良の努力であると想定1予約済み、「ベスト努力2未満2予約3予約4遅延センシティブ、バウンド5遅延センシティブ、100msバウンド6遅延センシティブ、10msバウンド7ネットワークコントロール
Table 1 - Example user_priority to service mappings
表1-サービスマッピングへのuser_priorityの例
Note: These mappings are believed to be useful defaults but further implementation and usage experience is required. The mappings may be refined in future editions of this document.
注：これらのマッピングは有用なデフォルトであると考えられていますが、さらなる実装と使用経験が必要です。マッピングは、このドキュメントの将来のエディションで洗練される場合があります。
With this example set of mappings, delay-sensitive, admission controlled traffic flows are mapped to user_priority values in ascending order of their delay bound requirement. Note that the bounds are targets only - see [IS802FRAME] for a discussion of the effects of other non-conformant flows on delay bounds of other flows. Only by applying admission control to higher-priority classes can any promises be made to lower-priority classes.
この例のマッピングセットを使用すると、遅延に敏感な入場制御トラフィックフローが、遅延境界要件の昇順でuser_priority値にマッピングされます。境界はターゲットのみであることに注意してください - 他のフローの遅延境界に対する他の不適合フローの影響についての議論については、[IS802Frame]を参照してください。より優先度の高いクラスに入学制御を適用することによってのみ、より低いクラスに約束することができます。
This set of mappings also leaves several classes as reserved for future definition.
この一連のマッピングは、将来の定義のために予約されているいくつかのクラスを残します。
Note: this mapping does not dictate what mechanisms or algorithms a network element (e.g., an Ethernet switch) must perform to implement these mappings: this is an implementation choice and does not matter so long as the requirements for the particular service model are met.
注：このマッピングは、ネットワーク要素（イーサネットスイッチなど）が実行するために実行する必要があるメカニズムまたはアルゴリズムを決定するものではありません。これらのマッピングを実装する必要があります。これは実装の選択であり、特定のサービスモデルの要件が満たされている限りは重要ではありません。
Note: these mappings apply primarily to networks constructed from devices that implement the priority-scheduling behavior defined as the default in 802.1D. Some devices may implement more complex scheduling behaviors not based only on priority. In that circumstance these mappings might still be used, but other, more specialized mappings may be more appropriate.
注：これらのマッピングは、主に802.1dのデフォルトとして定義された優先度スケジュール動作を実装するデバイスから構築されたネットワークに適用されます。一部のデバイスでは、優先度だけに基づいていないより複雑なスケジューリング動作を実装する場合があります。そのような状況では、これらのマッピングは依然として使用される可能性がありますが、他のより専門的なマッピングがより適切になる場合があります。
The recommendation of classes 4, 5 and 6 for Delay Sensitive, Admission Controlled flows is somewhat arbitrary; any classes with priorities greater than that assigned to Best Effort can be used. Those proposed here have the advantage that, for transit through 802.1D switches with only two-level strict priority queuing, all delay-sensitive traffic gets "high priority" treatment (the 802.1D default split is 0-3 and 4-7 for a device with 2 queues).
遅延に敏感で、入場制御されたフローのクラス4、5、および6の推奨は、ややarbitrary意的です。優先順位が最善の努力に割り当てられたクラスを持つクラスを使用することができます。ここで提案されているものには、2レベルの厳密な優先度キューイングのみの802.1Dスイッチを介したトランジットの場合、すべての遅延依存のトラフィックが「優先度が高い」処理を受けるという利点があります（802.1Dデフォルトの分割は0-3および4-7です。2つのキューがあるデバイス）。
The choice of the delay bound targets is tuned to an average expected application mix, and might be retuned by a network manager facing a widely different mix of user needs. The choice is potentially very significant: wise choice can lead to a much more efficient allocation of resources as well as greater (though still not very good) isolation between flows.
遅延バウンドターゲットの選択は、平均予想アプリケーションミックスに合わせて調整され、ユーザーニーズの大きく異なるミックスに直面しているネットワークマネージャーによって再度再生される可能性があります。選択は潜在的に非常に重要です。賢明な選択は、リソースのはるかに効率的な割り当てにつながる可能性があり、フロー間のより大きな（まだあまり良くありませんが）分離につながる可能性があります。
Placing Network Control traffic at class 7 is necessary to protect important traffic such as route updates and network management. Unfortunately, placing this traffic higher in the user_priority ordering causes it to have a direct effect on the ability of devices to provide assurances to QoS controlled application traffic. Therefore, an estimate of the amount of Network Control traffic must be made by any device that is performing admission control (e.g., SBMs). This would be in terms of the parameters that are normally taken into account by the admission control algorithm. This estimate should be used in the admission control decisions for the lower classes (the estimate is likely to be a configuration parameter of SBMs).
ルートの更新やネットワーク管理などの重要なトラフィックを保護するには、クラス7にネットワーク制御トラフィックを配置する必要があります。残念ながら、user_priorityの注文でこのトラフィックを高くすると、QoS制御されたアプリケーショントラフィックに保証を提供するデバイスの能力に直接影響を与えます。したがって、ネットワーク制御トラフィックの量の推定値は、入場制御を実行しているデバイス（SBMSなど）によって行う必要があります。これは、通常、入場制御アルゴリズムによって考慮されるパラメーターの観点からです。この見積もりは、下位クラスの入場管理決定で使用する必要があります（推定値はSBMSの構成パラメーターである可能性があります）。
A traffic class such as class 1 for "less than best effort" might be useful for devices that wish to dynamically "penalty tag" all of the data of flows that are presently exceeding their allocation or Tspec. This provides a way to isolate flows that are exceeding their service limits from flows that are not, to avoid reducing the QoS delivered to flows that are within their contract. Data from such tagged flows might also be preferentially discarded by an overloaded downstream device.
クラス1の「ベスト努力よりも低い」などのトラフィッククラスは、現在の割り当てまたはTSPECを超えているフローのすべてのデータを「ペナルティタグ」としたいデバイスに役立つ可能性があります。これは、契約内のフローに届けられたQoSを減らすことを避けるために、フローからのサービス制限を超えているフローを分離する方法を提供します。このようなタグ付きフローからのデータは、過負荷のダウンストリームデバイスによって優先的に破棄される場合があります。
A somewhat simpler approach would be to tag only the portion of a flow's packets that actually exceed the Tspec at any given instant as low priority. However, it is often considered to be a bad idea to treat flows in this way as it will likely cause significant re-ordering of the flow's packets, which is not desirable. Note that the default 802.1D treatment of user_priorities 1 and 2 is "less than" the default class 0.
やや簡単なアプローチは、優先度が低い瞬間にある任意の瞬間に実際にTSPECを超えるフローのパケットの部分のみにタグを付けることです。ただし、フローのパケットの大幅な再注文を引き起こす可能性が高いため、この方法でフローを治療することは悪い考えであると考えられますが、これは望ましくありません。user_priorities 1および2のデフォルトの802.1Dトリートメントは、「デフォルトのクラス0よりも「少ない」であることに注意してください。
The integrated service model requires that each network element that supports integrated services compute and make available certain "characterization parameters" describing the element's behavior. These parameters may be either generally applicable or specific to a particular QoS control service. These parameters may be computed by calculation, measurement, or estimation. When a network element cannot compute its own parameters (for example, a simple link), we assume that the device sending onto or receiving data from the link will compute the link's parameters as well as it's own. The accuracy of calculation of these parameters may not be very critical; in some cases loose estimates are all that is required to provide a useful service. This is important in the IEEE 802 case, where it will be virtually impossible to compute parameters accurately for certain topologies and switch technologies. Indeed, it is an assumption of the use of this model by relatively simple switches (see [IS802FRAME] for a discussion of the different types of switch functionality that might be expected) that they merely provide values to describe the device and admit flows conservatively. The discussion below presents a general outline for the computation of these parameters, and points out some cases where the parameters must be computed accurately. Further specification of how to export these parameters is for further study.
統合されたサービスモデルでは、統合サービスをサポートする各ネットワーク要素が、要素の動作を説明する特定の「特性評価パラメーター」を使用できるようにする必要があります。これらのパラメーターは、一般的に適用可能または特定のQoS制御サービスに固有の場合があります。これらのパラメーターは、計算、測定、または推定によって計算される場合があります。ネットワーク要素が独自のパラメーターを計算できない場合（たとえば、単純なリンク）、リンクからデータを送信または受信するデバイスがリンクのパラメーターと独自のパラメーターを計算すると仮定します。これらのパラメーターの計算の精度はそれほど重要ではないかもしれません。場合によっては、有用なサービスを提供するために必要なすべてがゆるい推定値だけです。これは、IEEE 802のケースで重要です。この場合、特定のトポロジとスイッチテクノロジーに対してパラメーターを正確に計算することが事実上不可能です。実際、このモデルの使用は、デバイスを記述し、控えめにフローを認める値を提供するだけであるという単に、予想されるさまざまなタイプのスイッチ機能の議論については、比較的単純なスイッチ（[IS802Frame]を参照）で仮定されています。以下の議論は、これらのパラメーターの計算の一般的な概要を示し、パラメーターを正確に計算する必要がある場合があります。これらのパラメーターをエクスポートする方法のさらなる仕様は、さらなる研究のためです。
There are some general parameters [GENCHAR] that a device will need to use and/or supply for all service types:
すべてのサービスタイプにデバイスが使用および/または供給する必要があるという一般的なパラメーター[GenChar]がいくつかあります。
* Ingress link
* イングレスリンク
* Egress links and their MTUs, framing overheads and minimum packet sizes (see media-specific information presented above).
* 出力リンクとそのMTU、フレーミングオーバーヘッドと最小パケットサイズ（上記のメディア固有の情報を参照）。
* Available path bandwidth: updated hop-by-hop by any device along the path of the flow.
* 使用可能なパス帯域幅：フローのパスに沿った任意のデバイスによってホップごとに更新されました。
* Minimum latency
* 最小レイテンシ
Of these parameters, the MTU and minimum packet size information must be reported accurately. Also, the "break bits" must be set correctly, both the overall bit that indicates the existence of QoS control support and the individual bits that specify support for a particular scheduling service. The available bandwidth should be reported as accurately as possible, but very loose estimates are acceptable. The minimum latency parameter should be determined and reported as accurately as possible if the element offers Guaranteed service, but may be loosely estimated or reported as zero if the element offers only Controlled-Load service.
これらのパラメーターのうち、MTUと最小パケットサイズの情報を正確に報告する必要があります。また、「ブレークビット」は正しく設定する必要があります。QoS制御サポートの存在を示す全体的なビットと、特定のスケジューリングサービスのサポートを指定する個々のビットの両方です。利用可能な帯域幅は可能な限り正確に報告する必要がありますが、非常に緩い推定値は受け入れられます。要素が保証されたサービスを提供する場合、最小レイテンシパラメーターはできるだけ正確に報告されますが、要素が制御されたロードサービスのみを提供する場合、ゼロとして緩やかに推定または報告される場合があります。
A network element supporting the Guaranteed Service [GS] must be able to determine the following parameters:
保証されたサービス[GS]をサポートするネットワーク要素は、次のパラメーターを決定できる必要があります。
* Constant delay bound through this device (in addition to any value provided by "minimum latency" above) and up to the receiver at the next network element for the packets of this flow if it were to be admitted. This includes any access latency bound to the outgoing link as well as propagation delay across that link. This value is advertised as the 'C' parameter of the Guaranteed Service.
* このデバイスにバインドされた一定の遅延（上記の「最小レイテンシ」によって提供される値に加えて）と、このフローのパケットの次のネットワーク要素で認められた場合にレシーバーまで。これには、発信リンクにバインドされたアクセスレイテンシと、そのリンク全体の伝播遅延が含まれます。この値は、保証されたサービスの「C」パラメーターとして宣伝されています。
* Rate-proportional delay bound through this device and up to the receiver at the next network element for the packets of this flow if it were to be admitted. This value is advertised as the 'D' parameter of the Guaranteed Service.
* このデバイスを介して、このフローのパケットの次のネットワーク要素のレシーバーに至るまで、レート比例遅延が認められた場合に至ります。この値は、保証されたサービスの「D」パラメーターとして宣伝されています。
* Receive resources that would need to be associated with this flow (e.g., buffering, bandwidth) if it were to be admitted and not suffer packet loss if it kept within its supplied Tspec/Rspec. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device.
* このフローに関連付けられる必要があるリソース（例：バッファリング、帯域幅）が認められ、供給されたTSPEC/RSPEC内に保管されていた場合にパケット損失を被らない場合は、リソースを受け取ります。これらの値は、入場制御アルゴリズムによって使用され、デバイスによって新しいフローを受け入れることができるかどうかを決定します。
* Transmit resources that would need to be associated with this flow (e.g., buffering, bandwidth, constant- and rate-proportional delay bounds) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device.
* このフローに関連付けられる必要があるリソース（例：バッファリング、帯域幅、一定および速度と比例の遅延境界）が認められる場合は送信します。これらの値は、入場制御アルゴリズムによって使用され、デバイスによって新しいフローを受け入れることができるかどうかを決定します。
The exported characterization parameters for this service should be reported as accurately as possible. If estimations or approximations are used, they should err in whatever direction causes the user to receive better performance than requested. For example, the C and D error terms should overestimate delay, rather than underestimate it.
このサービスのエクスポートされた特性評価パラメーターは、可能な限り正確に報告する必要があります。推定または近似を使用する場合、ユーザーが要求よりも優れたパフォーマンスを受信する方向に誤りする必要があります。たとえば、CおよびDエラー項は、遅延を過小評価するのではなく、遅延を過大評価する必要があります。
A network element implementing the Controlled Load service [CL] must be able to determine the following:
制御されたロードサービスを実装するネットワーク要素[CL]は、以下を決定できる必要があります。
* Receive resources that would need to be associated with this flow (e.g., buffering) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device.
* 認められる場合は、このフローに関連付けられる必要があるリソース（バッファリングなど）を受け取ります。これらの値は、入場制御アルゴリズムによって使用され、デバイスによって新しいフローを受け入れることができるかどうかを決定します。
* Transmit resources that would need to be associated with this flow (e.g., buffering) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device.
* 認められる場合は、このフローに関連付ける必要があるリソース（バッファリングなど）を送信します。これらの値は、入場制御アルゴリズムによって使用され、デバイスによって新しいフローを受け入れることができるかどうかを決定します。
The Controlled Load service does not export any service-specific characterization parameters. Internal resource allocation estimates should ensure that the service quality remains high when considering the statistical aggregation of Controlled Load flows into 802 traffic classes.
制御されたロードサービスは、サービス固有の特性評価パラメーターをエクスポートしません。内部リソース割り当ての推定値は、制御された負荷フローの統計的集約が802トラフィッククラスへの統計的集約を考慮すると、サービスの品質が高いことを保証する必要があります。
For a network element that implements only best effort service there are no explicit parameters that need to be characterized. Note that an integrated services aware network element that implements only best effort service will set the "break bit" described in [RSVPINTSERV].
最良の努力のみを実装するネットワーク要素の場合、特徴づける必要がある明示的なパラメーターはありません。[rsvpintserv]に記載されている「ブレークビット」を設定する統合されたサービスの統合的なサービスのネットワーク要素が認識されることに注意してください。
Where reservations that use the SBM protocol's TCLASS object [SBM] need to be merged, an algorithm needs to be defined that is consistent with the mappings to individual user_priority values in use in the Layer-2 cloud. A merged reservation must receive at least as good a service as the best of the component reservations.
SBMプロトコルのTCLASSオブジェクト[SBM]を使用する予約をマージする必要がある場合、レイヤー2クラウドで使用する個々のuser_priority値へのマッピングと一致するアルゴリズムを定義する必要があります。マージされた予約は、少なくともコンポーネントの予約と同じくらい優れたサービスを受け取る必要があります。
There is no single merging rule that can prevent all of the following side-effects:
次のすべての副作用を防ぐことができる単一のマージルールはありません。
* If a merger were to demote the existing branch of the flow into a higher-delay traffic class then this is a denial of service to the existing flow which would likely receive worse service than before.
* 合併により、フローの既存のブランチをより高い遅延トラフィッククラスに降格させた場合、これは既存のフローのサービスの拒否であり、以前よりも悪いサービスを受ける可能性があります。
* If a merger were to promote the existing branch of the flow into a new, lower-delay, traffic class, this might then suffer either admission control failures or may cost more in some sense than the already-admitted flow. This can also be considered as a denial-of-service attack.
* 合併により、フローの既存のブランチを新しい低遅延の交通クラスに促進する場合、これは入場制御の障害のいずれかに陥る可能性があります。これは、サービス拒否攻撃と見なすこともできます。
* Promotion of the new branch may lead to rejection of the request because it has been re-assigned to a traffic class that has not enough resources to accommodate it.
* 新しい支店の昇進は、リクエストを収容するのに十分なリソースがないトラフィッククラスに再割り当てされているため、リクエストの拒否につながる可能性があります。
Therefore, such a merger is declared to be illegal and the usual SBM admission control failure rules are applied. Traffic class selection is performed based on the TSpec information. When the first RESV for a flow arrives, a traffic class is chosen based on the request, an SBM TCLASS object is inserted into the message and admission control for that traffic class is done by the SBM. Reservation succeeds or fails as usual.
したがって、このような合併は違法であると宣言されており、通常のSBM入学制御の失敗規則が適用されます。トラフィッククラスの選択は、TSPEC情報に基づいて実行されます。フローの最初のRESVが到着すると、リクエストに基づいてトラフィッククラスが選択され、SBM TCLASSオブジェクトがメッセージに挿入され、トラフィッククラスがSBMによって行われます。予約は通常どおりに成功または失敗します。
When a second RESV for the same flow arrives at a different egress point of the Layer-2 cloud the process starts to repeat. Eventually the SBM-augmented RESV may hit a switch with an existing reservation in place for the flow i.e., an L2 branch point for the flow. If so, the traffic class chosen for the second reservation is checked against the first. If they are the same, the RESV requests are merged and passed on towards the sender(s).
同じフローの2番目のRESVがレイヤー-2クラウドの異なる出口点に到着すると、プロセスが繰り返され始めます。最終的には、SBMが介在したRESVは、フローのために既存の予約を設置したスイッチ、つまりフローのL2ブランチポイントを押している可能性があります。その場合、2回目の予約に選択されたトラフィッククラスは、最初のものに対してチェックされます。それらが同じ場合、RESVリクエストはマージされ、送信者に渡されます。
If the second TCLASS would have been different, an RSVP/SBM ResvErr error is returned to the Layer-3 device that launched the second RESV request into the Layer-2 cloud. This device will then pass on the ResvErr to the original requester according to RSVP rules. Detailed processing rules are specified in [SBM].
2番目のTCLASSが異なっていた場合、RSVP/SBM RESVERRエラーがレイヤー-3デバイスに戻り、2番目のRESV要求をレイヤー2クラウドに起動しました。このデバイスは、RSVPルールに従ってRESVERRを元の要求者に渡します。詳細な処理ルールは[SBM]で指定されています。
Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D-1998) need to inter-operate with routers and layer-3 switches. Wide deployment of such 802.1D-1998 switches will occur in a number of roles in the network: "desktop switches" provide dedicated 10/100 Mbps links to end stations and high speed core switches often act as central campus switching points for layer-3 devices. Layer-2 devices will have to operate in all of the following scenarios:
レイヤー2のみの標準を使用したスイッチ（例：802.1D-1990、802.1d-1998）は、ルーターとレイヤー3スイッチを操作する必要があります。このような802.1-1998スイッチの幅広い展開は、ネットワーク内の多くの役割で発生します。「デスクトップスイッチ」は、エンドステーションへの専用の10/100 Mbpsリンクを提供し、高速コアスイッチはレイヤー-3のセントラルキャンパススイッチングポイントとして機能することがよくありますデバイス。レイヤー2デバイスは、次のすべてのシナリオで動作する必要があります。
* every device along a network path is layer-3 capable and intrusive into the full data stream
* ネットワークパスに沿ったすべてのデバイスはレイヤー-3能力があり、完全なデータストリームに侵入します
* only the edge devices are pure layer-2
* エッジデバイスのみが純粋なレイヤー2です
* every alternate device lacks layer-3 functionality
* すべての代替デバイスには、レイヤー-3機能がありません
* most devices lack layer-3 functionality except for some key control points such as router firewalls, for example.
* ほとんどのデバイスは、たとえばルーターファイアウォールなどのいくつかの重要な制御ポイントを除き、レイヤー-3機能を欠いています。
Where int-serv flows pass through equipment which does not support Integrated Services or 802.1D traffic management and which places all packets through the same queuing and overload-dropping paths, it is obvious that some of a flow's desired service parameters become more difficult to support. In particular, the two integrated service classes studied here, Controlled Load and Guaranteed Service, both assume that flows will be policed and kept "insulated" from misbehaving other flows or from best effort traffic during their passage through the network. This cannot be done within an IEEE 802 network using devices with the default user_priority function; in this case policing must be approximated at the network edges.
Int-Servフローが統合サービスや802.1Dトラフィック管理をサポートせず、すべてのパケットを同じキューイングとオーバーロードドロップパスに配置する機器を通過する場合、フローの望ましいサービスパラメーターの一部がサポートがより困難になることは明らかです。特に、ここで調査された2つの統合されたサービスクラスは、荷重と保証されたサービスを制御します。どちらも、フローがポリシングされ、ネットワークを通過したときに他のフローを誤動作するか、最適なトラフィックから「断熱」していると仮定します。これは、デフォルトのuser_priority関数を備えたデバイスを使用して、IEEE 802ネットワーク内で実行することはできません。この場合、ネットワークのエッジでポリシングを近似する必要があります。
In addition, in order to provide a Guaranteed Service, *all* switching elements along the path must participate in special treatment for packets in such flows: where there is a "break" in guaranteed service, all bets are off. Thus, a network path that includes even a single switch transmitting onto a shared or half-duplex LAN segment is unlikely to be able to provide a very good approximation to Guaranteed Service. For Controlled Load service, the requirements on the switches and link types are less stringent although it is still necessary to provide differential queuing and buffering in switches for CL flows over best effort in order to approximate CL service. Note that users receive indication of such breaks in the path through the "break bits" described in y [RSVPINTSERV]. These bits must be correctly set when IEEE 802 devices that cannot provide a specific service exist in a network.
さらに、保証されたサービスを提供するために、パスに沿った *すべて *スイッチング要素は、そのようなフローのパケットの特別な処理に参加する必要があります。保証されたサービスに「ブレーク」がある場合、すべての賭けはオフです。したがって、共有または半分二重LANセグメントに送信する単一のスイッチさえ含むネットワークパスは、保証されたサービスに非常に良い近似を提供できる可能性は低いです。制御された負荷サービスの場合、スイッチとリンクのタイプの要件はあまり厳しくありませんが、CLサービスを近似するために最善の努力を伴うCLフローのスイッチでのバッファリングとバッファリングを提供する必要があります。ユーザーは、y [rsvpintserv]に記載されている「ブレークビット」を通るパスでのこのような休憩の兆候を受け取ることに注意してください。これらのビットは、ネットワークに特定のサービスを提供できないIEEE 802デバイスの場合、正しく設定する必要があります。
Other approaches might be to pass more information between switches about the capabilities of their neighbours and to route around non-QoS-capable switches: such methods are for further study. And of course the easiest solution of all is to upgrade links and switches to higher capacities.
他のアプローチは、隣人の機能に関するスイッチ間でより多くの情報を渡し、非QOS対応スイッチの周りにルーティングすることです。そのような方法は、さらなる研究のためのものです。そしてもちろん、すべての最も簡単な解決策は、リンクとより高い容量に切り替えることです。
[802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
[802.1D-Orig]「Mac Bridges」、ISO/IEC 10038、ANSI/IEEE STD 802.1D-1993
[802.1D] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3:1998"
[802.1d]「情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ：改訂。これはISO/IEC 10038：1993、802.11の改訂です。J-1992および802.6k-1992。p802.11c、p802.1p、p802.12eが組み込まれています。ISO/IEC 15802-3：1998 "
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[Intserv] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[CL] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[Cl] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[GS] Schenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212 September 1997.
[GS] Schenker、S.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212 1997年9月。
[802.1Q] ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998.
[802.1Q] ANSI/IEEE Standard 802.1Q-1998、「ローカルおよび大都市圏ネットワークのIEEE標準：仮想ブリッジ型ローカルエリアネットワーク」、1998年。
[GENCHAR] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[Genchar] Shenker、S。、およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[IS802FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and M. Seaman, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", RFC 2816, May 2000.
[IS802Frame] Ghanwani、A.、Pace、W.、Srinivasan、V.、Smith、A。and M. Seaman、「共有および切り替えのLANテクノロジーを介して統合サービスを提供するためのフレームワーク」、RFC 2816、2000年5月。
[SBM] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for Admission Control over IEEE 802-style Networks", RFC 2814, May 2000.
[SBM] Yavatkar、R.、Hoffman、D.、Bernet、Y.、Baker、F。and M. Speer、 "SBM（Subnet Bandwidth Manager）：IEEE 802スタイルネットワークの入場制御のためのプロトコル"、RFC 28144、2000年5月。
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RSVPINTSERV] WROCLAWSKI、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[プロセス] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
Any use of QoS requires examination of security considerations because it leaves the possibility open for denial of service or theft of service attacks. This document introduces no new security issues on top of those discussed in the companion ISSLL documents [IS802FRAME] and [SBM]. Any use of these service mappings assumes that all requests for service are authenticated appropriately.
QoSを使用するには、サービスの拒否またはサービス攻撃の盗難に対して可能性を開いたままにするため、セキュリティ上の考慮事項を調べる必要があります。このドキュメントでは、コンパニオンISSLLドキュメント[IS802Frame]および[SBM]で説明されているものの上に、新しいセキュリティの問題を紹介しません。これらのサービスマッピングの使用は、すべてのサービス要求が適切に認証されていることを前提としています。
This document draws heavily on the work of the ISSLL WG of the IETF and the IEEE P802.1 Interworking Task Group.
このドキュメントは、IETFおよびIEEE P802.1インターワーキングタスクグループのISSLL WGの作業に大きく描かれています。
Mick Seaman Telseon 480 S. California Ave Palo Alto, CA 94306 USA
Mick Seaman Telseon 480 S. California Ave Palo Alto、CA 94306 USA
Email: mick@telseon.com
Andrew Smith Extreme Networks 3585 Monroe St. Santa Clara, CA 95051 USA
アンドリュースミスエクストリームネットワーク3585モンローセントサンタクララ、カリフォルニア95051 USA
Phone: +1 408 579 2821
EMail: andrew@extremenetworks.com
Eric Crawley Unisphere Solutions 5 Carlisle Rd. Westford, MA 01886
Eric Crawley Unisphere Solutions 5 Carlisle Rd。マサチューセッツ州ウェストフォード01886
Phone: +1 978 692 1999
Email: esc@unispheresolutions.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 USA
コンピューターサイエンスのためのJohn Wroclawski MIT Laboratory 545 Technology Sq。マサチューセッツ州ケンブリッジ02139 USA
Phone: +1 617 253 7885
EMail: jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。