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
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.
著作権（C）インターネット協会（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.1D MACブリッジ（スイッチ）によって相互接続されてもよいIEEE 802ネットワークセグメントから構築されたLAN上IETF統合サービスのマッピングを記述する。これは、固有の関連IEEE 802技術の能力と、特に、802.1D-1998スイッチでのキューイング機能を使用して制御負荷および保証サービスをサポートするためのパラメータのマッピングを説明しています。
These mappings are one component of the Integrated Services over IEEE 802 LANs framework.
これらのマッピングは、IEEE 802のLANのフレームワークの上に統合サービスの一つの成分です。
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インターワーキングタスクグループは、基本的なMACサービスへの機能拡張のセットを開発しました（別称、「LANの切り替え」）ブリッジローカルエリアネットワークで提供。オリジナルのIEEE MACブリッジ標準の補足として、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]の近似をサポートすることを可能にします。このドキュメントでは、IEEE 802.1D準拠のネットワークパラメータにサービスクラスとIETFモデルのパラメータをマッピングするための方法を説明します。仲間ドキュメント[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
このドキュメント内では、第2節では、エンドシステムとルータがIEEEレイヤ2クラウドは、各データフローのパケットに使用すべきか、トラフィッククラスを学習国境する方法を説明します。第3節では、IPレベルのトラフィックをマップするために推奨されるアプローチはに流れを説明します
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トラフィッククラス。セクション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フローおよびフィルタ仕様に基づいてパケット処理の決定を行い、対応するデータパケットを分類するためにこれらの仕様を使用します。仕様は、直接使用することができるか、そのようなATM仮想回路としてレイヤ2構築物上に各RSVPセッションをマッピングすることによって間接的に使用することができます。
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のLANのフレームワーク上に[IS802FRAME]この文書は、レイヤ2トラフィッククラスの使用に基づく「集約フロー」アプローチを使用しています。このモデルでは、各到着フローは、フローの持続時間のために利用可能なクラスの1つに割り当てられ、このクラスで802クラウドを横断します。トラフィックは、システムのアドミッション制御及びクラス選択ルールはクラスのそれぞれにおけるフローのサービス要件が満たされていることを確認しながら、単一のクラスにグループ化されている同様のサービスを必要と流れます。多くの状況では、これはありませんQoS制御とフルルータ型統合サービス間の実行可能な中間点です。アプローチも、802.1Dモデルに指定された唯一の最も簡単な差動トラフィック分類機能を実装するスイッチで効果的に働くことができます。集約フローモデルでは、雲は適切なトラフィッククラスとの境界デバイス（エンドホスト又は境界ルータ）によってタグ付けされたレイヤ2の境界に到達するトラフィックは、802.1D「user_priority」値として表されます。二つの基本的な質問には、「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 =ベストエフォート、2 = 100 MSピーク遅延ターゲットなど3 = 10ミリ秒のピーク遅延ターゲット、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エンドポイントによって分類されるようuser_priorityトラフィッククラスは、所与のトラフィックフローに使用する「ネットワーク」を尋ねます。ネットワークは、ネットワーク管理、切替スイッチプロトコルまたはいくつかのビアを介して、など現在のネットワークトポロジ、負荷条件、他の入院フロー、このマッピング（例えばと共にスイッチを構成するタスクを考慮して適切である要求元に戻す値を提供しますネットワーク全体の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によって定義されるように、MACサービスの特性は、順序を保証隣接するレイヤ3つのルータの間の流れのデータパケット。これは、[IS802FRAME]と[CL]で説明したように潜在的な並べ替えの問題を回避することが通常望ましいです。異なる、低トラフィッククラスに同じ流れのための1つのトラフィッククラスと非適合トラフィックに準拠したデータトラフィックを送信することが望ましいかもしれないいくつかのシナリオがあることに注意してください：別のトラフィッククラスに、このような部門では、将来の検討課題です。 QoSサポートを必要とする新しいセッションや「流れ」が作成されると、クライアントは、それはそれとして、フローのパケットにラベルを付けることができるように、与えられたトラフィックフローに使用するトラフィッククラス（IEEE 802 user_priority）「ネットワーク」を依頼する必要がありますネットワークに配置します。要求/応答プロトコルは、この情報を返すために、クライアントとネットワークの間で必要とされています。要求がピギーバック受付制御要求および応答へのアドミッション制御応答にピギーバックすることができることができます。この「ワンパス」の割り当ては、タイムリーな方法でアドミッション制御トランザクションを完了すると、クライアントは広範な期間についての知識をキャッシュされた場合に発生する可能性がある状況の変化への暴露を低減するという利点があります。この情報を通信するためのRSVPプロトコルの拡張セットは[SBM]を定義されています。
The network (i.e., the first network element encountered downstream from the client) must then answer the following questions:
ネットワーク（クライアントから下流に遭遇した、すなわち、第1のネットワーク要素）は、次の質問に答える必要があります。
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.
一般的には、新しく到着の流れは、クラスの数に割り当てられることがあります。遅延10ミリ秒が許容される場合、例えば、フローは、潜在的に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.
許容可能なクラスが見つかった場合、ネットワークは、クライアントに選ばれたuser_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を超えているフローは、サービスの品質はインの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]アドミッション制御の2つの異なるモデルを提供するフレームワークのセクション6。
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のサービスが決定アドミッション制御アルゴリズムがあることに注意することが重要です。遅延目標と優先順位クラスのセットを考えると、比較的単純なアドミッション制御アルゴリズムを置くことができ、各フローが経験した帯域幅と遅延の動作が制御され、ロードサービスの要件に対応するが、高い保証を提供することができないようなクラスに流入保証サービス。保証サービスを提供するには、アドミッション制御アルゴリズムは、はるかに厳しい資源の配分である必要があり、また、このサービスに必要な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は、802.1 user_priorityクラスをIEEEする遅延ターゲットからのデフォルトのマッピングを示します。しかし、これらのマッピングがデフォルトとして表示されなければならない、と変更する必要があります。
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.
将来のネットワークでは、このマッピングテーブルは動的に調整し、人間の介入なしにされる可能性があります。 （「H.323ビデオ」）例えば、traffic_class = getQoSbyNameクライアントからの要求にサービスを提供し、ネットワーク全体の検索サービスのいくつかのフォームが実装される可能性があり、トラフィックの分類は、彼らが発生する可能性が何であったかの通知を受け、スイッチとどのようにそれらを割り当てることトラフィッククラスに要求します。また、ネットワークのアドミッション制御メカニズムは、直接、ネットワークリソースの利用率を最大化するために、マッピングテーブルを調整するかもしれません。このようなメカニズムは、今後の検討課題です。
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
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の推薦は幾分任意です。ベストエフォートに割り当てられているよりも高い優先順位を持つ任意のクラスを使用することができます。ここで提案されているものは、802.1Dを通る通過は2つだけレベルの完全優先キューイングと切り替えのために、すべての遅延に敏感なトラフィックは、「優先度の高い」治療（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「未満」であることに注意してください。
4. Computation of integrated services characterization parameters by IEEE 802 devices
IEEE 802デバイス4.計算統合サービスの特性パラメータ
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).
同じ流れのための第二RESVは、レイヤ2クラウドの異なる出口ポイントに到着するとプロセスが繰り返され始めます。最終的にSBM-増強RESVは、フローのための場所の既存の予約と流れのために、すなわち、L2の分岐点にスイッチを打つことができます。その場合、第二の予約のために選ばれたトラフィッククラスは、最初に照合されます。それらが同じである場合は、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].
二TCLASSが異なっていたならば、RSVP / SBM ResvErrエラーは、レイヤ2クラウドに二RESV要求を開始したレイヤ3デバイスに返されます。このデバイスは、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.1D-1998スイッチの幅広い展開がネットワーク内のロールの数に発生します。「デスクトップスイッチ」は、しばしば層-3の中央キャンパススイッチングポイントとして機能スイッチ局と高速コアを終了するための専用の10/100 Mbpsのリンクを提供しますデバイス。レイヤ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ブリッジ"、ISO / IEC 10038、ANSI / IEEE規格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部：1993、802.1：メディアアクセス制御（MAC）はブリッジ：これは、ISO / IEC 10038の改訂版改訂であります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.
[イントサーブ]ブレーデン、R.、クラーク、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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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]シェンカー、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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規格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.、ペース、W.、スリニバサン、V.、スミス、A.とM.シーマン、 "共有にわたり統合サービスを提供するためのフレームワークと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.、ホフマン、D.、Bernet、Y.、ベイカー、F.およびM.シュペーア、 "SBM（サブネット帯域幅マネージャー）：IEEE 802スタイルネットワーク上でアドミッション制御のためのプロトコル"、RFC 2814 、2000年5月。
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RSVPINTSERV] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[プロセス]ブラドナーの、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
ミック・シーマンTelseon 480 S.カリフォルニアアベニューパロアルト、CA 94306 USA
Email: mick@telseon.com
メール：mick@telseon.com
Andrew Smith Extreme Networks 3585 Monroe St. Santa Clara, CA 95051 USA
アンドリュー・スミスエクストリームネットワークス3585・モンローセントサンタクララ、CA 95051 USA
Phone: +1 408 579 2821 EMail: andrew@extremenetworks.com
電話：+1 408 579 2821 Eメール：andrew@extremenetworks.com
Eric Crawley Unisphere Solutions 5 Carlisle Rd. Westford, MA 01886
エリッククローリーUnisphereのソリューション5カーライルRdを。ウェストフォード、MA 01886
Phone: +1 978 692 1999 Email: esc@unispheresolutions.com
電話：+1 978 692 1999 Eメール：esc@unispheresolutions.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 USA
コンピュータサイエンス545平方技術のためのジョンWroclawski MIT研究所。ケンブリッジ、MA 02139 USA
Phone: +1 617 253 7885 EMail: jtw@lcs.mit.edu
電話：+1 617 253 7885 Eメール：jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。