Network Working Group J. Babiarz
Request for Comments: 4594 K. Chan
Category: Informational Nortel Networks
F. Baker
Cisco Systems
August 2006
Configuration Guidelines for DiffServ Service Classes
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
この文書では、Diffservので構成されたサービスクラスについて説明し、それらがどのように使用できるかとDiffServコードポイント（DSCPを）、交通コンディショナー、ホップ単位動作（のPHB）、およびアクティブキュー管理（AQM）メカニズムを使用してそれらを構築する方法を推奨しています。そこ特定のDSCP、トラフィックコンディショナー、のPHB、およびAQMは、特定のサービスクラスのために使用することは固有の要件はありませんが、政策としての相互運用性のために、一貫して適用することが有用です。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Expected Use in the Network ................................4
1.3. Service Class Definition ...................................5
1.4. Key Differentiated Services Concepts .......................5
1.4.1. Queuing .............................................6
1.4.1.1. Priority Queuing ...........................6
1.4.1.2. Rate Queuing ...............................6
1.4.2. Active Queue Management .............................7
1.4.3. Traffic Conditioning ................................7
1.4.4. Differentiated Services Code Point (DSCP) ...........8
1.4.5. Per-Hop Behavior (PHB) ..............................8
1.5. Key Service Concepts .......................................8
1.5.1. Default Forwarding (DF) .............................9
1.5.2. Assured Forwarding (AF) .............................9
1.5.3. Expedited Forwarding (EF) ..........................10
1.5.4. Class Selector (CS) ................................10
1.5.5. Admission Control ..................................11
2. Service Differentiation ........................................11
2.1. Service Classes ...........................................12
2.2. Categorization of User Service Classes ....................13
2.3. Service Class Characteristics .............................16
2.4. Deployment Scenarios ......................................21
2.4.1. Example 1 ..........................................21
2.4.2. Example 2 ..........................................23
2.4.3. Example 3 ..........................................25
3. Network Control Traffic ........................................27
3.1. Current Practice in the Internet ..........................27
3.2. Network Control Service Class .............................27
3.3. OAM Service Class .........................................29
4. User Traffic ...................................................30
4.1. Telephony Service Class ...................................31
4.2. Signaling Service Class ...................................33
4.3. Multimedia Conferencing Service Class .....................35
4.4. Real-Time Interactive Service Class .......................37
4.5. Multimedia Streaming Service Class ........................39
4.6. Broadcast Video Service Class .............................41
4.7. Low-Latency Data Service Class ............................43
4.8. High-Throughput Data Service Class ........................45
4.9. Standard Service Class ....................................47
4.10. Low-Priority Data ........................................48
5. Additional Information on Service Class Usage ..................49
5.1. Mapping for Signaling .....................................49
5.2. Mapping for NTP ...........................................50
5.3. VPN Service Mapping .......................................50
6. Security Considerations ........................................51
7. Acknowledgements ...............................................52
8. Appendix A .....................................................53
8.1. Explanation of Ring Clipping ..............................53
9. References .....................................................54
9.1. Normative References ......................................54
9.2. Informative References ....................................55
To aid in understanding the role of this document, we use an analogy: the Differentiated Services specifications are fundamentally a toolkit. The specifications provide the equivalent of band saws, planers, drill presses, and other tools. In the hands of an expert, there is no limit to what can be built, but such a toolkit can be intimidating to the point of being inaccessible to a non-expert who just wants to build a bookcase. This document should be viewed as a set of "project plans" for building all the (diffserv) furniture that one might want. The user may choose what to build (e.g., perhaps our non-expert doesn't need a china cabinet right now), and how to go about building it (e.g., plans for a non-expert probably won't employ mortise/tenon construction, but that absence does not imply that mortise/tenon construction is forbidden or unsound). The authors hope that these diffserv "project plans" will provide a useful guide to Network Administrators in the use of diffserv techniques to implement quality-of-service measures appropriate for their network's traffic.
このドキュメントの役割を理解するのを助けるために、我々はアナロジーを使用：差別化サービス仕様は基本的にツールキットです。仕様は、帯鋸、かんな、ドリルプレス、および他のツールと同等のものを提供しています。専門家の手では、構築することができるものに制限はありませんが、そのようなツールキットはちょうど本棚を構築したい非専門家へのアクセス不可であることのポイントに威圧することができます。この文書では、1つの場合がありますすべての（DiffServ）の家具を構築するための「事業計画」のセットとして考えるべきです。ユーザーは、（例えば、おそらく私たちの非専門家が今の中国のキャビネットを必要としない）を構築するために何を選択することができ、そしてどのようにほぞ穴/ほぞを採用していますおそらく、非専門家のために（例えば、計画をそれを構築して行くために建設、それ不在は）そのほぞ/ほぞの建設が禁止または不健全である意味するものではありません。著者らは、これらのDiffServ「プロジェクト計画」は、ネットワークのトラフィックに適切なサービス品質の措置を実施するためのDiffServ技術を使用してネットワーク管理者に便利なガイドを提供することを願っています。
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
この文書では、Diffservので構成されたサービスクラスについて説明し、それらがどのように使用できるかとDiffServコードポイント（DSCPを）、交通コンディショナー、ホップ単位動作（のPHB）、およびアクティブキュー管理（AQM）メカニズムを使用してそれらを構築する方法を推奨しています。そこ特定のDSCP、トラフィックコンディショナー、のPHB、およびAQMは、特定のサービスクラスのために使用することは固有の要件はありませんが、政策としての相互運用性のために、一貫して適用することが有用です。
Service class definitions are based on the different traffic characteristics and required performance of the applications/services. This approach allows us to map current and future applications/services of similar traffic characteristics and performance requirements into the same service class. Since the applications'/services' characteristics and required performance are end to end, the service class notion needs to be preserved end to end. With this approach, a limited set of service classes is required. For completeness, we have defined twelve different service classes, two for network operation/administration and ten for user/subscriber applications/services. However, we expect that network administrators will implement a subset of these classes relevant to their customers and their service offerings. Network Administrators may also find it of value to add locally defined service classes, although these will not necessarily enjoy end-to-end properties of the same type.
サービスクラス定義は、異なるトラフィック特性に基づいており、アプリケーション/サービスのパフォーマンスを必要としています。このアプローチは、私たちは同じサービスクラスに類似したトラフィック特性と性能要件の現在および将来のアプリケーション/サービスをマッピングすることができます。 '/サービスの特性や必要な性能のアプリケーションがエンドツーエンドなので、サービスクラスの概念は、エンドツーエンドを保存する必要があります。このアプローチでは、サービスクラスの制限されたセットが必要です。完全を期すために、私たちは12組の異なるサービスクラス、ネットワーク運用/管理とユーザー/加入者のアプリケーション/サービスのための10のための2つを定義しています。しかし、我々は、ネットワーク管理者は、顧客とそのサービスの提供に関連するこれらのクラスのサブセットを実装することを期待しています。ネットワーク管理者は、これらは必ずしも同じタイプのエンド・ツー・エンドの性質を享受していますが、ローカルに定義されたサービスクラスを追加する価値がそれを見つけることができます。
Section 1 provides an introduction and overview of technologies that are used for service differentiation in IP networks. Section 2 is an overview of how service classes are constructed to provide service differentiation, with examples of deployment scenarios. Section 3 provides configuration guidelines of service classes that are used for stable operation and administration of the network. Section 4 provides configuration guidelines of service classes that are used for differentiation of user/subscriber traffic. Section 5 provides additional guidance on mapping different applications/protocols to service classes. Section 6 addresses security considerations.
第1節では、IPネットワークにおけるサービスの差別化のために使用されている技術の導入と概要を説明します。第2節では、サービスクラスが展開シナリオの例では、サービスの差別化を提供するように構成されている方法の概要です。第3節では、ネットワークの安定運用と管理のために使用されているサービスクラスの構成ガイドラインを提供します。第4章では、ユーザ/加入者トラフィックの差別化のために使用されているサービスクラスの構成ガイドラインを提供します。第5節では、サービスクラスに異なるアプリケーション/プロトコルのマッピングの追加的なガイダンスを提供します。第6節は、セキュリティ上の考慮事項に対処しています。
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "SHOULD"、 "べきではない"、 "REQUIRED"、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In the Internet today, corporate LANs and ISP WANs are generally not heavily utilized. They are commonly 10% utilized at most. For this reason, congestion, loss, and variation in delay within corporate LANs and ISP backbones is virtually unknown. This clashes with user perceptions, for three very good reasons.
インターネットでは、今日、企業のLANおよびWANのISPは、一般的に頻繁に使用されていません。彼らは一般的に10％が最大で利用されています。このため、混雑、損失については、および企業LANやISPのバックボーン内の遅延の変動は事実上不明です。これは、3つの非常に良い理由のために、利用者の認識と衝突します。
o The industry moves through cycles of bandwidth boom and bandwidth bust, depending on prevailing market conditions and the periodic deployment of new bandwidth-hungry applications. o In access networks, the state is often different. This may be because throughput rates are artificially limited or over-subscribed, or because of access network design trade-offs. o Other characteristics, such as database design on web servers (that may create contention points, e.g., in filestore) and configuration of firewalls and routers, often look externally like a bandwidth limitation.
oを業界では、市場の状況や新しい帯域幅を大量に消費するアプリケーションの定期的な展開を実勢に応じて、帯域幅のブームと帯域幅のバストのサイクルを移動します。 Oアクセスネットワークでは、状態が異なることが多いです。スループット・レートがあるため、アクセスネットワークの設計上のトレードオフを人為的に制限されたり、オーバーサブスクライブ、またはされているためと考えられます。そのようなデータベースのWebサーバー上で設計（つまりファイルストアに、例えば、競合ポイントを作成してもよい）およびファイアウォール及びルータの設定などの他の特性、O、多くの場合、帯域幅の制限のような外部から見えます。
The intent of this document is to provide a consistent marking, conditioning, and packet treatment strategy so that it can be configured and put into service on any link that is itself congested.
このドキュメントの目的は、それが設定され、混雑自身で任意のリンク上のサービスに入れることができるように一貫性のマーキング、コンディショニング、およびパケットの治療戦略を提供することです。
A "service class" represents a set of traffic that requires specific delay, loss, and jitter characteristics from the network. Conceptually, a service class pertains to applications with similar characteristics and performance requirements, such as a "High-Throughput Data" service class for applications like the web and electronic mail, or a "Telephony" service class for real-time traffic such as voice and other telephony services. Such a service class may be defined locally in a Differentiated Services (DS) domain, or across multiple DS domains, possibly extending end to end.
「サービスクラス」は、ネットワークから特定の遅延、損失、およびジッタ特性を必要とするトラフィックのセットを表します。概念的には、サービスクラスは、Webや電子メール、または音声などのリアルタイムトラフィックのための「電話」サービスクラスなどのアプリケーションのための「ハイスループットデータ」サービスクラスと同様の特性と性能要件を持つアプリケーションに関連しますそして他の電話サービス。そのようなサービス・クラスは、差別化サービス（DS）ドメイン内でローカルに定義され、または複数のDSドメイン間、おそらく端から端まで延びることができます。
A service class as defined here is essentially a statement of the required characteristics of a traffic aggregate. The required characteristics of these traffic aggregates can be realized by the use of defined per-hop behavior (PHB) [RFC2474]. The actual specification of the expected treatment of a traffic aggregate within a domain may also be defined as a per-domain behavior (PDB) [RFC3086].
ここで定義されているサービスクラスは、基本的にトラフィック集合体の要求特性の文です。これらのトラフィック凝集体の要求される特性が定義されてホップごとのふるまい（PHB）[RFC2474]を使用することによって実現することができます。ドメイン内のトラフィック集合体の期待治療の実際の仕様では、ドメインごとの挙動（PDB）[RFC3086]として定義することができます。
Each domain may choose to implement different service classes or to use different behaviors to implement the service classes or to aggregate different kinds of traffic into the aggregates and still achieve their required characteristics. For example, low delay, loss, and jitter may be realized using the EF PHB, or with an over-provisioned AF PHB. This must be done with care as it may disrupt the end-to-end performance required by the applications/services. This document provides recommendations on usage of PHBs for specific service classes for their consistent implementation. These recommendations are not to be construed as prohibiting use of other PHBs that realize behaviors sufficient for the relevant class of traffic.
各ドメインは、異なるサービスクラスを実装するか、サービスクラスを実装するか、凝集体へのトラフィックの種類を集約し、まだ彼らの要求特性を達成するために、異なる振る舞いを使用することもできます。例えば、低遅延、損失、およびジッタがEF PHBを使用して実現することができる、またはオーバープロビジョニングAF PHBを有します。それはアプリケーション/サービスに必要なエンドツーエンドのパフォーマンスを妨害することがあり、これは注意して行わなければなりません。この文書では、彼らの一貫した実装のための特定のサービスクラスのためのPHBの使用に関する推奨事項を提供します。これらの推奨事項は、トラフィックの関連するクラスのための十分な動作を実現する他のPHBの使用を禁止すると解釈すべきではありません。
The Default Forwarding "Standard" service class is REQUIRED; all other service classes are OPTIONAL. It is expected that network administrators will base their choice of the level of service differentiation that they will support on their need, starting off with three or four service classes for user traffic and adding others as the need arises.
デフォルトフォワーディング「標準」サービスクラスが必要です。他のすべてのサービスクラスはオプションです。ネットワーク管理者はユーザトラフィックのための3つまたは4つのサービスクラスでオフに開始し、必要に応じて他の人を追加し、彼らのニーズにサポートすること、サービスの差別化のレベルの彼らの選択をベースにすることが期待されます。
The reader SHOULD be familiar with the principles of the Differentiated Services Architecture [RFC2474]. We recapitulate key concepts here only to provide convenience for the reader, the referenced RFCs providing the authoritative definitions.
読者は、差別化サービスアーキテクチャ[RFC2474]の原理に精通しているべきです。私たちは、参照先のRFCが権限の定義を提供する、唯一の読者の利便性を提供するために、ここで重要な概念を再現します。
A queue is a data structure that holds packets that are awaiting transmission. The packets may be delayed while in the queue, possibly due to lack of bandwidth, or because it is low in priority. There are a number of ways to implement a queue. A simple model of a queuing system, however, is a set of data structures for packet data, which we will call queues, and a mechanism for selecting the next packet from among them, which we call a scheduler.
キューは、送信を待っているパケットを保持するデータ構造です。キューにいる間のパケットは、おそらく帯域幅の不足のため、延期することができる、またはそれは優先順位が低いので。キューを実装するためのいくつかの方法があります。キューイング・システムの簡単なモデルは、しかし、我々は、スケジューラを呼び出し、キュー、およびそれらの中から次のパケットを選択するためのメカニズムを、呼び出しますパケットデータのためのデータ構造のセットです。
A priority queuing system is a combination of a set of queues and a scheduler that empties them in priority sequence. When asked for a packet, the scheduler inspects the highest priority queue and, if there is data present, returns a packet from that queue. Failing that, it inspects the next highest priority queue, and so on. A freeway onramp with a stoplight for one lane that allows vehicles in the high-occupancy-vehicle lane to pass is an example of a priority queuing system; the high-occupancy-vehicle lane represents the "queue" having priority.
プライオリティキューイング・システムは、キューのセットと優先順位でそれらを空にするスケジューラの組み合わせです。パケットのために尋ねられたとき、スケジューラは、最も優先度の高いキューを検査し、データが存在した場合、そのキューからパケットを返します。それはその次の最も優先度の高いキューを検査し、そして、それに失敗。高占有車レーン内の車両が通過することを可能にする1つのレーンのためのストップライトと高速道路のオンランプは、優先待ち行列システムの例です。高占有車レーンは、優先順位を有する「キュー」を表しています。
In a priority queuing system, a packet in the highest priority queue will experience a readily calculated delay. This is proportional to the amount of data remaining to be serialized when the packet arrived plus the volume of the data already queued ahead of it in the same queue. The technical reason for using a priority queue relates exactly to this fact: it limits delay and variations in delay and should be used for traffic that has that requirement.
プライオリティキューイングシステムでは、最も優先度の高いキュー内のパケットは、容易に計算遅延が発生します。これは、パケットが到着したプラスデータのボリュームがすでに同じキューに先行し、それのキューに入れられたときにシリアル化する残りのデータの量に比例しています。プライオリティキューを使用するための技術的な理由は、まさにこの事実に関連する：それは遅れに遅れ、および変形を制限し、その要件を持つトラフィックに使用する必要があります。
A priority queue or queuing system needs to avoid starvation of lower-priority queues. This may be achieved through a variety of means, such as admission control, rate control, or network engineering.
プライオリティキューまたはキューイングシステムは、優先順位の低いキューの飢餓を避けるために必要です。これは、アドミッション制御、速度制御、またはネットワーク技術として、様々な手段によって達成することができます。
Similarly, a rate-based queuing system is a combination of a set of queues and a scheduler that empties each at a specified rate. An example of a rate-based queuing system is a road intersection with a stoplight. The stoplight acts as a scheduler, giving each lane a certain opportunity to pass traffic through the intersection.
同様に、レートベースのキューイングシステムは、キューの組と特定の速度でそれぞれを空にするスケジューラの組み合わせです。レートベースのキューイング・システムの一例は、ストップライトの道路交差点です。ストップライトは、各レーンに交差点を通過するトラフィックを渡すために、特定の機会を与え、スケジューラとして機能します。
In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) or Weighted Round Robin (WRR), the delay that a packet in any given queue will experience depends on the parameters and occupancy of its queue and the parameters and occupancy of the queues it is competing with. A queue whose traffic arrival rate is much less than the rate at which it lets traffic depart will tend to be empty, and packets in it will experience nominal delays. A queue whose traffic arrival rate approximates or exceeds its departure rate will tend not to be empty, and packets in it will experience greater delay. Such a scheduler can impose a minimum rate, a maximum rate, or both, on any queue it touches.
そのような均等化キューイング（WFQ）または加重ラウンドロビン（WRR）、経験する任意のキュー内のパケットパラメータとキューの占有率とパラメータとの占有に依存する遅延などレートベースのキューイングシステムにおいてキューは、それがと競合しています。そのトラフィック到着率キューは、トラフィックの出発が空になる傾向がありますすることができますする速度よりもはるかに少なく、その中のパケットは、公称遅延が発生します。そのトラフィックの到着率が近いか超えたその出発率が空にならない傾向があり、その中のパケットが大きな遅延が発生しますキュー。そのようなスケジューラは、それが触れる任意のキューに、最小速度、最大速度、または両方を課すことができます。
Active Queue Management, or AQM, is a generic name for any of a variety of procedures that use packet dropping or marking to manage the depth of a queue. The canonical example of such a procedure is Random Early Detection (RED), in that a queue is assigned a minimum and maximum threshold, and the queuing algorithm maintains a moving average of the queue depth. While the mean queue depth exceeds the maximum threshold, all arriving traffic is dropped. While the mean queue depth exceeds the minimum threshold but not the maximum threshold, a randomly selected subset of arriving traffic is marked or dropped. This marking or dropping of traffic is intended to communicate with the sending system, causing its congestion avoidance algorithms to kick in. As a result of this behavior, it is reasonable to expect that TCP's cyclic behavior is desynchronized and that the mean queue depth (and therefore delay) should normally approximate the minimum threshold.
アクティブキュー管理、またはAQMは、パケットのドロップを使用するか、キューの深さを管理するために、マーキングの多様な方法の総称です。そのような手順の標準的な例は、キューは、最小および最大しきい値が割り当てられていることでランダム早期検出（RED）、であり、キューイングアルゴリズムは、キューの深さの移動平均を維持します。平均キュー深度が最大しきい値を超えている間、すべての到着トラフィックはドロップされます。平均キュー深度が最小しきい値ではなく、最大しきい値を超えている間、トラフィックの到着のランダムに選択されたサブセットは、マークされたり削除されます。これは、マーキングやトラフィックのドロップがでキックするために、その輻輳回避アルゴリズムを引き起こし、送信側システムと通信することを目的としている。この動作の結果として、TCPの巡回動作が非同期化されることを期待するのは合理的であると、平均キュー深度こと（と従って遅延）は、通常、最小閾値を近似すべきです。
A variation of the algorithm is applied in Assured Forwarding PHB [RFC2597], in that the behavior aggregate consists of traffic with multiple DSCP marks, which are intermingled in a common queue. Different minima and maxima are configured for the several DSCPs separately, such that traffic that exceeds a stated rate at ingress is more likely to be dropped or marked than traffic that is within its contracted rate.
行動集合は、共通キューに混在する複数のDSCPマークとトラフィックから成ることをアルゴリズムの変形は、保証転送PHB [RFC2597]に適用されます。異なる最小値と最大値は、入口で述べたレートを超えるトラフィックがその収縮率の範囲内であるトラフィックよりドロップまたはマークされる可能性が高くなるように、別々に、いくつかのDSCPのために構成されています。
In addition, at the first router in a network that a packet crosses, arriving traffic may be measured and dropped or marked according to a policy, or perhaps shaped on network ingress, as in "A Rate Adaptive Shaper for Differentiated Services" [RFC2963]. This may be used to bias feedback loops, as is done in "Assured Forwarding PHB" [RFC2597], or to limit the amount of traffic in a system, as is done in "Expedited Forwarding PHB" [RFC3246]. Such measurement procedures are collectively referred to as "traffic conditioners". Traffic conditioners are normally built using token bucket meters, for example with a committed rate and burst size, as in Section 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB [RFC2597] uses a variation on a meter with multiple rate and burst size measurements to test and identify multiple levels of conformance.
また、パケットが交差するネットワーク内の最初のルータに、到着するトラフィックは「差別化サービスのためのレート適応シェイパー」のように、ネットワークの入口に形状おそらく測定し、ドロップまたはマークされたポリシーに従って、またはすることができる[RFC2963] 。 「保証転送PHB」[RFC2597]で行われる、またはシステム内のトラフィックの量を制限するように、「緊急転送PHB」[RFC3246]で行われるように、これは、バイアスフィードバックループに使用してもよいです。このような測定手順は、総称して「トラフィックコンディショナー」と呼ばれます。トラフィックコンディショナは、通常のDiffServモデル[RFC3290]のセクション1.5.3のように、認定速度とバーストサイズと、例えば、トークンバケットメーターを使用して構築されています。保証転送PHB [RFC2597]はテストし、適合性の複数のレベルを識別するために、複数の速度とバーストサイズ測定と測定器の変形を使用します。
Multiple rates and burst sizes can be realized using multiple levels of token buckets or more complex token buckets; these are implementation details. The following are some traffic conditioners that may be used in deployment of differentiated services:
複数速度とバーストサイズは、トークンバケットまたはより複雑なトークンバケットの複数のレベルを使用して実現することができます。これらは実装の詳細です。以下の差別化されたサービスの展開に使用できるいくつかのトラフィックコンディショナーは、以下のとおりです。
o For Class Selector (CS) PHBs, a single token bucket meter to provide a rate plus burst size control. o For Expedited Forwarding (EF) PHB, a single token bucket meter to provide a rate plus burst size control. o For Assured Forwarding (AF) PHBs, usually two token bucket meters configured to provide behavior as outlined in "Two Rate Three Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is used to enforce two rates, whereas the single-rate, three-color marker is used to enforce a committed rate with two burst lengths.
Oのクラスセレクタ（CS）のPHB、料金プラスバーストサイズ制御を提供するために、単一のトークンバケットメートル。 O緊急転送（EF）PHB、レートプラスバーストサイズ制御を提供するために単一のトークンバケットメータについて。保証転送（AF）のPHB、「二つのレート3色マーカー（trTCM）」[RFC2698]または「シングルレート3カラーマーカー（srTCM）」[RFC2697]に概説されるように動作を提供するように構成され、通常、2つのトークンバケットメートルO。二速度3色マーカーは、シングルレートのに対し、三色のマーカーは、2つのバースト長との認定速度を強制するために使用され、2つのレートを強制するために使用されます。
The DSCP is a number in the range 0..63 that is placed into an IP packet to mark it according to the class of traffic it belongs in. Half of these values are earmarked for standardized services, and the other half of them are available for local definition.
DSCPは、それがに属するトラフィックのクラスに応じて、それをマークするために、IPパケットの中に置かれている範囲0 63の数字である。これらの値の半分が標準化されたサービスに充て、およびそれらの他の半分が利用できますローカル定義のため。
In the end, the mechanisms described above are combined to form a specified set of characteristics for handling different kinds of traffic, depending on the needs of the application. This document seeks to identify useful traffic aggregates and to specify what PHB should be applied to them.
最後に、上述したメカニズムは、アプリケーションのニーズに応じて、トラフィックの種類を処理するための特性指定されたセットを形成するために結合されます。この文書では、便利な交通凝集体を識別し、それらに適用されるべきかPHBを指定しようとしています。
While Differentiated Services is a general architecture that may be used to implement a variety of services, three fundamental forwarding behaviors have been defined and characterized for general use. These are basic Default Forwarding (DF) behavior for elastic traffic, the Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF) behavior for real-time (inelastic) traffic. The facts that four code points are recommended for AF and that one code point is recommended for EF are arbitrary choices, and the architecture allows any reasonable number of AF and EF classes simultaneously. The choice of four AF classes and one EF class in the current document is also arbitrary, and operators MAY choose to operate more or fewer of either.
差別化サービスは、様々なサービスを実装するために使用することができる一般的なアーキテクチャですが、3つの基本的な転送動作は、一般的な使用のために定義され、特徴づけられています。これらは弾性トラフィック、保証転送（AF）動作、およびリアルタイムのための緊急転送（EF）行動（非弾性）トラフィックのための基本的なデフォルトの転送（DF）の動作です。 4つの符号点は、AFのために推奨されており、その1つのコードポイントがEFのために推奨されていることを事実は任意選択であり、アーキテクチャが同時にAF及びEFクラスの任意の妥当な数を可能にします。 4つのAFクラスと現在の文書内の1つのEFクラスの選択も任意であり、事業者は、いずれかのより多くのまたはより少ないを動作させるために選ぶかもしれません。
The terms "elastic" and "real-time" are defined in [RFC1633], Section 3.1, as a way of understanding broad-brush application requirements. This document should be reviewed to obtain a broad understanding of the issues in quality of service, just as [RFC2475] should be reviewed to understand the data plane architecture used in today's Internet.
「リアルタイム」という用語は、「弾性」と理解広いブラシアプリケーション要件の方法として、[RFC1633]、セクション3.1で定義されています。この文書では、[RFC2475]は、今日のインターネットで使用されるデータ・プレーン・アーキテクチャを理解するために見直されるべきであるのと同様に、サービスの品質に問題の幅広い理解を得るために見直されるべきです。
The basic forwarding behaviors applied to any class of traffic are those described in [RFC2474] and [RFC2309]. Best-effort service may be summarized as "I will accept your packets" and is typically configured with some bandwidth guarantee. Packets in transit may be lost, reordered, duplicated, or delayed at random. Generally, networks are engineered to limit this behavior, but changing traffic loads can push any network into such a state.
トラフィックの任意のクラスに適用される基本的な転送動作は、[RFC2474]及び[RFC2309]に記載されているものです。ベストエフォート型のサービスでは、「私はあなたのパケットを受け入れるだろう」と一般的にいくつかの帯域保証が設定されているように要約することができます。輸送中のパケットは、失われた並べ替え、重複、またはランダムに遅れることがあります。一般的に、ネットワークは、この動作を制限するように設計されていますが、変更するトラフィック負荷は、このような状態に任意のネットワークをプッシュすることができます。
Application traffic in the internet that uses default forwarding is expected to be "elastic" in nature. By this, we mean that the sender of traffic will adjust its transmission rate in response to changes in available rate, loss, or delay.
デフォルトの転送を使用して、インターネットでのアプリケーショントラフィックは、自然の中で、「弾性」であることが予想されます。これにより、我々は、トラフィックの送信元が利用可能率、損失、または遅延の変化に応じてその伝送レートを調整することを意味します。
For the basic best-effort service, a single DSCP value is provided to identify the traffic, a queue to store it, and active queue management to protect the network from it and to limit delays.
基本的なベストエフォート型のサービスでは、単一のDSCP値はそれからネットワークを保護し、遅延を制限するトラフィック、それを格納するキュー、およびアクティブキュー管理を識別するために提供されます。
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss Priority (CLP) capability. It is intended for networks that offer average-rate Service Level Agreements (SLAs) (as FR and ATM networks do). This is an enhanced best-effort service; traffic is expected to be "elastic" in nature. The receiver will detect loss or variation in delay in the network and provide feedback such that the sender adjusts its transmission rate to approximate available capacity.
保証転送PHB [RFC2597]の動作は、明示的にフレームリレーの廃棄適性（DE）フラグやATMのセル廃棄優先（CLP）の能力をモデルにしています。これは、平均レートサービスレベル契約（SLA）（FRとATMネットワークがそうであるように）を提供するネットワークを対象としています。これが強化され、ベストエフォート型のサービスです。トラフィックは、自然の中で、「弾性」であることが予想されます。受信機は、ネットワークの遅延の損失又は変化を検出し、送信者が利用可能な容量を近似するために、その伝送レートを調整するようにフィードバックを提供します。
For such behaviors, multiple DSCP values are provided (two or three, perhaps more using local values) to identify the traffic, a common queue to store the aggregate, and active queue management to protect the network from it and to limit delays. Traffic is metered as it enters the network, and traffic is variously marked depending on the arrival rate of the aggregate. The premise is that it is normal for users occasionally to use more capacity than their contract stipulates, perhaps up to some bound. However, if traffic should be marked or lost to manage the queue, this excess traffic will be marked or lost first.
そのような行動のために、複数のDSCP値がそこからネットワークを保護し、遅延を制限するために、集合体を格納するための共通のキュー、及びアクティブキュー管理トラフィックを識別するために、（二、三、おそらくより多くのローカル値を使用して）設けられています。それがネットワークに入ると、トラフィックが計量され、トラフィックが様々に集約の到着率に応じてマークされます。前提は、それはおそらくいくつかの境界まで、その契約の規定よりも多くの容量を使用するために、時々のユーザーのために正常であることです。トラフィックは、キューを管理するためにマークされたり紛失しなければならない場合には、この過剰なトラフィックがマークされますまたは最初に失われました。
The intent of Expedited Forwarding PHB [RFC3246] is to provide a building block for low-loss, low-delay, and low-jitter services. It can be used to build an enhanced best-effort service: traffic remains subject to loss due to line errors and reordering during routing changes. However, using queuing techniques, the probability of delay or variation in delay is minimized. For this reason, it is generally used to carry voice and for transport of data information that requires "wire like" behavior through the IP network. Voice is an inelastic "real-time" application that sends packets at the rate the codec produces them, regardless of availability of capacity. As such, this service has the potential to disrupt or congest a network if not controlled. It also has the potential for abuse.
緊急転送PHB [RFC3246]の目的は、低損失、低遅延、および低ジッタのサービスのためのビルディングブロックを提供することです。拡張ベストエフォート型のサービスを構築するために使用することができます：トラフィックは、変更をルーティング中に回線エラーと並べ替えによる損失を受けたまま。しかし、キューイング技術を使用して、遅延の遅延または変化の可能性が最小限に抑えられます。このため、一般的にIPネットワークを介して行動「のような線」を必要とし、音声およびデータ情報の輸送のためを運ぶために使用されています。音声は容量にかかわらず利用できるのは、コーデックは、それらを生成レートでパケットを送信する非弾性「リアルタイム」のアプリケーションです。そのため、このサービスは制御されない場合は、ネットワークを混乱や混雑する可能性があります。また、乱用の可能性があります。
To protect the network, at minimum one SHOULD police traffic at various points to ensure that the design of a queue is not overrun, and then the traffic SHOULD be given a low-delay queue (often using priority, although it is asserted that a rate-based queue can do this) to ensure that variation in delay is not an issue, to meet application needs.
ネットワークを保護するには、最低でも1は、様々な点で警察のトラフィックは、キューの設計がオーバーランされていないことを確実にする必要があり、その後、トラフィックは低遅延キューを与えられるべきである（それは率と主張しているが、多くの場合、優先順位を使用してベースのキューは、アプリケーションのニーズを満たすために、遅延のばらつきが問題ないことを確認するために）これを行うことができます。
Class Selector provides support for historical codepoint definitions and PHB requirement. The Class Selector DS field provides a limited backward compatibility with legacy (pre DiffServ) practice, as described in [RFC2474], Section 4. Backward compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to historical use of the IP Precedence field, and we reserve these codepoints to map to PHBs that meet the general requirements specified in [RFC2474], Section 4.2.2.2.
クラスセレクタは、歴史的なコードポイントの定義とPHBの要求のためのサポートを提供します。 [RFC2474]に記載されているように、クラスセレクタDSフィールドは、セクション4下位互換性は、二つの方法で対処され、レガシー（事前のDiffServ）実施に限定下位互換性を提供します。まず、そこに広く普及し、すでにあるホップごとの挙動（[RFC1812]で指定された要件をキューイングIPv4の優先順位を満たす例えば、それらは）あり、我々はDS準拠のネットワークで彼らの継続的な使用を許可したいです。また、そこにIP Precedenceフィールドの歴史的な使用に対応していくつかのコードポイントであり、私たちは[RFC2474]で指定された一般的な要件は、セクション4.2.2.2を満たすのPHBにマッピングするには、これらのコードポイントを留保します。
No attempt is made to maintain backward compatibility with the "DTR" or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in [RFC0791] and [RFC1349].
[RFC0791]及び[RFC1349]で定義されるように試みは、サービスの「DTR」またはタイプ（TOS）IPv4のTOSオクテットのビットとの下位互換性を維持するために行われません。
A DS-compliant network can be deployed with a set of one or more Class Selector-compliant PHB groups. Also, a network administrator may configure the network nodes to map codepoints to PHBs, irrespective of bits 3-5 of the DSCP field, to yield a network that is compatible with historical IP Precedence use. Thus, for example, codepoint '011000' would map to the same PHB as codepoint '011010'.
DS準拠のネットワークは、1つまたは複数のクラスセレクタに準拠したPHBグループのセットを展開することができます。また、ネットワーク管理者は、履歴IP優先順位の使用と互換性のあるネットワークを生成するために関係なく、DSCPフィールドのビット3-5、のPHBにコードポイントをマップするためにネットワーク・ノードを構成することができます。したがって、例えば、コードポイント「011000」は「011010」コードポイントと同じPHBにマップすることになります。
Admission control (including refusal when policy thresholds are crossed) can ensure high-quality communication by ensuring the availability of bandwidth to carry a load. Inelastic real-time flows such as Voice over Internet Protocol (VoIP) (telephony) or video conferencing services can benefit from use of an admission control mechanism, as generally the telephony service is configured with over-subscription, meaning that some users may not be able to make a call during peak periods.
（ポリシーしきい値を超えた拒絶を含む）、アドミッション制御は、負荷を運ぶために、帯域幅の利用可能性を保証することにより、高品質な通信を確保することができます。非弾性リアルタイムは、一部のユーザーがないかもしれないことを意味し、一般電話サービスは、オーバーサブスクリプションが設定されているように、アドミッション制御メカニズムの使用から利益を得ることができ、インターネットプロトコル（VoIP）（電話）やビデオ会議サービスボイスオーバーなどの流れピーク時間帯に電話をかけることができ。
For VoIP (telephony) service, a common approach is to use signaling protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation Protocol (RSVP) to negotiate admittance and use of network transport capabilities. When a user has been authorized to send voice traffic, this admission procedure has verified that data rates will be within the capacity of the network that it will use. Many RTP voice payloads are inelastic and cannot react to loss or delay in any substantive way. For these voice payloads, the network SHOULD police at ingress to ensure that the voice traffic stays within its negotiated bounds. Having thus assured a predictable input rate, the network may use a priority queue to ensure nominal delay and variation in delay.
VoIPの（電話）サービスのために、一般的なアプローチは、アドミタンスとネットワークトランスポート機能の使用を交渉するようなSIP、H.323、H.248、MEGACO、およびリソース予約プロトコル（RSVP）のようなシグナリングプロトコルを使用することです。ユーザーが音声トラフィックを送信することを許可された場合には、この入学手続きは、データ・レートは、それが使用するネットワークの能力の範囲内になることを確認しました。多くのRTP音声ペイロードは、非弾性であり、任意の実質的な方法で、損失や遅延に反応することはできません。これらの音声ペイロードのために、ネットワークは、音声トラフィックがその交渉された境界内に留まることを保証するために、入口で警察べきです。このように予測可能な入力レートを保証したが、ネットワークは、遅延の公称遅延変動を確実にするために、優先キューを使用することができます。
Another approach that may be used in small and bandwidth-constrained networks for limited number of flows is RSVP [RFC2205] [RFC2996]. However, there is concern with the scalability of this solution in large networks where aggregation of reservations [RFC3175] is considered to be required.
フローの限られた数の小と帯域幅に制約のネットワークで使用することができる別のアプローチは、RSVP [RFC2205]、[RFC2996]です。しかし、予約[RFC3175]の凝集が必要であると考えられている大規模なネットワークでは、このソリューションのスケーラビリティとの懸念があります。
There are practical limits on the level of service differentiation that should be offered in the IP networks. We believe we have defined a practical approach in delivering service differentiation by defining different service classes that networks may choose to support in order to provide the appropriate level of behaviors and performance needed by current and future applications and services. The defined structure for providing services allows several applications having similar traffic characteristics and performance requirements to be grouped into the same service class. This approach provides a lot of flexibility in providing the appropriate level of service differentiation for current and new, yet unknown applications without introducing significant changes to routers or network configurations when a new traffic type is added to the network.
IPネットワークで提供されるサービスの差別化のレベルでの実用的な制限があります。私たちはネットワークが現在および将来のアプリケーションやサービスで必要な行動やパフォーマンスの適切なレベルを提供するために、サポートすることもできます異なるサービスクラスを定義することによって、サービスの差別化を提供する上で実用的なアプローチを定義していると信じています。サービスを提供するための定義された構造は、同様のトラフィック特性及び性能要件を有する複数のアプリケーションが同一のサービスクラスに分類されることを可能にします。このアプローチは、新たなトラフィックタイプがネットワークに追加されたときにルータやネットワーク構成に大幅な変更を導入することなく、現在と新しい、未知のアプリケーションのためのサービスの差別化の適切なレベルを提供する多くの柔軟性を提供します。
Traffic flowing in a network can be classified in many different ways. We have chosen to divide it into two groupings, network control and user/subscriber traffic. To provide service differentiation, different service classes are defined in each grouping. The network control traffic group can further be divided into two service classes (see Section 3 for detailed definition of each service class):
ネットワークを流れるトラフィックは、多くの異なる方法で分類することができます。我々は2つのグループ、ネットワーク制御とユーザ/加入者トラフィックに分割することを選択しました。サービスの差別化を提供するために、異なるサービスクラスは、各グループで定義されています。ネットワーク制御トラフィック・グループは、（各サービス・クラスの詳細な定義についてはセクション3を参照）は、2つのサービスクラスに分けることができます。
o "Network Control" for routing and network control function. o "OAM" (Operations, Administration, and Management) for network configuration and management functions.
ルーティングとネットワーク制御機能のためのO「ネットワークコントロール」。ネットワーク構成および管理機能のための「OAM」（運用、管理、および管理）の。
The user/subscriber traffic group is broken down into ten service classes to provide service differentiation for all the different types of applications/services (see Section 4 for detailed definition of each service class):
ユーザー/加入者トラフィックグループは、アプリケーション/サービス（各サービス・クラスの詳細な定義については、セクション4を参照）のすべての異なるタイプのサービスの差別化を提供するために、10個のサービスクラスに分類されます。
o Telephony service class is best suited for applications that require very low delay variation and are of constant rate, such as IP telephony (VoIP) and circuit emulation over IP applications. o Signaling service class is best suited for peer-to-peer and client-server signaling and control functions using protocols such as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol (MGCP). o Multimedia Conferencing service class is best suited for applications that require very low delay and have the ability to change encoding rate (rate adaptive), such as H.323/V2 and later video conferencing service. o Real-Time Interactive service class is intended for interactive variable rate inelastic applications that require low jitter and loss and very low delay, such as interactive gaming applications that use RTP/UDP streams for game control commands, and video conferencing applications that do not have the ability to change encoding rates or to mark packets with different importance indications. o Multimedia Streaming service class is best suited for variable rate elastic streaming media applications where a human is waiting for output and where the application has the capability to react to packet loss by reducing its transmission rate, such as streaming video and audio and webcast. o Broadcast Video service class is best suited for inelastic streaming media applications that may be of constant or variable rate, requiring low jitter and very low packet loss, such as broadcast TV and live events, video surveillance, and security.
Oテレフォニーサービスクラスには、IPテレフォニー（VoIP）のおよびIPアプリケーション経由回線エミュレーションなど、非常に低遅延変動を必要とし、一定の速度である用途のために最適です。 Oシグナリングサービスクラスは、ピアツーピアおよびクライアントサーバのシグナリングと制御機能例えばSIP、SIP-T、H.323、H.248、およびメディアゲートウェイ制御プロトコル（MGCP）などのプロトコルを使用するために最適です。 Oマルチメディア会議サービスクラスには、H.323 / V2以降ビデオ会議サービスのような非常に低遅延を必要とし、符号化率（レート適応）を変更する機能を持つアプリケーションのために最適です。 Oリアルタイムインタラクティブサービスクラスは、インタラクティブなゲーム制御コマンドのためにRTP / UDPストリームを使用するゲームアプリケーション、および持たないビデオ会議アプリケーションなどの低ジッタおよび損失と非常に低遅延を必要とする対話型の変数率非弾性用途のために意図されますエンコード速度を変更するか、別の重要性を指摘してパケットをマークする能力。 Oマルチメディアストリーミングサービスクラスは、人間が出力を待っていると、アプリケーションは、ストリーミングビデオとオーディオとウェブキャストとして、その伝送速度を低減することにより、パケット損失に反応する能力を持っている可変レート弾性ストリーミング・メディア・アプリケーションに最適です。 O放送ビデオサービスクラスは、低ジッタと、放送テレビやライブイベント、ビデオ監視、セキュリティなどの非常に低いパケット損失を、必要な一定または可変レートとすることができる非弾性ストリーミング・メディア・アプリケーションに最適です。
o Low-Latency Data service class is best suited for data processing applications where a human is waiting for output, such as web-based ordering or an Enterprise Resource Planning (ERP) application. o High-Throughput Data service class is best suited for store and forward applications such as FTP and billing record transfer. o Standard service class is for traffic that has not been identified as requiring differentiated treatment and is normally referred to as best effort. o Low-Priority Data service class is intended for packet flows where bandwidth assurance is not required.
O低遅延のデータサービスクラスは、Webベースの発注やエンタープライズ・リソース・プランニング（ERP）アプリケーションなど、人間が出力を待っているデータ処理アプリケーション、に最適です。 Oハイスループットデータサービスクラスは、FTPや課金記録転送としてストアアンドフォワードのアプリケーションに最適です。 O規格のサービスクラスは、分化し、治療を必要とするものとして同定されていないと正常にベストエフォートと呼ばれているトラフィックのためです。 O優先度の低いデータサービスクラスは、パケットのために意図された帯域保証が必要とされていないところに流れます。
The ten defined user/subscriber service classes listed above can be grouped into a small number of application categories. For some application categories, it was felt that more than one service class was needed to provide service differentiation within that category due to the different traffic characteristic of the applications, control function, and the required flow behavior. Figure 1 provides a summary of service class grouping into four application categories.
上記10に定義ユーザ/加入者サービスクラスは、アプリケーションの種類の少数にグループ分けすることができます。いくつかのアプリケーションカテゴリのためには、複数のサービスクラスが異なるアプリケーションのトラフィック特性、制御機能、および必要な流動挙動のために、そのカテゴリ内のサービスの差別化を提供するために必要であると感じました。図1は、4つのアプリケーションのカテゴリにサービス・クラスのグループ化の要約を提供します。
Application Control Category
アプリケーション制御カテゴリ
o The Signaling service class is intended to be used to control applications or user endpoints. Examples of protocols that would use this service class are SIP or H.248 for IP telephone service and SIP or Internet Group Management Protocol (IGMP) for control of broadcast TV service to subscribers. Although user signaling flows have similar performance requirements as Low-Latency Data, they need to be distinguished and marked with a different DSCP. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the media stream/session they signal and control.
Oシグナリングサービスクラスは、アプリケーションまたはユーザ・エンドポイントを制御するために使用されることを意図しています。このサービスクラスを使用するプロトコルの例は、加入者にテレビ放送サービスの制御のためのIP電話サービスおよびSIPまたはインターネットグループ管理プロトコル（IGMP）のためのSIPやH.248です。ユーザーシグナリングフローは、低遅延のデータと同様の性能要件を持っているが、それらは区別し、異なるDSCPでマークする必要があります。基本的な区別は、このクラスのプロトコルはメディアストリーム/彼らは信号のセッションおよび制御に縛られる傾向があるとして、影響を受けたトラフィックの「管理制御および管理」のようなものです。
Media-Oriented Category
メディア指向のカテゴリー
Due to the vast number of new (in process of being deployed) and already-in-use media-oriented services in IP networks, five service classes have been defined.
（展開されているプロセスで）新しいとIPネットワークで既に使用中のメディア指向サービスの膨大な数に、5つのサービスクラスが定義されているため。
o Telephony service class is intended for IP telephony (VoIP) service. It may also be used for other applications that meet the defined traffic characteristics and performance requirements. o Real-Time Interactive service class is intended for inelastic video flows from applications such as SIP-based desktop video conferencing applications and for interactive gaming.
Oテレフォニーサービスクラスは、IPテレフォニー（VoIP）のサービスを対象としています。また、定義されたトラフィックの特性と性能要件を満たし、他の用途に使用することができます。 Oリアルタイムインタラクティブサービスクラスは、非弾性映像を対象とし、このようなSIPベースのデスクトップビデオ会議アプリケーションなどのアプリケーションから、インタラクティブなゲームのために流れています。
o Multimedia Conferencing service class is for video conferencing solutions that have the ability to reduce their transmission rate on detection of congestion. These flows can therefore be classified as rate adaptive. As currently two types of video conferencing equipment are used in IP networks (ones that generate inelastic traffic and ones that generate rate-adaptive traffic), two service class are needed. The Real-Time Interactive service class should be used for equipment that generates inelastic video flows and the Multimedia Conferencing service class for equipment that generates rate-adaptive video flows. o Broadcast Video service class is to be used for inelastic traffic flows, which are intended for broadcast TV service and for transport of live video and audio events. o Multimedia Streaming service class is to be used for elastic multimedia traffic flows. This multimedia content is typically stored before being transmitted. It is also buffered at the receiving end before being played out. The buffering is sufficiently large to accommodate any variation in transmission rate that is encountered in the network. Multimedia entertainment over IP delivery services that are being developed can generate both elastic and inelastic traffic flows; therefore, two service classes are defined to address this space, respectively: Multimedia Streaming and Broadcast Video.
Oマルチメディア会議サービスクラスは、輻輳の検出に自分の伝送速度を減少させる能力を持っているビデオ会議ソリューションのためです。これらのフローは、したがって、レート適応に分類することができます。同様に、現在のビデオ会議機器の2種類がIPネットワーク（非弾性トラフィックとレート適応型トラフィックを生成するものを生成するもの）に使用され、2つのサービスクラスが必要とされています。リアルタイムインタラクティブサービスクラスは、非弾性ビデオフローを発生する機器およびレート適応ビデオフローを発生する機器のためのマルチメディア会議サービスクラスを使用する必要があります。 O放送ビデオサービスクラスは、テレビ放送サービスのためのライブビデオとオーディオイベントの輸送のために意図されている非弾性トラフィックフローに使用されます。 Oマルチメディアストリーミングサービスクラスは、弾性マルチメディアトラフィックフローのために使用されるべきです。このマルチメディア・コンテンツは、一般的に送信される前に保存されています。また、プレイアウトされる前に、受信側でバッファリングされています。バッファリングは、ネットワーク内で検出された伝送速度の任意の変化を収容するのに十分な大きさです。開発されているIP配信サービス上でマルチメディア・エンターテイメントは、弾性および非弾性の両方のトラフィックフローを生成することができます。そのため、2つのサービスクラスは、それぞれ、このスペースに対処するために定義されています：マルチメディアストリーミングおよびブロードキャストビデオ。
Data Category
データカテゴリ
The data category is divided into three service classes.
データカテゴリは、3つのサービスクラスに分割されます。
o Low-Latency Data for applications/services that require low delay or latency for bursty but short-lived flows. o High-Throughput Data for applications/services that require good throughput for long-lived bursty flows. High Throughput and Multimedia Steaming are close in their traffic flow characteristics with High Throughput being a bit more bursty and not as long-lived as Multimedia Streaming. o Low-Priority Data for applications or services that can tolerate short or long interruptions of packet flows. The Low-Priority Data service class can be viewed as "don't care" to some degree.
O低遅延のデータバースト性が、短命のフローのための低遅延やレイテンシを必要とするアプリケーション/サービスのため。 Oハイスループットデータ長寿命バースト的な流れのための良好なスループットを必要とするアプリケーション/サービスのため。高スループットとマルチメディア蒸しは、高スループットのマルチメディアストリーミングのように長寿命もう少しバースト性はないことを彼らの交通流特性に接近しています。パケットフローの短いまたは長い中断を許容できるアプリケーションやサービスのO優先度の低いデータ。低優先度のデータサービスクラスは、ある程度「気にしない」とみなすことができます。
Best-Effort Category
ベストエフォートのカテゴリー
o All traffic that is not differentiated in the network falls into this category and is mapped into the Standard service class. If a packet is marked with a DSCP value that is not supported in the network, it SHOULD be forwarded using the Standard service class.
Oネットワークに区別されていないすべてのトラフィックは、このカテゴリーに入ると、標準サービスクラスにマッピングされます。パケットがネットワークでサポートされていないDSCP値でマークされている場合、それは標準のサービスクラスを使用して転送する必要があります。
Figure 1, below, provides a grouping of the defined user/subscriber service classes into four categories, with indications of which ones use an independent flow for signaling or control; type of flow behavior (elastic, rate adaptive, or inelastic); and the last column provides end user Quality of Service (QoS) rating as defined in ITU-T Recommendation G.1010.
図1は、以下のものがシグナリングまたは制御のための独立した流れを使用するかの指示と、4つのカテゴリに定義されたユーザ/加入者サービスクラスのグループ化を提供します。流動挙動の種類（弾性、レート適応、または非弾性）。 ITU-T勧告G.1010で定義されているし、最後の列は、サービス（QoS）の評価のエンドユーザーの品質を提供します。
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
Figure 1. User/Subscriber Service Classes Grouping
図1.ユーザー/加入者サービスクラスのグループ化
Here is a short explanation of the end user QoS category as defined in ITU-T Recommendation G.1010. User traffic is divided into four different categories, namely, interactive, responsive, timely, and non-critical. An example of interactive traffic is between two humans and is most sensitive to delay, loss, and jitter. Another example of interactive traffic is between two servers where very low delay and loss are needed. Responsive traffic is typically between a human and a server but can also be between two servers. Responsive traffic is less affected by jitter and can tolerate longer delays than interactive traffic. Timely traffic is either between servers or servers and humans and the delay tolerance is significantly longer than responsive traffic. Non-critical traffic is normally between servers/machines where delivery may be delay for period of time.
ここではITU-T勧告G.1010で定義されたエンドユーザのQoSカテゴリの短い説明があります。ユーザーのトラフィックは、すなわち、インタラクティブな応答、タイムリー、かつ非クリティカル4つの異なるカテゴリーに分割されます。インタラクティブなトラフィックの例は、2人の人間の間で、遅延、損失、およびジッタに最も敏感です。インタラクティブなトラフィックの別の例は、非常に低遅延と損失が必要とされている2つのサーバー間です。応答トラフィックは、人間とサーバの間で一般的であるだけでなく、2つのサーバー間ですることができます。応答トラフィックが少なく、ジッタの影響を受けているとの対話型のトラフィックよりも長い遅延を許容することができます。タイムリーなトラフィックは、いずれかのサーバーまたはサーバーと人間と遅延許容度の間の応答のトラフィックよりも有意に長いです。非クリティカルなトラフィックは配信が一定期間の遅延かもしれサーバ/マシン間で通常です。
This document provides guidelines for network administrators in configuring their network for the level of service differentiation that is appropriate in their network to meet their QoS needs. It is expected that network operators will configure and provide in their networks a subset of the defined service classes. Our intent is to provide guidelines for configuration of Differentiated Services for a wide variety of applications, services, and network configurations. In addition, network administrators may choose to define and deploy other service classes in their network.
この文書は、そのQoSのニーズを満たすために彼らのネットワーク内に適切なサービスの差別化のレベルのために彼らのネットワークを構成するには、ネットワーク管理者のためのガイドラインを提供します。ネットワーク事業者が設定し、そのネットワークで定義されたサービスクラスのサブセットを提供することが期待されます。私たちの目的は、アプリケーション、サービス、およびさまざまなタイプのネットワーク構成のための差別化サービスを設定するためのガイドラインを提供することです。また、ネットワーク管理者は、ネットワーク内の他のサービスクラスを定義し、展開することもできます。
Figure 2 provides a behavior view for traffic serviced by each service class. The traffic characteristics column defines the characteristics and profile of flows serviced, and the tolerance to loss, delay, and jitter columns define the treatment the flows will receive. End-to-end quantitative performance requirements may be obtained from ITU-T Recommendations Y.1541 and Y.1540.
図2は、各サービス・クラスによってサービストラフィックのための行動のビューを提供します。トラフィック特性列は特性およびサービスフローのプロファイルを定義し、損失、遅延、およびジッタ列に対する耐性は、フローが受信する処理を定義します。エンドツーエンドの定量的な性能要件は、ITU-T勧告Y. 1541とY.1540から得ることができます。
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------
Figure 2. Service Class Characteristics
2.サービスクラス特性を図
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies that data is buffered in the endpoint and that a moderate level of network-induced variation in delay will not affect the application. Applications that use TCP as a transport are generally good examples. Routing protocols and peer-to-peer signaling also fall in this class; although loss can create problems in setting up calls, a moderate level of jitter merely makes call placement a little less predictable in duration.
図2注：「はい」ジッタ耐性列のデータがエンドポイントにバッファリング遅延にネットワーク誘起変化の適度なレベルがアプリケーションに影響を与えないことであることを意味します。トランスポートとしてTCPを使用するアプリケーションは、一般的に良い例です。ルーティングプロトコル及びピア・ツー・ピアシグナリングはまた、このクラスに入ります。損失は、通話のセットアップに問題を作成することができますが、ジッターの適度なレベルは、単に期間中のコールの配置が少し予測可能になります。
Service classes indicate the required traffic forwarding treatment in order to meet user, application, or network expectations. Section 3 defines the service classes that MAY be used for forwarding network control traffic, and Section 4 defines the service classes that MAY be used for forwarding user traffic with examples of intended application types mapped into each service class. Note that the application types are only examples and are not meant to be all-inclusive or prescriptive. Also, note that the service class naming or ordering does not imply any priority ordering. They are simply reference names that are used in this document with associated QoS behaviors that are optimized for the particular application types they support. Network administrators MAY choose to assign different service class names to the service classes that they will support. Figure 3 defines the RECOMMENDED relationship between service classes and DS codepoint assignment with application examples. It is RECOMMENDED that this relationship be preserved end to end.
サービスクラスは、ユーザー、アプリケーション、またはネットワークの期待を満たすために必要なトラフィックの転送処理を示しています。セクション3は、転送ネットワーク制御トラフィックのために使用されるかもしれサービスクラスを定義し、セクション4は、各サービス・クラスにマッピングされ、意図される用途の種類の例で、ユーザトラフィックを転送するために使用されるかもしれサービス・クラスを定義します。アプリケーションの種類はあくまで一例であり、すべて込みや規範であることを意味していないことに注意してください。また、サービスクラスの命名や順序が任意の優先順位を意味するものではありませんのでご注意。彼らは単に彼らがサポートする特定のアプリケーションの種類に合わせて最適化されている関連付けられたQoS行動で、このドキュメントで使用されている名前を参照しています。ネットワーク管理者は、彼らがサポートするサービスクラスに異なるサービスクラス名を割り当てるために選ぶかもしれません。図3は、サービスクラスおよびアプリケーション例にDSコードポイントの割り当て間の推奨関係を定義します。この関係は端から端まで保存することが推奨されます。
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------|
| Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
Figure 3. DSCP to Service Class Mapping
図3. DSCPサービスクラスへのマッピング
Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000'.
図3のための注意事項：デフォルトの転送（DF）とクラスセレクタ0（CS0）と同等の挙動を提供し、同じDSコードポイントを使用し、「000000」。
It is expected that network administrators will base their choice of the service classes that they will support on their need, starting off with three or four service classes for user traffic and adding others as the need arises.
ネットワーク管理者は、ユーザトラフィックのために、3つのまたは4つのサービスクラスでオフに開始し、必要に応じて他の人を追加し、彼らは彼らのニーズにサポートするサービスクラスの彼らの選択をベースにすることが期待されます。
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be used for the defined service classes that are further detailed in Sections 3 and 4 of this document. According to what applications/services need to be differentiated, network administrators can choose the service class(es) that need to be supported in their network.
図4は、セクション3と、この文書の4においてさらに詳述されている定義されたサービス・クラスのために使用されるべきであるのDiffServ QoSメカニズムの概要を提供します。アプリケーション/サービスを差別化するために必要なものによれば、ネットワーク管理者は、ネットワークでサポートする必要のあるサービスクラス（複数可）を選択することができます。
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 |three-color marker | RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+------+-------------------+---------|--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 |three-color marker | RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three-color marker | RFC2597 | Rate | per|
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
Figure 4. Summary of QoS Mechanisms Used for Each Service Class
各サービスクラスに使用したQoSメカニズムの図4.まとめ
Notes for Figure 4:
図4のための注意事項：
o Conditioning at DS edge means that traffic conditioning is performed at the edge of the DiffServ network where untrusted user devices are connected or between two DiffServ networks. o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o The PHB for Real-Time Interactive service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a second EF PHB that uses relaxed performance parameters and a rate scheduler. o The PHB for Broadcast Video service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a third EF PHB that uses relaxed performance parameters and a rate scheduler. o In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress.
O DSエッジのコンディショニングは、トラフィックコンディショニングを信頼できないユーザ装置が接続されているのDiffServネットワークのエッジで又は二のDiffServネットワークとの間で行われることを意味します。 O「SR + BS」バーストサイズ制御を有する単一速度を提供するポリシングメカニズムを表します。シングルレートO、三色マーカー（srTCM）の動作は、RFC 2697と同等であるべきであり、二速度3色マーカー（trTCM）の動作は、リアルタイム対話用PHB O RFC 2698と同等であるべきですサービスクラスは、高帯域幅の保証を提供するために設定する必要があります。これは、リラックスした性能パラメータを使用する第2のEF PHBとレートスケジューラとして構成されてもよいです。 oを放送ビデオサービスクラスのPHBは、高帯域幅の保証を提供するために設定する必要があります。これは、リラックスした性能パラメータを使用して第三のEF PHBとレートスケジューラとして構成されてもよいです。 O IP precedenceマーキングを使用したネットワークセグメントでは、唯一の2つのサービスクラスのは、高スループットのデータまたは低優先度データ、サポートすることができます。我々は、サポートされていないサービス・クラスのDSCP値（S）が入力で000xx1に変更し、マーキングの優先順位を使用するネットワークセグメントの出口に元の値（複数可）に変更することをお勧めします。低優先度のデータは、標準サービス・クラスにマップされている場合、その後、マーキング000001 DSCPが標準からそれを区別するために使用されるかもしれ出口でパケットをマーク。
It is expected that network administrators will base their choice of the service classes that they will support on their need, starting off with three or four service classes for user traffic and adding more service classes as the need arises. In this section, we provide three examples of possible deployment scenarios.
ネットワーク管理者は、ユーザトラフィックのために、3つのまたは4つのサービスクラスでオフに開始し、必要に応じて複数のサービスクラスを追加し、彼らは彼らのニーズにサポートするサービスクラスの彼らの選択をベースにすることが期待されます。このセクションでは、我々は可能な展開シナリオの3つの例を提供します。
A network administrator determines that he needs to provide different performance levels (quality of service) in his network for the services that he will be offering to his customers. He needs to enable his network to provide: o Reliable VoIP (telephony) service, equivalent to Public Switched Telephone Network (PSTN). o A low-delay assured bandwidth data service. o Support for current Internet services.
ネットワーク管理者は、彼は彼が彼の顧客に提供されるサービスのために彼のネットワーク内の異なるパフォーマンスレベル（サービス品質）を提供する必要があると判断します。公立と同等の信頼性の高いVoIPの（電話）サービスは、交換電話網（PSTN）○：彼は、提供するために、自分のネットワークを有効にする必要があります。 O低遅延、帯域幅、データサービスを保証します。現在のインターネットサービスのためのOサポート。
For this example, the network administrator's needs are addressed with the deployment of the following six service classes:
この例では、ネットワーク管理者のニーズは、以下の6つのサービスクラスの展開に対処されています。
o Network Control service class for routing and control traffic that is needed for reliable operation of the provider's network. o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment through the network for support of current Internet service. o Telephony service class for VoIP (telephony) bearer traffic. o Signaling service class for Telephony signaling to control the VoIP service. o Low-Latency Data service class for the low-delay assured bandwidth differentiated data service. o OAM service class for operation and management of the network.
プロバイダのネットワークの信頼性の高い動作のために必要とされるルーティングおよび制御トラフィック用のOネットワーク制御サービスクラス。現在のインターネットサービスをサポートするためにネットワークを介して、通常の（未分化）転送処理を受信するすべてのトラフィックのための標準サービスクラスO。トラフィックVoIPベアラ（電話）用のOテレフォニーサービスクラス。 Oテレフォニーのためのシグナリングサービスクラスは、VoIPサービスを制御するためのシグナリング。 O低遅延保証帯域幅の差別化データサービスのための低遅延のデータサービスクラス。ネットワークの運用と管理のためのO OAMサービスクラス。
Figure 5 provides a summary of the mechanisms needed for delivery of service differentiation for Example 1.
図5は、実施例1のサービスの差別化の送達のために必要な機構の概要を提供します。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 5. Service Provider Network Configuration Example 1
図5.サービスプロバイダーネットワークの構成例1
Notes for Figure 5:
図5のための注意事項：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697. o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
O「SR + BS」バーストサイズ制御を有する単一速度を提供するポリシングメカニズムを表します。 Oシングルレートは、三色マーカー（srTCM）現象が標準サービスクラスを使用して転送されるべきサポートされるサービス・クラスによって表されていないDSCP値でマークされた任意のパケットO RFC 2697.と同等であるべきです。
With this example, we show how network operators with Example 1 capabilities can evolve their service offering to provide three new additional services to their customers. The new additional service capabilities that are to be added are:
この例では、我々は1つの機能は、彼らのサービスの提供を進化させることができます例で、ネットワークオペレータは顧客に3つの新しい付加的なサービスを提供する方法を示しています。追加される新しい追加のサービス機能は以下のとおりです。
o SIP-based desktop video conference capability to complement VoIP (telephony) service. o TV and on-demand movie viewing service to residential subscribers. o Network-based data storage and file backup service to business customers.
O SIPベースのデスクトップビデオ会議機能は、VoIP（電話）サービスを補完します。個人加入者へのOテレビ、オンデマンドの映画視聴サービス。ビジネスのお客様にO、ネットワーク・ベースのデータ・ストレージとファイルバックアップサービス。
The new additional services that the network administrator would like to offer are addressed with the deployment of the following four additional service classes (these are additions to the six service classes already defined in Example 1):
ネットワーク管理者が提供したいと思い、新たな追加サービスは、以下の4つの追加のサービスクラス（これらはすでに実施例1で定義された6つのサービスクラスに追加されている）の展開に対処されています。
o Real-Time Interactive service class for transport of MPEG-4 real-time video flows to support desktop video conferencing. The control/signaling for video conferencing is done using the Signaling service class. o Broadcast Video service class for transport of IPTV broadcast information. The channel selection and control is via IGMP mapped into the Signaling service class. o Multimedia Streaming service class for transport of stored MPEG-2 or MPEG-4 content. The selection and control of streaming information is done using the Signaling service class. The selection of Multimedia Streaming service class for on-demand movie service was chosen as the set-top box used for this service has local buffering capability to compensate for the bandwidth variability of the elastic streaming information. Note that if transport of on-demand movie service is inelastic, then the Broadcast Video service class SHOULD be used. o High-Throughput Data service class is for transport of bulk data for network-based storage and file backup service to business customers.
MPEG-4リアルタイム・ビデオの輸送のためのOリアルタイムインタラクティブサービスクラスは、デスクトップビデオ会議をサポートするために流れます。ビデオ会議のための制御/シグナリングは、シグナリングサービスクラスを使用して行われます。 O IPTVの輸送用放送ビデオサービスクラスは、情報を放送します。 IGMPシグナリングサービスクラスにマッピングを介してチャネル選択と制御です。記憶されたMPEG-2またはMPEG-4コンテンツの輸送のためのOマルチメディアストリーミングサービスクラス。選択とストリーミング情報の制御は、シグナリングサービスクラスを使用して行われます。このサービスのために使用されたセットトップボックスは、弾性ストリーミング情報の帯域幅の変動を補償するためのローカルバッファリング機能を持っているとして、オンデマンド映画サービスのためのマルチメディアストリーミングサービスクラスの選択が選ばれました。オンデマンド映画サービスのトランスポートが非弾性である場合、放送ビデオサービスクラスを使用する必要があることに注意してください。 Oハイスループットデータサービスクラスは、ビジネス顧客へのネットワーク・ベースのストレージとファイルバックアップサービスのための大量のデータを輸送するためです。
Figure 6 provides a summary of the mechanisms needed for delivery of service differentiation for all the service classes used in Example 2.
図6は、実施例2で使用されるすべてのサービスクラスのサービスの差別化の送達のために必要な機構の概要を提供します。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+-------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | |Yes |
| Streaming | AF32 |three-color marker | RFC2597 | Rate |per |
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | |Yes |
| Latency | AF22 |three-color marker | RFC2597 | Rate |per |
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate |Yes |
| | +other| | | | |
-------------------------------------------------------------------
Figure 6. Service Provider Network Configuration Example 2
図6.サービスプロバイダーネットワークの構成例2
Notes for Figure 6:
図6のための注意事項：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698.
O「SR + BS」バーストサイズ制御を有する単一速度を提供するポリシングメカニズムを表します。シングルレートO、三色マーカー（srTCM）の動作は、RFC 2697と同等であるべきであり、二速度3色マーカー（trTCM）の動作は、RFC 2698と同等であるべきです。
o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
Oサポートサービスクラスで表現されていないDSCP値でマーキングされたすべてのパケットは、標準的なサービスクラスを使用して転送する必要があります。
An enterprise network administrator determines that they need to provide different performance levels (quality of service) in their network for the new services that are being offered to corporate users. The enterprise network needs to:
企業のネットワーク管理者は、彼らが企業ユーザーに提供されている新しいサービスのために、ネットワーク内の異なるパフォーマンスレベル（サービス品質）を提供する必要があると判断します。企業ネットワークは、する必要があります：
o Provide reliable corporate VoIP service. o Provide video conferencing service to selected Conference Rooms. o Support on-demand distribution of prerecorded audio and video information to large number of users. o Provide a priority data transfer capability for engineering teams to share design information. o Reduce or deny bandwidth during peak traffic periods for selected applications. o Continue to provide normal IP service to all remaining applications and services.
O信頼性の高い企業のVoIPサービスを提供します。 O選択した会議室にビデオ会議サービスを提供します。多数のユーザーに事前に録音されたオーディオおよびビデオ情報のOサポートオンデマンド配信。 Oエンジニアリングチームが設計情報を共有するための優先度のデータ転送能力を提供します。 O選択したアプリケーションのトラフィックのピーク時間帯に帯域幅を減らすか、または拒否します。 O残りのすべてのアプリケーションとサービスに正常なIPサービスを提供し続けます。
For this example, the enterprise's network needs are addressed with the deployment of the following nine service classes:
この例では、企業のネットワークのニーズは、以下の9つのサービスクラスの展開に対処されています。
o Network Control service class for routing and control traffic that is needed for reliable operation of the enterprise network. o OAM service class for operation and management of the network. o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment. o Telephony service class for VoIP (telephony) bearer traffic. o Signaling service class for Telephony signaling to control the VoIP service. o Multimedia Conferencing service class for support of inter-Conference Room video conferencing service using H.323/V2 or similar equipment. o Multimedia Streaming service class for transfer of prerecorded audio and video information. o High-Throughput Data service class to provide bandwidth assurance for timely transfer of large engineering files. o Low-Priority Data service class for selected background applications where data transfer can be delayed or suspended for a period of time during peak network load conditions.
企業ネットワークの信頼性の高い動作のために必要とされるルーティングおよび制御トラフィック用のOネットワーク制御サービスクラス。ネットワークの運用と管理のためのO OAMサービスクラス。正常（未分化）転送処理を受信するすべてのトラフィックのためのO規格サービスクラス。トラフィックVoIPベアラ（電話）用のOテレフォニーサービスクラス。 Oテレフォニーのためのシグナリングサービスクラスは、VoIPサービスを制御するためのシグナリング。 H.323 / V2または同様の装置を使用してインター会議室ビデオ会議サービスのサポートのためのOのマルチメディア会議サービスクラス。事前に録音されたオーディオおよびビデオ情報の転送のためのOのマルチメディアストリーミングサービスクラス。 Oハイスループットデータサービスクラスは、大規模なエンジニアリング・ファイルのタイムリーな転送のための帯域幅保証を提供します。データ転送は、ピークネットワークの負荷状態の間の時間だけ遅延または中断することができる選択されたバックグラウンドアプリケーション用のO低優先度のデータサービスクラス。
Figure 7 provides a summary of the mechanisms needed for delivery of service differentiation for Example 3.
図7は、実施例3のサービス差別化の送達のために必要な機構の概要を提供します。
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 | three-color marker| RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 | three-color marker| RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 7. Enterprise Network Configuration Example
図7.エンタープライズネットワークの構成例
Notes for Figure 7:
図7のための注意事項：
o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class.
O「SR + BS」バーストサイズ制御を有する単一速度を提供するポリシングメカニズムを表します。 Oシングルレートは、三色マーカー（srTCM）の動作は、RFC 2697と同等であるべきであり、二速度3色マーカー（trTCM）現象がDSCPでマークされたすべてのパケットO RFC 2698と同等であるべきですサポートされているサービスクラスで表現されていない値は、標準的なサービスクラスを使用して転送する必要があります。
Network control traffic is defined as packet flows that are essential for stable operation of the administered network as well as for information that may be exchanged between neighboring networks across a peering point where SLAs are in place. Network control traffic is different from user application control (signaling) that may be generated by some applications or services. Network control traffic is mostly between routers and network nodes that are used for operating, administering, controlling, or managing the network segments. Network Control Traffic may be split into two service classes, i.e., Network Control and OAM.
ネットワーク制御トラフィックを投与ネットワークの安定動作のために、ならびにSLAは所定の位置にあるピアリングポイントを横切って隣接するネットワークの間で交換される情報のために必須であるパケットフローとして定義されます。ネットワーク制御トラフィックは、いくつかのアプリケーションまたはサービスによって生成することができるユーザーアプリケーション制御（シグナリング）とは異なります。ネットワーク制御トラフィックは、動作管理、制御、またはネットワークセグメントを管理するために使用されるルータとネットワークノードとの間に大部分です。ネットワーク制御トラフィックは、2つのサービスクラス、すなわち、ネットワーク制御およびOAMに分割することができます。
Based on today's routing protocols and network control procedures that are used in the Internet, we have determined that CS6 DSCP value SHOULD be used for routing and control and that CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols. Network administrators MAY use a Local/Experimental DSCP; therefore, they may use a locally defined service class within their network to further differentiate their routing and control traffic.
インターネットで使用されている今日のルーティングプロトコルおよびネットワーク制御手順に基づいて、我々はCS6のDSCP値は、ルーティングおよび制御のためにとCS7 DSCP値が潜在的に将来のルーティングや制御プロトコルのために、将来の使用のために予約する必要があることに使用されるべきであると決定しました。ネットワーク管理者は、ローカル/実験DSCPを使用することができます。従って、それらは、さらに、それらのルーティングおよび制御トラフィックを区別するために、ネットワーク内でローカルに定義されたサービスクラスを使用することができます。
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
CS7 DSCPがパケットをマークするために、ネットワークのエッジコンディショニングを推奨：
o Drop or remark CS7 packets at ingress to DiffServ network domain. o CS7 marked packets SHOULD NOT be sent across peering points. Exchange of control information across peering points SHOULD be done using CS6 DSCP and the Network Control service class.
OのDiffServネットワークドメインへの入口でCS7パケットをドロップしたり発言。 O CS7マークされたパケットは、ピアリングポイントを介して送信されるべきではありません。ピアリングポイント間の制御情報の交換は、CS6 DSCPおよびネットワーク制御サービスクラスを使用して行われるべきです。
The Network Control service class is used for transmitting packets between network devices (routers) that require control (routing) information to be exchanged between nodes within the administrative domain as well as across a peering point between different administrative domains. Traffic transmitted in this service class is very important as it keeps the network operational, and it needs to be forwarded in a timely manner.
ネットワーク制御サービスクラスは、制御管理ドメイン内ならびに異なる管理ドメイン間のピアリングポイントを横切ってノード間で交換される（ルーティング）情報を必要とするネットワークデバイス（ルータ）間でパケットを送信するために使用されます。それは運用ネットワークを維持して、このサービスクラスに送信されたトラフィックが非常に重要であり、それがタイムリーに転送する必要があります。
The Network Control service class SHOULD be configured using the DiffServ Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured so that the traffic receives a minimum bandwidth guarantee, to ensure that the packets always receive timely service. The configured forwarding resources for Network Control service class SHOULD be such that the probability of packet drop under peak load is very low in this service class. The Network
ネットワーク制御サービスクラスは、[RFC2474]で定義されたDiffServクラスセレクタ（CS）PHBを用いて構成されるべきです。トラフィックは、パケットは、常にタイムリーなサービスを受けることを保証するために、最低帯域保証を受けるように、このサービスクラスを設定する必要があります。ネットワーク制御サービスクラスの設定された転送リソースは、ピーク時の負荷の下でパケットのドロップの確率は、このサービスクラスでは非常に低いようなものであるべきです。ネットワーク
Control service class SHOULD be configured to use a Rate Queuing system such as defined in Section 1.4.1.2 of this document.
Controlサービスクラスには、このドキュメントのセクション1.4.1.2で定義されたレート・キューイング・システムを使用するように設定する必要があります。
The following are examples of protocols and applications that SHOULD use the Network Control service class:
ネットワーク制御サービスクラスを使用すべきであるプロトコルやアプリケーションの例を以下に示します。
o Routing packet flows: OSPF, BGP, ISIS, RIP. o Control information exchange within and between different administrative domains across a peering point where SLAs are in place. o LSP setup using CR-LDP and RSVP-TE.
Oルーティングパケットフロー：OSPF、BGP、ISIS、RIP。 OのSLAが適所にあるピアリングポイント間で異なる管理ドメイン内および間の情報交換を制御します。 CR-LDPおよびRSVP-TEを用いたO LSPセットアップ。
The following protocols and applications SHOULD NOT use the Network Control service class:
次のプロトコルおよびアプリケーションは、ネットワーク制御サービスクラスを使用しないでください。
o User traffic.
Oユーザトラフィック。
The following are traffic characteristics of packet flows in the Network Control service class:
以下は、ネットワーク制御サービスクラスにおけるパケットフローのトラフィック特性であります：
o Mostly messages sent between routers and network servers. o Variable size packets, normally one packet at a time, but traffic can also burst (BGP). o User traffic is not allowed to use this service class. By user traffic, we mean packet flows that originate from user-controlled end points that are connected to the network.
ルータやネットワークサーバとの間で送信されるO大抵のメッセージ。 O可変サイズのパケット、通常、一度パケットが、トラフィックはまた、（BGP）をバーストすることができます。 Oユーザトラフィックは、このサービスクラスを使用することを許可されていません。ユーザトラフィックによって、我々は、ネットワークに接続されたユーザ制御エンドポイントから発信パケットフローを意味します。
The RECOMMENDED DSCP marking is CS6 (Class Selector 6).
マーキング推奨DSCPはCS6（クラスセレクタ6）です。
RECOMMENDED Network Edge Conditioning:
推奨ネットワークエッジコンディショニング：
o At peering points (between two DiffServ networks) where SLAs are in place, CS6 marked packets SHOULD be policed, e.g., using a single rate with burst size (sr+bs) token bucket policer to keep the CS6 marked packet flows to within the traffic rate specified in the SLA. o CS6 marked packet flows from untrusted sources (for example, end user devices) SHOULD be dropped or remarked at ingress to the DiffServ network. o Packets from users/subscribers are not permitted access to the Network Control service classes.
O SLAは所定の位置にある場合（二のDiffServネットワーク間）の点をピアリングで、CS6はCS6著しいパケット内に流れる維持するバーストサイズ（SR + BS）トークンバケットポリシングと単一レートを使用して、パケットは、例えば、ポリシングされるべきであるとマークSLAで指定されたトラフィックレート。 O CS6マークされたパケットは、信頼できないソースから流れ（例えば、エンドユーザデバイス）を滴下またはDiffServのネットワークへの入口で注目されるべきです。 Oユーザ/加入者からのパケットは、ネットワーク制御サービスクラスへのアクセスを許可されていません。
The fundamental service offered to the Network Control service class is enhanced best-effort service with high bandwidth assurance. Since this service class is used to forward both elastic and inelastic flows, the service SHOULD be engineered so that the Active Queue Management (AQM) [RFC2309] is applied to CS6 marked packets.
ネットワーク制御サービスクラスに提供される基本的なサービスは、高帯域幅保証付きのベストエフォート型サービスを強化しています。このサービス・クラスは、弾性及び非弾性の両方のフローを転送するために使用されているので、アクティブキュー管理（AQM）[RFC2309]はCS6マーキングされたパケットに適用されるように、サービスは、操作されるべきです。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は、ターゲット・キューの深さを指定し、および最大閾値は、すべてのトラフィックが廃棄されるか、ECNがマークされている上に、キューの深さを指定します。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold CS6 < max-threshold CS6 o max-threshold CS6 <= memory assigned to the queue
キューに割り当てられO最小閾値CS6 <MAX-閾値CS6 O最大しきい値CS6 <=メモリ
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The OAM (Operations, Administration, and Management) service class is RECOMMENDED for OAM&P (Operations, Administration, and Management and Provisioning) using protocols such as Simple Network Management Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, and Common Open Policy Service (COPS). Applications using this service class require a low packet loss but are relatively not sensitive to delay. This service class is configured to provide good packet delivery for intermittent flows.
OAM（運用、管理、および管理）サービスクラスは、このような簡易ネットワーク管理プロトコル（SNMP）、簡易ファイル転送プロトコル（TFTP）、FTP、Telnetの、などのプロトコルを使用してOAM＆P（運用、管理、および管理とプロビジョニング）に推奨されますそして、共通オープンポリシーサービス（COPS）。このサービスクラスを使用するアプリケーションは、低パケット損失を必要とするが、比較的遅延に敏感ではありません。このサービスクラスは、断続的な流れのための良好なパケット配信を提供するように構成されています。
The OAM service class SHOULD use the Class Selector (CS) PHB defined in [RFC2474]. This service class SHOULD be configured to provide a minimum bandwidth assurance for CS2 marked packets to ensure that they get forwarded. The OAM service class SHOULD be configured to use a Rate Queuing system such as defined in Section 1.4.1.2 of this document.
OAMサービスクラスは、[RFC2474]で定義されたクラスセレクタ（CS）PHBを使用すべきです。このサービスクラスは、それらが転送されますことを確認するために、CS2マークされたパケットのための最小帯域保証を提供するために設定する必要があります。 OAMサービスクラスには、このドキュメントのセクション1.4.1.2で定義されたレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the OAM service class:
以下のアプリケーションは、OAMサービスクラスを使用する必要があります。
o Provisioning and configuration of network elements. o Performance monitoring of network elements. o Any network operational alarms.
Oプロビジョニングおよびネットワーク要素の構成。ネットワーク要素のOパフォーマンスの監視。任意のネットワーク運用のアラームO。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o Intermittent traffic flows. o Traffic may burst at times. o Both elastic and inelastic flows. o Traffic not sensitive to delays.
可変サイズのパケットO。 O断続的なトラフィックが流れます。 Oトラフィックが倍に破裂することがあります。 O弾性および非弾性の両方が流れます。遅延に敏感ではないOトラフィック。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o All flows in this service class are marked with CS2 (Class Selector 2).
Oこのサービス・クラス内のすべてのフローは、CS2（クラスセレクタ2）が付いています。
Applications or IP end points SHOULD pre-mark their packets with CS2 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
アプリケーションまたはIPエンドポイントは、CS2 DSCP値とのパケットを事前にマークすべきです。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を実行する必要があります。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (routers inside administered network) MAY not require policing. o Normally OAM&P CS2 marked packet flows are not allowed to flow across peering points. If that is the case, then CS2 marked packets SHOULD be policed (dropped) at both egress and ingress peering interfaces.
O信頼できないソース（エンドユーザデバイス）から（DSCP設定）マーキングパケットフローは[RFC2475]で定義された多門（MF）の分類方法を用いてのDiffServネットワークへの入口で確認してください。 Oパケットは、信頼できないソース（エンドユーザデバイス）からのトラフィックフローがネゴシエート又は操作限界内に留まることを保証するために、バーストサイズ、トークンバケットポリサーで単一レートを使用して、例えば、DiffServのネットワークへの入口でポリシングされるべきです。 Oパケットは、信頼できるソース（投与ネットワーク内部ルータ）から流れポリシングを必要としません。 O通常OAM＆P CS2マークされたパケットフローは、ピアリングポイントを横切って流れることができません。その場合は、次にCS2マーキングされたパケットは、ポリシングされるべきである出入りピアリングインターフェイスの両方に（滴下）。
The fundamental service offered to "OAM" traffic is enhanced best-effort service with controlled rate. The service SHOULD be engineered so that CS2 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since this service class is used to forward both elastic and inelastic flows, the service SHOULD be engineered so that Active Queue Management [RFC2309] is applied to CS2 marked packets.
「OAM」トラフィックに提供される基本的なサービスは、制御された速度で強化され、ベストエフォート型のサービスです。 CS2マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。このサービスクラスは、弾性および非弾性の両方のフローを転送するために使用されているので、アクティブキュー管理[RFC2309]はCS2マークされたパケットに適用されるように、サービスが設計される必要があります。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は各DSCPのためのターゲット・キューの深さを指定し、および最大しきい値がその上キューの深さを指定するようDSCPを持つすべてのトラフィックは廃棄されるか、ECNがマーク。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold CS2 < max-threshold CS2 o max-threshold CS2 <= memory assigned to the queue
キューに割り当てられたO分しきい値CS2 <最大しきい値CS2 O最大しきい値CS2 <=メモリ
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services. User traffic can be differentiated in many different ways; therefore, we investigated several different approaches to classifying user traffic. We looked at differentiating user traffic as real-time versus non-real-time, elastic or rate-adaptive versus inelastic, sensitive versus insensitive to loss as well as traffic categorization as interactive, responsive, timely, and non-critical, as defined in ITU-T Recommendation G.1010. In the final analysis, we used all of the above for service differentiation, mapping application types that seemed to have different sets of performance sensitivities, and requirements to different service classes.
パケットが別のユーザまたは加入者との間を流れるように、ユーザトラフィックが定義されています。これは、または終端端末から送信されたトラフィックであり、それは、アプリケーションやサービスの非常に多種多様をサポートしています。ユーザートラフィックは、多くの異なる方法で区別することができます。そのため、我々は、ユーザトラフィックを分類するには、いくつかの異なるアプローチを検討しました。で定義されている私たちは、インタラクティブな応答、タイムリー、かつ非クリティカルとして損失だけでなく、トラフィックの分類に鈍感対敏感、非弾性対弾性またはレート適応、非リアルタイム対リアルタイムとしてユーザトラフィックを差別見ITU-T勧告G.1010。最終的な分析では、我々は、サービスの差別化のために異なるサービスクラスにパフォーマンスの感度、および要件の異なるセットを持っているように見えたマッピングアプリケーションの種類を上記のすべてを使用していました。
Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes. Figure 3 provides some common applications and the forwarding service classes that best support them, based on their performance requirements.
ネットワーク管理者は、彼らが必要とするすべて、または定義されたサービスクラスのサブセットをサポートすることを選ぶかもしれ行動の種類に応じてアプリケーションを分類することができます。図3は、彼らのパフォーマンス要件に基づいて、最高のそれらをサポートするいくつかの一般的なアプリケーションや転送サービスクラスを提供します。
The Telephony service class is RECOMMENDED for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service.
テレフォニーサービスクラスは、リアルタイム、非常に低遅延、非常に低ジッタ、および比較的一定のレートトラフィックソースの非常に低いパケット損失（非弾性トラフィックソース）を必要とするアプリケーションに推奨されます。このサービスクラスは、IP電話サービスのために使用されるべきです。
The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. Operation is in some respect similar to an ATM CBR service, which has guaranteed bandwidth and which, if it stays within the negotiated rate, experiences nominal delay and no loss. The EF PHB has a similar guarantee.
テレフォニーサービスクラスのトラフィックに提供される基本的なサービスは、指定された上限に最小ジッタ、遅延、およびパケット損失のサービスまであります。それが交渉率の範囲内にとどまる場合の動作は、帯域幅を保証しているATM CBRサービス、に似たいくつかの点であり、公称遅延や損失なしを経験します。 EF PHBは同様の保証を持っています。
Typical configurations negotiate the setup of telephone calls over IP, using protocols such as H.248, MEGACO, H.323, or SIP. When a user has been authorized to send telephony traffic, the call admission procedure should have verified that the newly admitted flow will be within the capacity of the Telephony service class forwarding capability in the network. For VoIP (telephony) service, call admission control is usually performed by a telephony call server/ gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on access points to the network. The bandwidth in the core network and the number of simultaneous VoIP sessions that can be supported needs to be engineered and controlled so that there is no congestion for this service. Since the inelastic types of RTP payloads in this class do not react to loss or significant delay in any substantive way, the Telephony service class SHOULD forward packets as soon as possible. Some RTP payloads that may be used in telephony applications are adaptive and will not be in this class.
典型的な構成は、このようなH.248、MEGACO、H.323、またはSIPなどのプロトコルを使用して、IP経由の通話の設定を交渉します。ユーザーは、テレフォニートラフィックを送信することを許可された場合には、呼受付手順は、新たに入院フローは、ネットワーク内のテレフォニーサービスクラスの転送機能の能力の範囲内になることを確認しておく必要があります。 VoIPの（電話）サービスのために、アドミッション制御は、通常、ネットワークへのアクセスポイントにシグナリング（SIP、H.323、H.248、MEGACO、等）を使用して電話通話サーバ/ゲートキーパーによって実行される呼び出し。このサービスのための輻輳がないようにサポートすることができ、コアネットワークにおける帯域幅と同時のVoIPセッションの数は、設計および制御する必要があります。このクラスのRTPペイロードの非弾性タイプは任意の実質的な方法で損失または大幅な遅延には反応しないので、テレフォニーサービスクラスは、できるだけ早くパケットを転送すべきです。テレフォニーアプリケーションで使用することができるいくつかのRTPペイロードは、適応型であり、このクラスではありません。
The Telephony service class SHOULD use Expedited Forwarding (EF) PHB, as defined in [RFC3246], and SHOULD be configured to receive guaranteed forwarding resources so that all packets are forwarded quickly. The Telephony service class SHOULD be configured to use a Priority Queuing system such as that defined in Section 1.4.1.1 of this document.
[RFC3246]で定義され、そしてすべてのパケットが迅速に転送されるように保証転送リソースを受信するように構成されるべきであるテレフォニーサービスクラスが、緊急転送（EF）PHBを使用すべきです。テレフォニーサービスクラスは、このドキュメントのセクション1.4.1.1で定義されているようなプライオリティキューイングシステムを使用するように設定する必要があります。
The following applications SHOULD use the Telephony service class:
次のアプリケーションは、テレフォニーサービスクラスを使用する必要があります。
o VoIP (G.711, G.729 and other codecs). o Voice-band data over IP (modem, fax). o T.38 fax over IP. o Circuit emulation over IP, virtual wire, etc. o IP Virtual Private Network (VPN) service that specifies single-rate, mean network delay that is slightly longer then network propagation delay, very low jitter, and a very low packet loss.
OのVoIP（G.711、G.729、および他のコーデック）。 IPオーバーO音声帯域データ（モデム、ファックス）。 IP経由OのT.38ファックス。 O IP、仮想ワイヤなどのIP Oシングルレートを指定する仮想プライベートネットワーク（VPN）サービスオーバー回線エミュレーションは、少し長いその後、伝搬遅延、非常に低ジッタ、および非常に低いパケットロスをネットワークであるネットワーク遅延を意味します。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in size). o Packets emitted at constant time intervals. o Admission control of new flows is provided by telephony call server, media gateway, gatekeeper, edge router, end terminal, or access node that provides flow admission control function.
VoIPのためのOほとんど固定サイズのパケット（サイズ60、70、120または200バイト）。 Oパケットは、一定の時間間隔で放出されました。 O新しいフローのアドミッション制御は、フローアドミッション制御機能を提供する電話コールサーバ、メディアゲートウェイ、ゲートキーパー、エッジルータ、エンド端末、またはアクセス・ノードによって提供されます。
Applications or IP end points SHOULD pre-mark their packets with EF DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
アプリケーションまたはIPエンドポイントは、EF DSCP値とのパケットを事前にマークすべきです。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を実行する必要があります。
The RECOMMENDED DSCP marking is EF for the following applications:
マーキング推奨DSCPは、次のアプリケーションのためのEFです。
o VoIP (G.711, G.729 and other codecs). o Voice-band data over IP (modem and fax). o T.38 fax over IP. o Circuit emulation over IP, virtual wire, etc.
OのVoIP（G.711、G.729、および他のコーデック）。 IPオーバーO音声帯域データ（モデムやファックス）。 IP経由OのT.38ファックス。 IP経由O回線エミュレーション、仮想ワイヤなど
RECOMMENDED Network Edge Conditioning:
推奨ネットワークエッジコンディショニング：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the telephony traffic stays within its negotiated bounds.
O信頼できないソース（エンドユーザデバイス）から（DSCP設定）マーキングパケットフローは[RFC2475]で定義された多門（MF）の分類方法を用いてのDiffServネットワークへの入口で確認してください。 Oパケットは、信頼できないソース（エンドユーザデバイス）から流れ電話トラフィックがネゴシエート境界内に留まることを保証するために、バーストサイズ、トークンバケットポリサーで単一レートを使用して、例えば、DiffServのネットワークへの入口でポリシングされるべきです。
o Policing is OPTIONAL for packet flows from trusted sources whose behavior is ensured via other means (e.g., administrative controls on those systems). o Policing of Telephony packet flows across peering points where SLA is in place is OPTIONAL as telephony traffic will be controlled by admission control mechanism between peering points.
パケットは、その動作の他の手段（それらのシステム上の例えば、管理コントロール）を介して確保され、信頼できるソースから流れるためのOポリシングは任意です。 Oテレフォニーパケットのポリシングは、SLAは、電話トラフィックがピアリングポイント間アドミッション制御機構によって制御されるような任意の場所であるピアリング点を横切って流れます。
The fundamental service offered to "Telephony" traffic is enhanced best-effort service with controlled rate, very low delay, and very low loss. The service MUST be engineered so that EF marked packet flows have sufficient bandwidth in the network to provide guaranteed delivery. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF marked packet flows.
基本的なサービスは、「テレフォニー」のトラフィックが制御された速度、非常に低遅延、および非常に低損失のベストエフォート型サービスを強化していることを申し出ました。 EFマークされたパケットフローが保証された配信を提供するために、ネットワーク内に十分な帯域幅を持つようにサービスを設計しなければなりません。通常、このサービスクラスのトラフィックは、パケットロスに動的に対応しません。そのため、アクティブキュー管理[RFC2309]はEFマークされたパケットフローに適用されるべきではありません。
The Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between IP phone and soft-switch, soft-client and soft-switch, and media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. Applications using this service class require a relatively fast response, as there are typically several messages of different sizes sent for control of the session. This service class is configured to provide good response for short-lived, intermittent flows that require real-time packet forwarding. To minimize the possibility of ring clipping at start of call for VoIP service that interfaces to a circuit switch Exchange in the Public Switched Telephone Network (PSTN), the Signaling service class SHOULD be configured so that the probability of packet drop or significant queuing delay under peak load is very low in IP network segments that provide this interface. The term "ring clipping" refers to those instances where the front end of a ringing signal is altered because the bearer path is not made available in time to carry all of the audible ringing signal. This condition may occur due to a race condition between when the tone generator in the circuit switch Exchange is turned on and when the bearer path through the IP network is enabled. See Section 8.1 for additional explanation of "ring clipping" and Section 5.1 for explanation of mapping different signaling methods to service classes.
シグナリングサービスクラスは、遅延に敏感なクライアント - サーバー（従来の電話）とピア・ツー・ピアアプリケーションシグナリングをお勧めします。テレフォニーシグナリングは、様々なプロトコルを使用して、IP電話機、ソフトスイッチ、ソフトクライアントとソフトスイッチ、メディアゲートウェイとソフトスイッチ、並びにピア・ツー・ピア間のシグナリングを含みます。このサービスクラスはセッションとアプリケーションの制御に使用されることを意図しています。通常、セッションの制御のために送られた大きさの異なるいくつかのメッセージがあるとして、このサービスクラスを使用するアプリケーションは、比較的高速応答を必要としています。このサービスクラスは、リアルタイムのパケット転送を必要と短命、断続的な流れのための良好な応答を提供するように構成されています。公衆交換電話網（PSTN）の回路スイッチExchangeにインタフェースするVoIPサービスのためのコールの開始時にクリップリングの可能性を最小限にするために、シグナリングサービスクラスは、下パケットドロップまたは重要キューイング遅延の確率ように構成されるべきですピーク負荷は、このインタフェースを提供し、IPネットワークセグメントでは非常に低いです。用語「環クリッピング」は、ベアラ・パスが、可聴リンギング信号のすべてを運ぶために時間内に利用可能にされていないため、リンギング信号のフロントエンドが変更されたそれらのインスタンスを指します。この状態は、回路スイッチExchange内の音源がオンされると、IPネットワークを介してベアラ・パスが有効になっている場合との間の競合状態を発生する可能性があります。 「リングクリッピング」とサービスクラスへのマッピング異なるシグナリング方法の説明については、セクション5.1の追加説明については、セクション8.1を参照してください。
The Signaling service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide a minimum bandwidth assurance for CS5 marked packets to ensure that they get forwarded. The Signaling service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
シグナリングサービスクラスは、[RFC2474]で定義されたクラスセレクタ（CS）PHBを使用する必要があります。このサービスクラスは、それらが転送されますことを確認するために、CS5マークされたパケットのための最小帯域保証を提供するために設定する必要があります。シグナリングサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the Signaling service class:
以下のアプリケーションは、シグナリングサービスクラスを使用する必要があります。
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323). o Peer-to-peer signaling for multimedia applications (e.g., using SIP, H.323). o Peer-to-peer real-time control function. o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP encapsulated ISDN, or other proprietary protocols. o Signaling to control IPTV applications using protocols such as IGMP. o Signaling flows between high-capacity telephony call servers or soft switches using protocol such as SIP-T. Such high-capacity devices may control thousands of telephony (VoIP) calls.
OピアツーピアIPテレフォニーシグナリング（例えば、H.323、SIPを使用して）。 Oピアツーピア（例えば、SIP、H.323を使用して）マルチメディアアプリケーションのためのシグナリング。 Oピア・ツー・ピア・リアルタイム制御機能。 H.248、MEGACO、MGCPを使用したクライアントサーバーIPテレフォニーシグナリングO、IPは、ISDN、またはその他の独自のプロトコルをカプセル化。例えばIGMPなどのプロトコルを使用してIPTVアプリケーションを制御するシグナリングO。 Oシグナリングは、SIP-Tなどのプロトコルを使用して大容量のテレフォニーコールサーバまたはソフトスイッチとの間を流れます。このような大容量のデバイスは、電話の数千人（VoIP）の通話を制御することができます。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets, normally one packet at a time. o Intermittent traffic flows. o Traffic may burst at times. o Delay-sensitive control messages sent between two end points.
O可変サイズのパケット、一度に通常一つのパケット。 O断続的なトラフィックが流れます。 Oトラフィックが倍に破裂することがあります。 O遅延に敏感な制御メッセージは、二つのエンドポイント間で送信されます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o All flows in this service class are marked with CS5 (Class Selector 5).
Oこのサービス・クラス内のすべてのフローは、CS5（クラスセレクタ5）が付いています。
Applications or IP end points SHOULD pre-mark their packets with CS5 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
アプリケーションまたはIPエンドポイントは、CS5 DSCP値とのパケットを事前にマークすべきです。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を実行する必要があります。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
信頼できないソース（エンドユーザデバイス）から（DSCP設定）マーキングOパケットフローは、[RFC2475]で定義された多門（MF）の分類方法を用いてのDiffServネットワークへの入口で確認してください。 Oパケットは、信頼できないソース（エンドユーザデバイス）からのトラフィックフローがネゴシエート又は操作限界内に留まることを保証するために、バーストサイズ、トークンバケットポリサーで単一レートを使用して、例えば、DiffServのネットワークへの入口でポリシングされるべきです。 Oパケットは、信頼できるソース（投与ネットワーク内のアプリケーションサーバ）から流れポリシングを必要としません。 Oパケットのポリシングポイントをピアリングを横切って流れるのサービスレベル契約（SLA）に行われるべきです。
The fundamental service offered to "Signaling" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS5 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery and low delay. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 marked packet flows.
「シグナリング」トラフィックに提供される基本的なサービスは、制御された速度や遅延を強化ベストエフォート型のサービスです。 CS5マークされたパケットフローが配信と低遅延の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。通常、このサービスクラスのトラフィックは、パケットロスに動的に対応しません。そのため、アクティブキュー管理[RFC2309]はCS5マークされたパケットフローに適用されるべきではありません。
The Multimedia Conferencing service class is RECOMMENDED for applications that require real-time service for rate-adaptive traffic. H.323/V2 and later versions of video conferencing equipment with dynamic bandwidth adjustment are such applications. The traffic sources in this service class have the ability to dynamically change their transmission rate based on feedback from the receiver. One approach used in H.323/V2 equipment is, when the receiver detects a pre-configured level of packet loss, it signals to the transmitter the indication of possible on-path congestion. When available, the transmitter then selects a lower rate encoding codec. Note that today, many H.323/V2 video conferencing solutions implement fixed-step bandwidth change (usually reducing the rate), traffic resembling step-wise CBR.
マルチメディア会議サービスクラスは、レート適応型トラフィックのリアルタイムサービスを必要とするアプリケーションに推奨されます。 H.323 / V2及び動的帯域幅調整とビデオ会議機器のそれ以降のバージョンは、そのようなアプリケーションです。このサービスクラスのトラフィックソースを動的に受信機からのフィードバックに基づいて自分の伝送速度を変更する機能を持っています。 H.323 / V2の機器に使用される一つのアプローチは、受信機がパケット損失の事前設定されたレベルを検出した場合、それは送信機にオンパス輻輳可能の指示を信号です。利用可能な場合、送信機は、次に、低レート符号化コーデックを選択します。ステップワイズCBRに似ている今日、多くのH.323 / V2ビデオ会議ソリューションを実装固定ステップ帯域幅の変化（通常速度を低下させる）、トラフィックを注意してください。
Typical video conferencing configurations negotiate the setup of multimedia session using protocols such as H.323. When a user/end-point has been authorized to start a multimedia session, the admission procedure should have verified that the newly admitted data rate will be within the engineered capacity of the Multimedia Conferencing service class. The bandwidth in the core network and the number of simultaneous video conferencing sessions that can be supported SHOULD be engineered to control traffic load for this service.
典型的なビデオ会議の設定は、H.323などのプロトコルを使用してマルチメディアセッションのセットアップを交渉します。ユーザー/エンドポイントは、マルチメディアセッションを開始することを許可された場合は、入学手続きは、新たに入院データレートがマルチメディア会議サービスクラスの設計能力の範囲内になることを確認しておく必要があります。コアネットワーク内の帯域幅と同時にサポート可能なビデオ会議セッションの数は、このサービスのトラフィック負荷を制御するために設計される必要があります。
The Multimedia Conferencing service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a bandwidth assurance for AF41, AF42, and AF43 marked packets to ensure that they get forwarded. The Multimedia Conferencing service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
マルチメディア会議サービスクラスは、[RFC2597]で定義された保証転送（AF）PHBを使用する必要があります。このサービスクラスは、それらが転送され得ることを保証するために、AF41、AF42、AF43とマークされたパケットの帯域幅保証を提供するために設定する必要があります。マルチメディア会議サービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the Multimedia Conferencing service class:
以下のアプリケーションは、マルチメディア会議サービスクラスを使用する必要があります。
o H.323/V2 and later versions of video conferencing applications (interactive video).
O H.323 / V2およびビデオ会議アプリケーション（インタラクティブ・ビデオ）のそれ以降のバージョン。
o Video conferencing applications with rate control or traffic content importance marking. o Application server-to-application server non-bursty data transfer requiring very low delay. o IP VPN service that specifies two rates and mean network delay that is slightly longer then network propagation delay. o Interactive, time-critical, and mission-critical applications.
マーキング、レート制御またはトラフィックコンテンツの重要性を持つoビデオ会議アプリケーション。非常に低遅延を必要とするアプリケーションサーバとアプリケーションサーバの非バーストデータ転送を、O。 2つのレートを指定し、少し長いネットワーク伝播遅延、その後でネットワーク遅延を意味するO IP VPNサービス。 Oインタラクティブ、タイムクリティカル、およびミッションクリティカルなアプリケーション。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o The higher the rate, the higher the density of large packets. o Constant packet emission time interval. o Variable rate. o Source is capable of reducing its transmission rate based on detection of packet loss at the receiver.
可変サイズのパケットO。大きいパケットの密度レートが高いほど、O。 Oコンスタントパケットの発光時間間隔。変数o率。 Oソースは、受信機におけるパケットロスの検出に基づいて、その送信レートを低減することが可能です。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] and mark all packets as AF4x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
以下に示すようにアプリケーションまたはIPエンドポイントは、DSCP値と、それらのパケットを事前にマークする必要があり。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を行い、AF4xとしてすべてのパケットをマークするべきです。注：この場合、2つのレート、三色のマーカーは、色盲モードで動作するように構成されます。
RECOMMENDED DSCP marking when performed by router closest to source:
ルータ源に最も近いによって実行時にマーキングを推奨DSCP：
o AF41 = up to specified rate "A". o AF42 = in excess of specified rate "A" but below specified rate "B". o AF43 = in excess of specified rate "B". o Where "A" < "B".
指定されたレート "A" までAF41 = O。 AF42 =指定された速度「A」の過剰ではなく指定されたレート「B」以下、O。 O AF43 =指定されたレート「B」の過剰です。 Oどこに "A" < "B"。
Note: One might expect "A" to approximate the sum of the mean rates and "B" to approximate the sum of the peak rates.
注意：一つは、「A」は、ピークレートの和を近似する平均金利と「B」の合計値に近づけるために期待するかもしれません。
RECOMMENDED DSCP marking when performed by H.323/V2 video conferencing equipment:
H.323 / V2ビデオ会議機器によって実行される際にマーキングを推奨DSCP：
o AF41 = H.323 video conferencing audio stream RTP/UDP. o AF41 = H.323 video conferencing video control RTCP/TCP. o AF41 = H.323 video conferencing video stream up to specified rate "A". o AF42 = H.323 video conferencing video stream in excess of specified rate "A" but below specified rate "B". o AF43 = H.323 video conferencing video stream in excess of specified rate "B". o Where "A" < "B".
AF41 = H.323ビデオ会議のオーディオストリームRTP / UDP O。 O AF41 = H.323ビデオ会議ビデオ制御RTCP / TCP。 O AF41 = H.323ビデオ会議ビデオは、指定されたレート「A」までのストリーム。指定された速度「A」の過剰ではなく指定されたレート「B」以下O AF42 = H.323ビデオ会議ビデオストリーム。指定されたレート「B」を超えるO AF43 = H.323ビデオ会議ビデオストリーム。 Oどこに "A" < "B"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
trTCM [RFC2698]で定義されるように、O二速度3色マーカーは動作を提供するように構成されるべきです。パケットが信頼できるソースまたは以前に信頼のDiffServドメインとマーキング色でマークされている場合、O保存される、2つのレート、三色のマーカーは、カラー対応モードで動作するように構成されるべきです。マーキングパケットが信頼されていないか、または色マーキングが保存されるようにされていない場合はO、次いで二速度3色マーカーは、色盲モードで動作するように構成されるべきです。
The fundamental service offered to "Multimedia Conferencing" traffic is enhanced best-effort service with controlled rate and delay. For video conferencing service, typically a 1% packet loss detected at the receiver triggers an encoding rate change, dropping to the next lower provisioned video encoding rate. As such, Active Queue Management [RFC2309] SHOULD be used primarily to switch the video encoding rate under congestion, changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. The probability of loss of AF41 traffic MUST NOT exceed the probability of loss of AF42 traffic, which in turn MUST NOT exceed the probability of loss of AF43 traffic.
「マルチメディア会議」トラフィックに提供される基本的なサービスは、制御された速度や遅延を強化ベストエフォート型のサービスです。ビデオ会議サービスのために、受信機で検出され、典型的には1％のパケット損失は、次の下位プロビジョニングビデオ符号化レートに落とし、符号化率変更をトリガします。このように、アクティブキュー管理[RFC2309]は、高レートから低レート、768 kbpsの、すなわち、1472 kbpsに変更する、輻輳の下ビデオ符号化率を切り替えるために主に使用されるべきです。 AF41のトラフィックの損失の可能性は、順番にAF43のトラフィックの損失の可能性を超えてはならないAF42のトラフィックの損失の可能性を、超えてはなりません。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は各DSCPのためのターゲット・キューの深さを指定し、および最大しきい値がその上キューの深さを指定するようDSCPを持つすべてのトラフィックは廃棄されるか、ECNがマーク。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold AF43 < max-threshold AF43 o max-threshold AF43 <= min-threshold AF42 o min-threshold AF42 < max-threshold AF42 o max-threshold AF42 <= min-threshold AF41 o min-threshold AF41 < max-threshold AF41 o max-threshold AF41 <= memory assigned to the queue
O最小閾値AF43 <MAX-閾値AF43 0最大しきい値AF43 <=最小閾値AF42 O最小閾値AF42 <MAX-閾値AF42 0最大しきい値AF42 <=最小閾値AF41 O最小閾値AF41 <MAX-キューに割り当てられたしきい値AF41 0最大しきい値AF41 <=メモリ
Note: This configuration tends to drop AF43 traffic before AF42 and AF42 before AF41. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：この設定は、AF41の前にAF42とAF42 AF43前にトラフィックをドロップする傾向があります。他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The Real-Time Interactive service class is RECOMMENDED for applications that require low loss and jitter and very low delay for variable rate inelastic traffic sources. Interactive gaming and video conferencing applications that do not have the ability to change encoding rates or to mark packets with different importance indications are such applications. The traffic sources in this traffic class do not have the ability to reduce their transmission rate according to feedback received from the receiving end.
リアルタイムインタラクティブサービスクラスは、低損失およびジッタおよび可変レート非弾性トラフィックソースのための非常に低遅延を必要とするアプリケーションに推奨されます。エンコードレートを変更する機能を持っていないか、別の重要性を指摘してパケットをマークするインタラクティブゲームやビデオ会議アプリケーションでは、このようなアプリケーションです。このトラフィッククラスのトラフィックソースは、受信側から受け取ったフィードバックに基づいて自分の伝送速度を減少させる能力を持っていません。
Typically, applications in this service class are configured to negotiate the setup of RTP/UDP control session. When a user/end-point has been authorized to start a new session, the admission procedure should have verified that the newly admitted data rates will be within the engineered capacity of the Real-Time Interactive service class. The bandwidth in the core network and the number of simultaneous Real-time Interactive sessions that can be supported SHOULD be engineered to control traffic load for this service.
通常、このサービスクラスのアプリケーションは、RTP / UDP・コントロール・セッションのセットアップを交渉するように構成されています。ユーザー/エンドポイントは、新しいセッションを開始することを許可された場合は、入学手続きは、新たに入院データレートがリアルタイムインタラクティブサービスクラスの設計能力の範囲内になることを確認しておく必要があります。コアネットワーク内の帯域幅とサポートすることができ、同時にリアルタイムインタラクティブセッションの数は、このサービスのトラフィック負荷を制御するために設計される必要があります。
The Real-Time Interactive service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide a high assurance for bandwidth for CS4 marked packets to ensure that they get forwarded. The Real-Time Interactive service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document. Note that this service class MAY be configured as a second EF PHB that uses relaxed performance parameter, a rate scheduler, and CS4 DSCP value.
リアルタイムインタラクティブサービスクラスは、[RFC2474]で定義されたクラスセレクタ（CS）PHBを使用する必要があります。このサービスクラスは、それらが転送されますことを確認するために、CS4マークされたパケットのための帯域幅のための高い保証を提供するために設定する必要があります。リアルタイムインタラクティブサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。このサービス・クラスはリラックスした性能パラメータを使用する第2のEF PHB、レートスケジューラ、およびCS4 DSCP値として構成してもよいことに注意してください。
The following applications SHOULD use the Real-Time Interactive service class:
以下のアプリケーションは、リアルタイムのインタラクティブサービスクラスを使用する必要があります。
o Interactive gaming and control. o Video conferencing applications without rate control or traffic content importance marking. o IP VPN service that specifies single rate and mean network delay that is slightly longer then network propagation delay. o Inelastic, interactive, time-critical, and mission-critical applications requiring very low delay.
インタラクティブなゲームやコントロールO。レート制御やトラフィックのコンテンツの重要性マーキングなしoビデオ会議アプリケーション。シングルレートを指定し、少し長いネットワーク伝播遅延、その後でネットワーク遅延を意味するO IP VPNサービス。 O非弾性、インタラクティブ、タイムクリティカルな、そして非常に低遅延を必要とするミッションクリティカルなアプリケーション。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o Variable rate, non-bursty. o Application is sensitive to delay variation between flows and sessions. o Lost packets, if any, are usually ignored by application.
可変サイズのパケットO。 O変数率、非バースト性。 Oアプリケーションフローとセッションの間の変化を遅延に敏感です。 O失われたパケットは、もしあれば、通常、アプリケーションによって無視されます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o All flows in this service class are marked with CS4 (Class Selector 4).
Oこのサービス・クラス内のすべてのフローはCS4（クラスセレクタ4）が付いています。
Applications or IP end points SHOULD pre-mark their packets with CS4 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
アプリケーションまたはIPエンドポイントは、CS4 DSCP値とのパケットを事前にマークすべきです。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を実行する必要があります。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds. o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
信頼できないソース（エンドユーザデバイス）から（DSCP設定）マーキングOパケットフローは、[RFC2475]で定義された多門（MF）の分類方法を用いてのDiffServネットワークへの入口で確認してください。 Oパケットは、信頼できないソース（エンドユーザデバイス）からのトラフィックフローがネゴシエート又は操作限界内に留まることを保証するために、バーストサイズ、トークンバケットポリサーで単一レートを使用して、例えば、DiffServのネットワークへの入口でポリシングされるべきです。 Oパケットは、信頼できるソース（投与ネットワーク内のアプリケーションサーバ）から流れポリシングを必要としません。 Oパケットのポリシングポイントをピアリングを横切って流れるのサービスレベル契約（SLA）に行われるべきです。
The fundamental service offered to "Real-Time Interactive" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS4 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS4 marked packet flows.
提供の基本的なサービスは、「リアルタイムインタラクティブ」トラフィックが制御された速度と遅延とベストエフォート型サービスを強化されています。 CS4マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。通常、このサービスクラスのトラフィックは、パケットロスに動的に対応しません。そのため、アクティブキュー管理[RFC2309]はCS4マークされたパケットフローに適用されるべきではありません。
The Multimedia Streaming service class is RECOMMENDED for applications that require near-real-time packet forwarding of variable rate elastic traffic sources that are not as delay sensitive as applications using the Multimedia Conferencing service class. Such applications include streaming audio and video, some video (movies) on-demand applications, and webcasts. In general, the Multimedia Streaming service class assumes that the traffic is buffered at the source/destination; therefore, it is less sensitive to delay and jitter.
マルチメディアストリーミングサービスクラスは、マルチメディア会議サービスクラスを使用するアプリケーションなどの機密遅延としてではない可変レート弾性トラフィックソースのほぼリアルタイムのパケット転送を必要とするアプリケーションに推奨されます。このようなアプリケーションは、ストリーミングオーディオおよびビデオ、いくつかの動画（ムービー）オンデマンドアプリケーション、およびWebキャストが含まれます。一般に、マルチメディアストリーミングサービスクラスは、トラフィックが送信元/送信先でバッファリングされていると仮定します。そのため、それが遅延およびジッタの影響を受けにくいです。
The Multimedia Streaming service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF31, AF32, and AF33 marked packets to ensure that they get forwarded. The Multimedia Streaming service class SHOULD be configured to use Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
マルチメディアストリーミングサービスクラスは、[RFC2597]で定義された保証転送（AF）PHBを使用する必要があります。このサービスクラスは、それらが転送され得ることを保証するために、AF31、AF32、AF33とマークされたパケットのための最小帯域保証を提供するために設定する必要があります。マルチメディアストリーミングサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the Multimedia Streaming service class:
以下のアプリケーションは、マルチメディアストリーミングサービスクラスを使用する必要があります。
o Buffered streaming audio (unicast). o Buffered streaming video (unicast). o Webcasts. o IP VPN service that specifies two rates and is less sensitive to delay and jitter.
Oバッファストリーミングオーディオ（ユニキャスト）。 Oバッファストリーミングビデオ（ユニキャスト）。 O Webキャスト。 2つのレートを指定し、遅延やジッタの影響を受けにくいO IP VPNサービス。
The following are traffic characteristics: o Variable size packets. o The higher the rate, the higher the density of large packets. o Variable rate. o Elastic flows. o Some bursting at start of flow from some applications.
可変サイズのパケットO：次のトラフィックの特性です。大きいパケットの密度レートが高いほど、O。変数o率。 O弾性が流れます。 Oいくつかのいくつかのアプリケーションからの流れの開始時に破裂。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF3x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
以下に示すようにアプリケーションまたはIPエンドポイントは、DSCP値と、それらのパケットを事前にマークする必要があり。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を行い、AF3xとしてすべてのパケットにマークを付けるべきです。注：この場合、2つのレート、三色のマーカーは、色盲モードで動作するように構成されます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o AF31 = up to specified rate "A". o AF32 = in excess of specified rate "A" but below specified rate "B". o AF33 = in excess of specified rate "B". o Where "A" < "B".
指定されたレート "A" までAF31 = O。 AF32 =指定された速度「A」の過剰ではなく指定されたレート「B」以下、O。 O AF33 =指定されたレート「B」の過剰です。 Oどこに "A" < "B"。
Note: One might expect "A" to approximate the sum of the mean rates and "B" to approximate the sum of the peak rates.
注意：一つは、「A」は、ピークレートの和を近似する平均金利と「B」の合計値に近づけるために期待するかもしれません。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
trTCM [RFC2698]で定義されるように、O二速度3色マーカーは動作を提供するように構成されるべきです。パケットが信頼できるソースまたは以前に信頼のDiffServドメインとマーキング色でマークされている場合、O保存される、2つのレート、三色のマーカーは、カラー対応モードで動作するように構成されるべきです。マーキングパケットが信頼されていないか、または色マーキングが保存されるようにされていない場合はO、次いで二速度3色マーカーは、色盲モードで動作するように構成されるべきです。
The fundamental service offered to "Multimedia Streaming" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that AF31 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the AF3x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to reduce forwarding rate to the minimum assured rate at congestion points. The probability of loss of AF31 traffic MUST NOT exceed the probability of loss of AF32 traffic, which in turn MUST NOT exceed the probability of loss of AF33.
「マルチメディアストリーミング」トラフィックに提供される基本的なサービスは、制御された速度や遅延を強化ベストエフォート型のサービスです。 AF31マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。 AF3xトラフィックは弾性であり、パケット損失に動的に応答するので、アクティブキュー管理[RFC2309]は、輻輳点最低保証レートに転送速度を減少させるために主に使用されるべきです。 AF31のトラフィックの損失の可能性は、順番にAF33の損失の可能性を超えてはならないAF32のトラフィックの損失の可能性を、超えてはなりません。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は各DSCPのためのターゲット・キューの深さを指定し、および最大しきい値がその上キューの深さを指定するようDSCPを持つすべてのトラフィックは廃棄されるか、ECNがマーク。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold AF33 < max-threshold AF33 o max-threshold AF33 <= min-threshold AF32 o min-threshold AF32 < max-threshold AF32 o max-threshold AF32 <= min-threshold AF31 o min-threshold AF31 < max-threshold AF31 o max-threshold AF31 <= memory assigned to the queue
O最小閾値AF33 <MAX-閾値AF33 0最大しきい値AF33 <=最小閾値AF32 O最小閾値AF32 <MAX-閾値AF32 0最大しきい値AF32 <=最小閾値AF31 O最小閾値AF31 <MAX-キューに割り当てられたしきい値AF31 0最大しきい値AF31 <=メモリ
Note: This configuration tends to drop AF33 traffic before AF32 and AF32 before AF31. Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：この設定は、AF31の前にAF32とAF32 AF33前にトラフィックをドロップする傾向があります。注意：他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The Broadcast Video service class is RECOMMENDED for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable rate inelastic traffic sources that are not as delay sensitive as applications using the Real-Time Interactive service class. Such applications include broadcast TV, streaming of live audio and video events, some video-on-demand applications, and video surveillance. In general, the Broadcast Video service class assumes that the destination end point has a dejitter buffer, for video application usually a 2 - 8 video-frame buffer (66 to several hundred of milliseconds), and therefore that it is less sensitive to delay and jitter.
放送ビデオサービスクラスはリアルタイムインタラクティブサービスクラスを使用するアプリケーションなどの機密遅延としてではありません一定速度および可変レート非弾性トラフィックソースの非常に低いパケット損失とほぼリアルタイムのパケット転送を必要とするアプリケーションに推奨されます。このようなアプリケーションは、ライブオーディオおよびビデオ、イベント、いくつかのビデオ・オン・デマンドのアプリケーション、およびビデオ監視のテレビ放送、ストリーミングが含まれます。 （ミリ秒の数百まで66）8ビデオフレームバッファ、したがって、遅延にあまり敏感であることと、 - 一般に、放送ビデオ・サービス・クラスは、宛先エンドポイントは、通常、ビデオアプリケーション2のために、デジッタバッファを有していることを前提としていジッタ。
The Broadcast Video service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This service class SHOULD be configured to provide high assurance for bandwidth for CS3 marked packets to ensure that they get forwarded. The Broadcast Video service class SHOULD be configured to use Rate Queuing system such as that defined in Section 1.4.1.2 of this document. Note that this service class
放送ビデオサービスクラスは、[RFC2474]で定義されたクラスセレクタ（CS）PHBを使用する必要があります。このサービスクラスは、それらが転送されますことを確認するために、CS3マークされたパケットのための帯域幅のための高い保証を提供するために設定する必要があります。放送ビデオサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。なお、このサービス・クラス
MAY be configured as a third EF PHB that uses relaxed performance parameter, a rate scheduler, and CS3 DSCP value.
緩和された性能パラメータ、レート・スケジューラ、及びCS3 DSCP値を使用して第三のEF PHBとして構成されてもよいです。
The following applications SHOULD use the Broadcast Video service class:
以下のアプリケーションは、放送ビデオサービスクラスを使用する必要があります。
o Video surveillance and security (unicast). o TV broadcast including HDTV (multicast). o Video on demand (unicast) with control (virtual DVD). o Streaming of live audio events (both unicast and multicast). o Streaming of live video events (both unicast and multicast).
oビデオ監視やセキュリティ（ユニキャスト）。 HDTV（マルチキャスト）を含むOのテレビ放送。 Oコントロール（仮想DVD）とビデオオンデマンド（ユニキャスト）。 Oライブオーディオイベント（ユニキャストとマルチキャストの両方）のストリーミング。 Oライブビデオイベント（ユニキャストとマルチキャストの両方）のストリーミング。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o The higher the rate, the higher the density of large packets. o Mixture of variable rate and constant rate flows. o Fixed packet emission time intervals. o Inelastic flows.
可変サイズのパケットO。大きいパケットの密度レートが高いほど、O。可変速度及び一定の速度の流れのO混合物。 O固定パケット発光時間間隔。 O非弾性が流れます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o All flows in this service class are marked with CS3 (Class Selector 3). o In some cases, such as those for security and video surveillance applications, it may be desirable to use a different DSCP marking. If so, then locally user definable (EXP/LU) codepoints in the range '011xx1' MAY be used to provide unique traffic identification. The locally user definable (EXP/LU) codepoint(s) MAY be associated with the PHB that is used for CS3 traffic. Furthermore, depending on the network scenario, additional network edge conditioning policy MAY be needed for the EXP/LU codepoint(s) used.
Oこのサービス・クラス内のすべてのフローはCS3（クラスセレクタ3）が付いています。 Oいくつかの場合において、このようなセキュリティおよびビデオ監視アプリケーションのためのものとして、マーキング異なるDSCPを使用することが望ましい場合があります。もしそうであれば、範囲「011xx1」に、次いで局所的にユーザ定義可能な（EXP / LU）コードポイントは、固有のトラフィックの識別を提供するために使用され得ます。ローカルユーザ定義可能な（EXP / LU）コードポイント（複数可）CS3トラフィックのために使用されるPHBに関連付けることができます。また、ネットワークシナリオに応じて、追加のネットワークエッジ調整ポリシーが使用EXP / LUコードポイント（複数可）のために必要とされ得ます。
Applications or IP end points SHOULD pre-mark their packets with CS3 DSCP value. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475].
アプリケーションまたはIPエンドポイントは、CS3 DSCP値とのパケットを事前にマークすべきです。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を実行する必要があります。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475]. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds.
信頼できないソース（エンドユーザデバイス）から（DSCP設定）マーキングOパケットフローは、[RFC2475]で定義された多門（MF）の分類方法を用いてのDiffServネットワークへの入口で確認してください。 Oパケットは、信頼できないソース（エンドユーザデバイス）からのトラフィックフローがネゴシエート又は操作限界内に留まることを保証するために、バーストサイズ、トークンバケットポリサーで単一レートを使用して、例えば、DiffServのネットワークへの入口でポリシングされるべきです。
o Packet flows from trusted sources (application servers inside administered network) MAY not require policing. o Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
Oパケットは、信頼できるソース（投与ネットワーク内のアプリケーションサーバ）から流れポリシングを必要としません。 Oパケットのポリシングポイントをピアリングを横切って流れるのサービスレベル契約（SLA）に行われるべきです。
The fundamental service offered to "Broadcast Video" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that CS3 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally, traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS3 marked packet flows.
「放送ビデオ」トラフィックに提供される基本的なサービスは、制御された速度や遅延を強化ベストエフォート型のサービスです。 CS3マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。通常、このサービスクラスのトラフィックは、パケットロスに動的に対応しません。そのため、アクティブキュー管理[RFC2309]はCS3マークされたパケットフローに適用されるべきではありません。
The Low-Latency Data service class is RECOMMENDED for elastic and responsive typically client-/server-based applications. Applications forwarded by this service class are those that require a relatively fast response and typically have asymmetrical bandwidth need, i.e., the client typically sends a short message to the server and the server responds with a much larger data flow back to the client. The most common example of this is when a user clicks a hyperlink (~ few dozen bytes) on a web page, resulting in a new web page to be loaded (Kbytes of data). This service class is configured to provide good response for TCP [RFC1633] short-lived flows that require real-time packet forwarding of variable rate traffic sources.
低遅延のデータサービスクラスは、弾性および応答通常、クライアント - /サーバーベースのアプリケーションに推奨されます。このサービスクラスによって転送アプリケーションは、すなわち、クライアントは通常、サーバへのショートメッセージを送信し、サーバーは、クライアントに非常に大きなデータフローで応答し、必要に比較的高速応答を必要とし、一般的に非対称の帯域幅を有するものです。ユーザーがロードする新しいWebページ（データのバイト）で、その結果、Webページ上のハイパーリンク（〜数十バイト）をクリックしたときに、この最も一般的な例です。このサービスクラスは、可変レートのトラフィックソースのリアルタイムパケット転送を必要とTCP [RFC1633]短命フローの良好な応答を提供するように構成されています。
The Low-Latency Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF21, AF22, and AF23 marked packets to ensure that they get forwarded. The Low-Latency Data service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
低遅延データサービスクラスは、[RFC2597]で定義された保証転送（AF）PHBを使用する必要があります。このサービスクラスは、それらが転送され得ることを保証するために、AF21、AF22、AF23とマークされたパケットのための最小帯域保証を提供するために設定する必要があります。低遅延のデータサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the Low-Latency Data service class:
以下のアプリケーションは、低遅延のデータサービスクラスを使用する必要があります。
o Client/server applications. o Systems Network Architecture (SNA) terminal to host transactions (SNA over IP using Data Link Switching (DLSw)). o Web-based transactions (E-commerce). o Credit card transactions. o Financial wire transfers. o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). o VPN service that supports Committed Information Rate (CIR) with up to two burst sizes.
Oクライアント/サーバーアプリケーション。 （（DLSwのを）切り替えデータリンクを使用してIP経由SNA）の取引を主催するOシステム・ネットワーク体系（SNA）ターミナル。 O Webベースのトランザクション（Eコマース）。 Oクレジットカード決済。金融電信送金O。エンタープライズ・リソース・プランニング（ERP）アプリケーション（例えば、SAP / BAAN）O。最大2つのバーストサイズと認定情報レート（CIR）をサポートするO VPNサービス。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o Variable packet emission rate. o With packet bursts of TCP window size. o Short traffic bursts. o Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification.
可変サイズのパケットO。 O変数のパケット放出率。 TCPウィンドウサイズのパケットバーストでは、O。短いトラフィックバーストO。受信機で、または明示的輻輳通知を介してパケット損失の検出に基づいて、その送信レートを低減することができるOソース。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] and mark all packets as AF2x. Note: In this case, the single-rate, three-color marker will be configured to operate in Color-Blind mode.
以下に示すようにアプリケーションまたはIPエンドポイントは、DSCP値と、それらのパケットを事前にマークする必要があり。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を行い、AF2xとしてすべてのパケットをマークするべきです。注：この場合には、シングルレート、三色のマーカーは、色盲モードで動作するように構成されます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o AF21 = flow stream with packet burst size up to "A" bytes. o AF22 = flow stream with packet burst size in excess of "A" but below "B" bytes. o AF23 = flow stream with packet burst size in excess of "B" bytes. o Where "A" < "B".
パケットバーストサイズまで「A」バイトのO AF21 =流れ。 「」しかし、以下の「B」バイトを超えるパケットのバーストサイズでO AF22 =流れ。 「B」バイトを超えるパケットのバーストサイズでO AF23 =流れ。 Oどこに "A" < "B"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o The single-rate, three-color marker SHOULD be configured to provide the behavior as defined in srTCM [RFC2697]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
シングルレートO、三色のマーカーはsrTCM [RFC2697]で定義されるように動作を提供するように構成されるべきです。パケットが信頼できるソースまたは以前に信頼のDiffServドメインとマーキング色でマークされている場合は、O、次いでシングルレート、三色のマーカーがカラー対応モードで動作するように構成する必要があり、保存されるべきです。パケットが信頼されていないマーキングまたは色が保持されるべきではないマーキング場合、Oは、シングルレート、三色のマーカーは、色盲モードで動作するように構成されるべきです。
The fundamental service offered to "Low-Latency Data" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that AF21 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the AF2x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points by dropping packets from TCP flows that have large burst size. The probability of loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management.
基本的なサービスが提供する「低遅延データ」のトラフィックが制御された速度と遅延とベストエフォート型サービスを強化しています。 AF21マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスが設計される必要があります。 AF2xトラフィックは弾性であり、パケット損失に動的に応答するので、アクティブキュー管理[RFC2309]は、大きなバーストサイズを有するTCPフローからパケットをドロップすることによって輻輳点でTCPの流量を制御するために主に使用されるべきです。 AF21のトラフィックの損失の可能性は、順番にAF23の損失の可能性を超えてはならないAF22のトラフィックの損失の可能性を、超えてはなりません。明示的輻輳通知（ECN）[RFC3168]もアクティブキュー管理に使用されるかもしれません。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は各DSCPのためのターゲット・キューの深さを指定し、および最大しきい値がその上キューの深さを指定するようDSCPを持つすべてのトラフィックは廃棄されるか、ECNがマーク。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold AF23 < max-threshold AF23 o max-threshold AF23 <= min-threshold AF22 o min-threshold AF22 < max-threshold AF22 o max-threshold AF22 <= min-threshold AF21 o min-threshold AF21 < max-threshold AF21 o max-threshold AF21 <= memory assigned to the queue
O最小閾値AF23 <MAX-閾値AF23 0最大しきい値AF23 <=最小閾値AF22 O最小閾値AF22 <MAX-閾値AF22 0最大しきい値AF22 <=最小閾値AF21 O最小閾値AF21 <MAX-キューに割り当てられたしきい値AF21 0最大しきい値AF21 <=メモリ
Note: This configuration tends to drop AF23 traffic before AF22 and AF22 before AF21. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：この設定は、AF21の前にAF22とAF22 AF23前にトラフィックをドロップする傾向があります。他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The High-Throughput Data service class is RECOMMENDED for elastic applications that require timely packet forwarding of variable rate traffic sources and, more specifically, is configured to provide good throughput for TCP longer-lived flows. TCP [RFC1633] or a transport with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782] normally will drive as high a data rate as it can obtain over a long period of time. The FTP protocol is a common example, although one cannot definitively say that all FTP transfers are moving data in bulk.
ハイスループットデータサービスクラスは、可変レートのトラフィックソースのタイムリーなパケット転送を必要と弾性アプリケーションに推奨され、より具体的には、TCP長い寿命のフローのための優れたスループットを提供するように構成されています。 TCP [RFC1633]または一貫した輻輳回避手順[RFC2581]と輸送[RFC3782]、それが長期間にわたって得ることができるように、通常のように高いデータレートを駆動します。一つは決定的すべてのFTP転送が大量にデータを移動していると言うことはできないものの、FTPプロトコルは、一般的な例です。
The High-Throughput Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD be configured to provide a minimum bandwidth assurance for AF11, AF12, and AF13 marked packets to ensure that they are forwarded in a timely manner. The High-Throughput Data service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
ハイスループット・データ・サービス・クラスは、[RFC2597]で定義された保証転送（AF）PHBを使用する必要があります。このサービスクラスは、それらが適時に転送されることを保証するためにAF11、AF12、AF13とマークされたパケットのための最小帯域保証を提供するために設定する必要があります。ハイスループットデータサービスクラスには、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the High-Throughput Data service class:
以下のアプリケーションは、高スループットのデータサービスクラスを使用する必要があります。
o Store and forward applications. o File transfer applications. o Email. o VPN service that supports two rates (committed information rate and excess or peak information rate).
Oストアアンドフォワードのアプリケーション。 Oファイル転送アプリケーション。 Oメール。 2つのレート（認定情報レートおよび超過またはピーク情報速度）をサポートO VPNサービス。
The following are traffic characteristics:
トラフィック特性は以下のとおりです。
o Variable size packets. o Variable packet emission rate. o Variable rate. o With packet bursts of TCP window size. o Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification.
可変サイズのパケットO。 O変数のパケット放出率。変数o率。 TCPウィンドウサイズのパケットバーストでは、O。受信機で、または明示的輻輳通知を介してパケット損失の検出に基づいて、その送信レートを低減することができるOソース。
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF1x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
以下に示すようにアプリケーションまたはIPエンドポイントは、DSCP値と、それらのパケットを事前にマークする必要があり。エンドポイントは、DSCP値を設定することができない場合、エンドポイントにトポロジー的に最も近いルータは、[RFC2475]で定義されるように、多門（MF）の分類を行い、AF1xとしてすべてのパケットにマークを付けるべきです。注：この場合、2つのレート、三色のマーカーは、色盲モードで動作するように構成されます。
RECOMMENDED DSCP marking:
推奨DSCPマーキング：
o AF11 = up to specified rate "A". o AF12 = in excess of specified rate "A" but below specified rate "B". o AF13 = in excess of specified rate "B". o Where "A" < "B".
指定されたレート "A" までAF11 = O。 AF12 =指定された速度「A」の過剰ではなく指定されたレート「B」以下、O。 O AF13 =指定されたレート「B」の過剰です。 Oどこに "A" < "B"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServネットワークのエッジで実行推奨コンディショニング：
o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
trTCM [RFC2698]で定義されるように、O二速度3色マーカーは動作を提供するように構成されるべきです。パケットが信頼できるソースまたは以前に信頼のDiffServドメインとマーキング色でマークされている場合、O保存される、2つのレート、三色のマーカーは、カラー対応モードで動作するように構成されるべきです。マーキングパケットが信頼されていないか、または色マーキングが保存されるようにされていない場合はO、次いで二速度3色マーカーは、色盲モードで動作するように構成されるべきです。
The fundamental service offered to "High-Throughput Data" traffic is enhanced best-effort service with a specified minimum rate. The service SHOULD be engineered so that AF11 marked packet flows have sufficient bandwidth in the network to provide assured delivery. It can be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss. Since the AF1x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points by dropping packets from TCP flows that have higher rates first. The probability of loss of AF11 traffic MUST NOT exceed the probability of loss of AF12 traffic, which in turn MUST NOT exceed the probability of loss of AF13. In such a case, if one network customer is driving significant excess and another seeks to use the link, any losses will be experienced by the high-rate user, causing him to reduce his rate. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management.
「ハイスループットデータ」トラフィックに提供される基本的なサービスは、指定された最小レートでベストエフォート型のサービスを強化しています。 AF11マークされたパケットのフローが確実な配達を提供するために、ネットワーク内に十分な帯域幅を持つようにサービスが設計される必要があります。このクラスは、すべての利用可能な帯域幅を消費し、混雑リンクを通過するパケットが高いキュー遅延やパケットロスが発生する可能性がありますことを想定することができます。 AF1xトラフィックは弾性であり、パケット損失に動的に応答するので、アクティブキュー管理[RFC2309]は最初のより高い速度を有するTCPフローからパケットをドロップすることによって輻輳点でTCPの流量を制御するために主に使用されるべきです。 AF11のトラフィックの損失の可能性は、順番にAF13の損失の可能性を超えてはならないAF12のトラフィックの損失の可能性を、超えてはなりません。 1人のネットワークの顧客は有意な過剰を駆動され、別のリンクを使用しようとするならば、このような場合には、任意の損失は彼が彼の速度を低下させる原因となる、高レートのユーザーが経験されます。明示的輻輳通知（ECN）[RFC3168]もアクティブキュー管理に使用されるかもしれません。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は各DSCPのためのターゲット・キューの深さを指定し、および最大しきい値がその上キューの深さを指定するようDSCPを持つすべてのトラフィックは廃棄されるか、ECNがマーク。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold AF13 < max-threshold AF13 o max-threshold AF13 <= min-threshold AF12 o min-threshold AF12 < max-threshold AF12 o max-threshold AF12 <= min-threshold AF11 o min-threshold AF11 < max-threshold AF11 o max-threshold AF11 <= memory assigned to the queue
O最小閾値AF13 <MAX-閾値AF13 0最大しきい値AF13 <=最小閾値AF12 O最小閾値AF12 <MAX-閾値AF12 0最大しきい値AF12 <=最小閾値AF11 O最小閾値AF11 <MAX-キューに割り当てられたしきい値AF11 0最大しきい値AF11 <=メモリ
Note: This configuration tends to drop AF13 traffic before AF12 and AF12 before AF11. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：この設定は、AF11の前にAF12とAF12 AF13前にトラフィックをドロップする傾向があります。他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The Standard service class is RECOMMENDED for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides the Internet's "best-effort" forwarding behavior. This service class typically has minimum bandwidth guarantee.
標準のサービスクラスは、DiffServのネットワークドメイン内の他のサポート転送サービスクラスのいずれかに分類されていないトラフィックをお勧めします。このサービスクラスには、インターネットの「ベストエフォート」の転送動作を提供します。このサービスクラスは通常、最低帯域保証を持っています。
The Standard service class MUST use the Default Forwarding (DF) PHB, defined in [RFC2474], and SHOULD be configured to receive at least a small percentage of forwarding resources as a guaranteed minimum. This service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document.
標準的なサービスクラスは、[RFC2474]で定義されたデフォルト転送（DF）PHBを使用する必要があり、保証最小値として転送資源の少なくとも小さな割合を受け取るように構成されるべきです。このサービスクラスは、このドキュメントのセクション1.4.1.2で定義されているようなレート・キューイング・システムを使用するように設定する必要があります。
The following applications SHOULD use the Standard service class:
以下のアプリケーションは、標準のサービスクラスを使用する必要があります。
o Network services, DNS, DHCP, BootP. o Any undifferentiated application/packet flow transported through the DiffServ enabled network.
Oネットワークサービス、DNS、DHCP、BootPサーバ。 O任意の未分化アプリケーション/パケットフローは、DiffServの有効なネットワークを介して輸送します。
The following is a traffic characteristic:
以下では、トラフィックの特徴であります：
o Non-deterministic, mixture of everything.
O非決定論的、すべての混合物。
The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.
マーキング推奨DSCPは、DF（デフォルトフォワーディング）「000000」です。
Network Edge Conditioning:
ネットワークエッジコンディショニング：
There is no requirement that conditioning of packet flows be performed for this service class.
パケットのコンディショニングは、このサービスクラスに対して実行するフロー要件はありません。
The fundamental service offered to the Standard service class is best-effort service with active queue management to limit overall delay. Typical configurations SHOULD use random packet dropping to implement Active Queue Management [RFC2309] or Explicit Congestion Notification [RFC3168], and MAY impose a minimum or maximum rate on the queue.
標準のサービスクラスに提供される基本的なサービスは、全体的な遅延を制限するために、アクティブキュー管理とベストエフォート型サービスです。典型的な構成は、アクティブキュー管理[RFC2309]または明示的輻輳通知[RFC3168]を実装するために、ランダムなパケット廃棄を使用すべきである、とキューの最小または最大レートを課すことができます。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は、ターゲット・キューの深さを指定し、および最大閾値は、すべてのトラフィックが廃棄されるか、ECNがマークされている上に、キューの深さを指定します。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold DF < max-threshold DF o max-threshold DF <= memory assigned to the queue
キューに割り当てられO最小閾値DF <MAX-閾値DF O最大しきい値DF <=メモリ
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The Low-Priority Data service class serves applications that run over TCP [RFC0793] or a transport with consistent congestion avoidance procedures [RFC2581] [RFC3782] and that the user is willing to accept service without guarantees. This service class is specified in [RFC3662] and [QBSS].
低優先度のデータサービスクラスは、TCP [RFC0793]や一貫性のある輻輳回避手順と輸送[RFC2581] [RFC3782]の上に、ユーザーが保証なしでサービスを受け入れることを望んでいることを実行するアプリケーションを提供しています。このサービスクラスには、[QBSS] [RFC3662]で指定されています。
The following applications MAY use the Low-Priority Data service class:
以下のアプリケーションは、低優先度のデータサービスクラスを使用することがあります：
o Any TCP based-application/packet flow transported through the DiffServ enabled network that does not require any bandwidth assurances.
O任意のTCPベースのアプリケーション/パケットフローは、任意の帯域幅の保証を必要としないのDiffServ対応のネットワークを介して輸送します。
The following is a traffic characteristic:
以下では、トラフィックの特徴であります：
o Non-real-time and elastic.
非リアルタイムOと弾性。
Network Edge Conditioning:
ネットワークエッジコンディショニング：
There is no requirement that conditioning of packet flows be performed for this service class.
パケットのコンディショニングは、このサービスクラスに対して実行するフロー要件はありません。
The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
マーキング推奨DSCPはCS1（クラスセレクタ1）です。
The fundamental service offered to the Low-Priority Data service class is best-effort service with zero bandwidth assurance. By placing it into a separate queue or class, it may be treated in a manner consistent with a specific Service Level Agreement.
低優先度のデータサービスクラスに提供される基本的なサービスは、ゼロ帯域保証付きのベストエフォート型のサービスです。別のキューまたはクラスにそれを置くことで、特定のサービスレベル契約と一貫性のある方法で処理することができます。
Typical configurations SHOULD use Explicit Congestion Notification [RFC3168] or random loss to implement Active Queue Management [RFC2309].
典型的な構成は、アクティブキュー管理[RFC2309]を実装するために、[RFC3168]またはランダム損失を明示的輻輳通知を使用すべきです。
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations:
RED [RFC2309]はAQMアルゴリズムとして使用される場合、最小閾値は、ターゲット・キューの深さを指定し、および最大閾値は、すべてのトラフィックが廃棄されるか、ECNがマークされている上に、キューの深さを指定します。したがって、このサービス・クラスで、次の不等式は、キュー構成で保持する必要があります。
o min-threshold CS1 < max-threshold CS1 o max-threshold CS1 <= memory assigned to the queue
キューに割り当てられO最小閾値CS1 <MAX-閾値CS1 O最大しきい値CS1 <=メモリ
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注意：他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
In this section, we provide additional information on how some specific applications should be configured to use the defined service classes.
このセクションでは、我々はいくつかの特定のアプリケーションが定義されたサービスクラスを使用するように設定する方法に関する追加情報を提供しています。
There are many different signaling protocols, ways that signaling is used and performance requirements from applications that are controlled by these protocols. We believe that different signaling protocols should use the service class that best meets the objectives of application or service they control. The following mapping is recommended:
多くの異なったシグナリングプロトコル、シグナリングが使用されている方法と、これらのプロトコルによって制御されているアプリケーションからの性能要件があります。私たちは、異なるシグナリングプロトコルが最高のは、彼らがコントロールするアプリケーションやサービスの目的に合致するサービスクラスを使用する必要があると考えています。次のマッピングをお勧めします。
o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP (use Signaling service class).
OピアツーピアSIP / H.323は、CS5 DSCP（使用シグナリングサービスクラス）でマークされている使用してシグナリング。
o Client-server signaling as used in many implementation for IP telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or proprietary protocols is marked with CS5 DSCP (use Signaling service class). o Signaling between call servers or soft-switches in carrier's network using SIP, SIP-T, or IP encapsulated ISUP is marked with CS5 DSCP (use Signaling service class). o RSVP signaling depends on the application. If RSVP signaling is "on-path" as used in IntServ, then it needs to be forwarded from the same queue (service class) and marked with the same DSCP value as application data that it is controlling. This may also apply to the "on-path" Next Steps in Signaling (NSIS) protocol. o If IGMP is used for multicast session control such as channel changing in IPTV systems, then IGMP packets should be marked with CS5 DSCP (use Signaling service class). When IGMP is used only for the normal multicast routing purpose, it should be marked with CS6 DSCP (use Network Control service class).
H.248、MEGACO、MGCPを使用してIPテレフォニーのための多くの実装で使用されるようなクライアントサーバーシグナリングO、IPは、ISDN、または独自のプロトコルをカプセル化CS5 DSCP（使用シグナリングサービスクラス）が付いています。 SIPを用いた通信事業者のネットワーク内のコールサーバまたはソフトスイッチ間シグナリングO、SIP-T、またはIPカプセル化ISUPがCS5 DSCP（使用シグナリングサービスクラス）でマークされています。 O RSVPシグナリングは、アプリケーションに依存します。 RSVPシグナリングがのIntServで使用される「オンパス」である場合、それは同じキュー（サービスクラス）から転送し、それが制御しているアプリケーションデータと同じDSCP値でマークする必要があります。これはまた、「オンパス」シグナリングに次のステップ（NSIS）プロトコルに適用することができます。 IGMPは、IPTVシステムにおいてチャンネル変更としてマルチキャストセッション制御のために使用される場合、O、次いで、IGMPパケットがCS5 DSCP（使用シグナリングサービスクラス）でマークされるべきです。 IGMPのみ、通常のマルチキャストルーティングの目的のために使用されている場合、それはCS6 DSCP（ネットワークコントロールサービスクラスを使用）でマークする必要があります。
From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport. Therefore, we suggest that the following guidelines for Network Time Protocol (NTP) be used:
実施した試験から、表示は正確な時間の分布が非常に低いパケット遅延変動（ジッタ）の輸送を必要とすることです。したがって、我々は、ネットワークタイムプロトコル（NTP）については、次のガイドラインを使用することを示唆しています：
o When NTP is used for providing high-accuracy timing within an administrator's (carrier's) network or to end users/clients, the Telephony service class should be used, and NTP packets should be marked with EF DSCP value. o For applications that require "wall clock" timing accuracy, the Standard service class should be used, and packets should be marked with DF DSCP.
NTPは、管理者（事業者）ネットワーク内で高精度のタイミングを提供するために使用されるか、またはユーザー/クライアントを終了する場合、O、テレフォニーサービスクラスを使用する必要があり、そしてNTPパケットがEF DSCP値でマークされなければなりません。タイミング精度を「壁時計」を必要とするアプリケーションの場合oは、標準サービスクラスを使用する必要があり、かつパケットがDF DSCPでマークする必要があります。
"Differentiated Services and Tunnels" [RFC2983] considers the interaction of DiffServ architecture with IP tunnels of various forms. Further to guidelines provided in RFC 2983, below are additional guidelines for mapping service classes that are supported in one part of the network into a VPN connection. This discussion is limited to VPNs that use DiffServ technology for traffic differentiation.
「差別化サービスおよびトンネル」[RFC2983]は様々な形式のIPトンネルとDiffServアーキテクチャの相互作用を考慮しています。さらに以下、RFC 2983で提供されたガイドラインへのVPN接続にネットワークの一部でサポートされているマッピングサービスクラスの追加のガイドラインがあります。この議論は、トラフィックの差別化のためのDiffServ技術を使用してVPNに限定されています。
o The DSCP value(s) that is/are used to represent a PHB or a PHB group should be the same for the networks at both ends of the VPN tunnel, unless remarking of DSCP is done as ingress/egress processing function of the tunnel. DSCP marking needs to be preserved end to end.
PHBまたはPHBグループは、VPNトンネルの両端のネットワークに対して同じであるべきを表すために使用されている/されたDSCP値（S）O、DSCPの再マーキングするトンネルの入口/出口処理機能として実行されていない限り。エンドツーエンドを保存するニーズをDSCPマーキング。
o The VPN may be configured to support one or more service classes. It is left up to the administrators of the two networks to agree on the level of traffic differentiation that will be provided in the network that supports VPN service. Service classes are then mapped into the supported VPN traffic forwarding behaviors that meet the traffic characteristics and performance requirements of the encapsulated service classes. o The traffic treatment in the network that is providing the VPN service needs to be such that the encapsulated service class or classes receive comparable behavior and performance in terms of delay, jitter, and packet loss and that they are within the limits of the service specified. o The DSCP value in the external header of the packet forwarded through the network providing the VPN service may be different from the DSCP value that is used end to end for service differentiation in the end network. o The guidelines for aggregation of two or more service classes into a single traffic forwarding treatment in the network that is providing the VPN service is for further study.
O VPNは、1つまたは複数のサービスクラスをサポートするように構成することができます。 VPNサービスをサポートするネットワークで提供されるトラフィックの差別化のレベルに同意する2つのネットワークの管理者に委ねられています。サービスクラスは、その後、カプセル化されたサービスクラスのトラフィック特性と性能要件を満たすサポートVPNトラフィックの転送動作にマッピングされます。 VPNサービスを提供しているネットワーク内のトラフィック処理は、カプセル化されたサービス・クラスまたはクラスは、遅延、ジッタ、パケット損失の点で同等の挙動および性能を受信することと、それらが指定されたサービスの限界内にあるようにする必要があるoを。 O VPNサービスを提供するネットワークを介して転送されたパケットの外部ヘッダのDSCP値は、エンドネットワークにおけるサービスの差別化のためのエンドツーエンドのに使用されるDSCP値と異なっていてもよいです。 VPNサービスを提供しているネットワーク内の単一のトラフィック転送処理に二つ以上のサービスクラスの集約のためのガイドラインoを今後の検討課題です。
This document discusses policy and describes a common policy configuration, for the use of a Differentiated Services Code Point by transports and applications. If implemented as described, it should require that the network do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy.
この文書では、政策を議論し、トランスポートとアプリケーションによる差別化サービスコードポイントを使用するため、共通のポリシーの設定について説明します。説明するように実装されている場合、それは、ネットワークは、ネットワークが既に許可されていない何もしないことを要求すべきです。その場合は、新しいセキュリティ問題は、このような政策の使用から生じてはなりません。
It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined service class. In that case, a policy issue exists that the network SHOULD detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior.
ポリシーが正しく適用されることが可能である、または間違ったポリシーが定義されたサービスクラスのネットワークに適用されるため。その場合には、政策の問題は、ネットワークが、検出、評価、および対処すべきであるということが存在します。これは、政策指向の行動に依存して、任意のネットワークの既知のセキュリティ問題です。
A well-known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the author's knowledge, there is no known technical way to respond to an unauthenticated data stream using service that it is not intended to use, and such is the nature of the Internet.
帯域幅は、サービス（例えば、音声トランスポート）のために予約または有効になっている場合、よく知られた欠陥が表示され、別のサービスや攻撃トラフィックストリームは、それを使用しています。この可能性は、適切なパケットマーキングに依存DiffServの技術、に固有のものです。帯域予約またはプライオリティキューイングシステムは脆弱なネットワークで使用される場合、認証及びフローアドミッションを使用することが推奨されます。筆者の知る限りでは、そこに使用するように意図されていないサービスを使用して認証されていないデータストリームに対応するための既知の技術的な方法はありません、そして、このようなインターネットの性質です。
The use of a service class by a user is not an issue when the SLA between the user and the network permits him to use it, or to use it up to a stated rate. In such cases, simple policing is used in the
ユーザーとネットワーク間のSLAは、それを使用する、または述べレートにそれを使用するために彼を許可したときに、ユーザーによるサービスクラスを使用することは問題ではありません。このような場合には、簡単なポリシングはで使用されています
Differentiated Services Architecture. Some service classes, such as Network Control, are not permitted to be used by users at all; such traffic should be dropped or remarked by ingress filters. Where service classes are available under the SLA only to an authenticated user rather than to the entire population of users, authentication and authorization services are required, such as those surveyed in [AUTHMECH].
差別化サービスアーキテクチャ。こうしたネットワーク制御などの一部のサービスクラスは、すべてのユーザーが使用することを許可されていません。そのようなトラフィックは入力フィルタによってドロップまたはリマークされなければなりません。サービスクラスだけではなく、ユーザーの全人口により認証されたユーザにSLAの下で利用可能な場合、認証および認可サービスは、[AUTHMECH]に調査対象者として、必要とされています。
The authors thank the TSVWG reviewers, David Black, Brian E. Carpenter, and Alan O'Neill for their review and input to this document.
作者はこのドキュメントへの彼らのレビューと入力のために、デビッド・ブラック、ブライアンE.カーペンター、アラン・オニールをTSVWGの査読に感謝します。
The authors acknowledge a great many inputs, most notably from Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe Zebarth, and Alistair Munroe each did a thorough proofreading, and the document is better for their contributions.
著者は、非常に多くの入力を認識し、最も有名なブルース・デイビー、デイブ・オラン、ラルフSantitoro、ゲイリーKenward、フランソワAudet、モルガン・リトルウッド、ロバート・ミルン、ジョン・シュラー、ナリンMistryさん、アル・モートン、マイク・ピアース、エド・ケーラー・ジュニア、ティムからRahrer、フィル・ディッキンソン、マイク・フィドラー、とシェーンAmante。キンバリーキング、ジョーZebarth、とアリスター・マンローそれぞれが徹底校正をした、そしてドキュメントは彼らの貢献のためのより良いです。
The term "ring clipping" refers to those instances where the front end of a ringing signal is altered because the bearer channel is not made available in time to carry all the audible ringing signal. This condition may occur due to a race condition between when the tone generator located in the circuit switch Exchange is turned on and when the bearer path through the IP network is enabled. To reduce ring clipping from occurring, delay of signaling path needs to be minimized. Below is a more detailed explanation.
用語「環クリッピング」は、ベアラチャネルは、すべての可聴リンギング信号を運ぶために時間内に利用可能にされていないため、リンギング信号のフロントエンドが変更されたそれらのインスタンスを指します。この状態は、回路スイッチ所に位置する音源がオンされると、IPネットワークを介してベアラ・パスが有効になっている場合との間の競合状態を発生する可能性があります。発生クリッピングリングを低減するために、シグナル伝達経路の遅延を最小限にする必要があります。以下は、より詳細な説明があります。
The bearer path setup delay target is defined as the ISUP Initial Address Message (IAM) / Address Complete Message (ACM) round-trip delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7), as defined by ITU-T. This consists of the amount of time it takes for the ISUP Initial Address Message (IAM) to leave the Transit Exchange, travel through the SS7 network (including any applicable STPs, or Signaling Transfer Points), and be processed by the End Exchange thus generating the Address Complete Message (ACM) and for the ACM to travel back through the SS7 network and return to the Transit Exchange. If the bearer path has not been set up within the soft-switch media gateway and the IP network that is performing the Transit Exchange function by the time the ACM is forwarded to the originating End Exchange, the phenomenon known as ring clipping may occur. If ACM processing within the soft-switch media gateway and delay through the IP network is excessive, it will delay the setup of the bearer path, and therefore may cause clipping of the ring tone to be heard.
ベアラ・パス設定遅延目標は、ISUP初期アドレスメッセージ（IAM）/アドレス完了メッセージ（ACM）、ラウンドトリップ遅延として定義されます。 ITU-Tによって定義されるISUPは、信号システム第7号（SS7）のISDNユーザ部を指します。これは、ISUP初期アドレスメッセージ（IAM）は、トランジット交換を残す（適用可能なのSTPを含む、または転送シグナリングポイント）SS7ネットワークを介して移動し、エンド取引所で処理されるため、それはこのように生成するのにかかる時間の量で構成されていアドレス完了メッセージ（ACM）とACMは、SS7ネットワークを介して戻って移動し、トランジットExchangeに戻すため。ベアラパスは、ソフトスイッチ、メディアゲートウェイとACMを発信エンドExchangeに転送されるまでにトランジット交換機能を実行しているIPネットワーク内に設定されていない場合、リングクリッピングと呼ばれる現象が発生する可能性があります。 IPネットワークを介して、ソフトスイッチ、メディアゲートウェイと遅延内のACM処理が過剰である場合は、ベアラ・パスのセットアップを遅らせるであろう、したがってリングトーンのクリッピングが聞こえさせてもよいです。
The intra-exchange ISUP IAM signaling delay value should not exceed 240ms. This may include soft-switch, media gateway, router, and propagation delay on the inter-exchange data path. This value represents the threshold where ring clipping theoretically commences. It is important to note that the 240ms delay objective as presented is a maximum value. Service administrators are free to choose specific IAM delay values according to their own preferences (i.e., they may wish to set a very low mean delay objective for strategic reasons to differentiate themselves from other providers). In summary, out of the 240-ms delay budget, 200ms is allocated as cross-Exchange delay (soft-switch and media gateway) and 40ms for network delay (queuing and distance).
イントラ交換ISUP IAM信号遅延値は240msを超えてはなりません。これは、ソフトスイッチ、メディアゲートウェイ、ルータ、及び中間交換データパス上の伝播遅延を含むことができます。この値は、リングクリッピングが理論的に開始する閾値を表します。提示された240ms遅延目標が最大値であることに注意することが重要です。サービス管理者は（つまり、彼らは他のプロバイダから身を区別するために、戦略的な理由のために非常に低い平均遅延目標を設定したい場合があります）自分の好みに応じて、特定のIAM遅延値を自由に選択できます。要約すると、240ミリ秒の遅延バジェットのうち、200ミリ秒は、ネットワーク遅延（キューイングや距離）の相互交換遅延（ソフトスイッチ、メディアゲートウェイ）と40msのように割り当てられています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P.、 "インターネットプロトコルスイートでサービスの種類"、RFC 1349、1992年7月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]祝福、R.、ニコルズ、K.、およびK. Wehrleの、 "低級努力ドメイン単位の行動差別化サービスのための（PDB）"、RFC 3662、2003年12月。
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, September 2005.
[AUTHMECH]レスコラ、E.、「認証メカニズムの調査」、進歩、2005年9月での作業。
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 Technical Report Proposed Service Definition, March 2001.
[QBSS] "QBoneスカベンジャーサービス（QBSS）の定義"、Internet2の技術報告書案サービス定義、2001年3月。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen、J.とR.ゲラン、 "シングルレート3カラーマーカー"、RFC 2697、1999年9月。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999.
[RFC2698] Heinanen、J.とR.ゲラン、 "二つのレート3カラーマーカー"、RFC 2698、1999年9月。
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for Differentiated Services", RFC 2963, October 2000.
[RFC2963]ボナベンチャー、O.およびS.デCnodder、 "差別化サービスのためのレート適応シェイパー"、RFC 2963、2000年10月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290] Bernet、Y.、ブレイク、S.、グロスマン、D.、およびA.スミス、 "Diffservのルータのための非公式の管理モデル"、RFC 3290、2002年5月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]フロイド、S.、ヘンダーソン、T.、およびA. Gurtov、RFC 3782、2004年4月 "TCPの高速回復アルゴリズムにNewRenoの変更"。
Authors' Addresses
著者のアドレス
Jozef Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
ヨゼフBabiarz Nortel Networksの3500カーリングアベニューオタワ、オンタリオ。 K2H 8E9カナダ
Phone: +1-613-763-6098 Fax: +1-613-765-7462 EMail: babiarz@nortel.com
電話：+ 1-613-763-6098ファックス：+ 1-613-765-7462 Eメール：babiarz@nortel.com
Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
クォックホーチャンNortel Networksの600テクノロジーパークドライブビレリカ、MA 01821米国
Phone: +1-978-288-8175 Fax: +1-978-288-8700 EMail: khchan@nortel.com
電話：+ 1-978-288-8175ファックス：+ 1-978-288-8700 Eメール：khchan@nortel.com
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア州93117米国
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。