[要約] RFC 4594は、DiffServサービスクラスの設定ガイドラインであり、ネットワークトラフィックの優先順位付けと品質の制御に関する推奨事項を提供しています。このRFCの目的は、異なるサービスクラスのトラフィックを効果的に管理し、ネットワークのパフォーマンスと効率を向上させることです。
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
DiffServサービスクラスの構成ガイドライン
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).
Copyright（c）The Internet Society（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で構成されたサービスクラスについて説明し、それらを使用する方法と、差別化されたサービスコードポイント（DSCPS）、トラフィックコンディショナー、ホップごとの動作（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.
このドキュメントの役割を理解するために、類似性を使用します。差別化されたサービス仕様は、基本的にツールキットです。仕様は、バンドソー、プレーナー、ドリルプレス、およびその他のツールに相当するものを提供します。専門家の手には、構築できるものに制限はありませんが、そのようなツールキットは、本棚を構築したいだけの専門家にアクセスできないという点に威圧的になる可能性があります。このドキュメントは、必要なすべての（diffserv）家具を構築するための一連の「プロジェクト計画」と見なす必要があります。ユーザーは、何を構築するかを選択できます（たとえば、おそらく私たちの非専門家は今のところ中国のキャビネットを必要としない可能性があります）、そしてそれを構築する方法（例えば、非専門家の計画はおそらくMortise/Tenonを採用しないでしょう/建設ですが、その不在は、ほこり/テノンの建設が禁止または不健全であることを意味するものではありません）。著者は、これらの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で構成されたサービスクラスについて説明し、それらを使用する方法と、差別化されたサービスコードポイント（DSCPS）、トラフィックコンディショナー、ホップごとの動作（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の異なるサービスクラス、2つはネットワーク操作/管理用、およびユーザー/サブスクライバーのアプリケーション/サービス用10を定義しました。ただし、ネットワーク管理者は、顧客とサービス提供に関連するこれらのクラスのサブセットを実装することを期待しています。ネットワーク管理者は、ローカルで定義されたサービスクラスを追加する価値があることもあることがありますが、これらは必ずしも同じタイプのエンドツーエンドプロパティを享受するわけではありません。
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].
キーワードは「 "lows" "" lows "、" not "、" expering "、" shall "、" shall "、" sulld "、" not "、" becommended "、" 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と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アクセスネットワークでは、状態はしばしば異なります。これは、スループットレートが人為的に制限されているか、過剰に登録されているか、またはアクセスネットワーク設計のトレードオフによるものかもしれません。o Webサーバー上のデータベース設計（FileStoreで競合ポイントを作成する可能性がある）やファイアウォールとルーターの構成など、その他の特性は、多くの場合、帯域幅の制限のように外部的に見えます。
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]に精通している必要があります。ここでは、読者に利便性を提供するためだけに重要な概念を再現します。これは、権威ある定義を提供する参照RFCSです。
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.
優先キューまたはキューイングシステムは、優先度の低いキューの飢vを避ける必要があります。これは、入場管理、レート管理、ネットワークエンジニアリングなど、さまざまな手段を通じて達成できます。
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.
同様に、レートベースのキューイングシステムは、一連のキューと、指定されたレートでそれぞれを空にするスケジューラの組み合わせです。レートベースのキューイングシステムの例は、ストップライトとの道路交差点です。Stoplightはスケジューラとして機能し、各レーンに交差点を通り抜ける特定の機会を与えます。
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）は、パケットドロップまたはマーキングを使用してキューの深さを管理するさまざまな手順の汎用名です。このような手順の標準的な例は、ランダムな早期検出（赤）であり、キューに最小限と最大しきい値が割り当てられ、キューイングアルゴリズムはキューの深さの移動平均を維持します。平均キューの深さは最大のしきい値を超えていますが、到着するトラフィックはすべて減少します。平均キューの深さは最小しきい値を超えていますが、最大のしきい値を超えていませんが、到着するトラフィックのランダムに選択されたサブセットがマークまたはドロップされます。このトラフィックのマーキングまたはドロップは、送信システムと通信し、混雑回避アルゴリズムを開始することを目的としています。この動作の結果、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.
アルゴリズムのバリエーションは、PHB [RFC2597]を保証された転送に適用されます。これは、動作の集計は、共通のキューに混ざり合っている複数のDSCPマークを持つトラフィックで構成されているからです。複数のDSCPに対して別の最小値と最大値が個別に構成されているため、Ingressでの記載されているレートを超えるトラフィックは、契約率内のトラフィックよりもドロップまたはマークされる可能性が高くなります。
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]のように、ポリシーに従ってトラフィックを測定およびドロップまたはマークすることができます。。これは、「Assured PHB」[RFC2597]で行われるように、フィードバックループをバイアスするために使用されるか、「迅速な転送PHB」[RFC3246]で行われるように、システムのトラフィックの量を制限するために使用できます。このような測定手順は、集合的に「トラフィックコンディショナー」と呼ばれます。トラフィックコンディショナーは、通常、diffservモデル[RFC3290]のセクション1.5.3のように、たとえばコミットされたレートとバーストサイズなど、トークンバケットメーターを使用して構築されます。Assured Forwarding 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の場合、レートとバーストサイズのコントロールを提供するための単一のトークンバケットメーター。o保証された転送（AF）PHB、通常、「2つのレート3色マーカー（TRTCM）」[RFC2698]または「シングルレート3色マーカー（SRTCM）」[RFC2697]で概説されている動作を提供するように構成された2つのトークンバケットメーターの場合。2レートの3色マーカーは2つのレートを強制するために使用されますが、単一率の3色マーカーは、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つの基本的な転送行動が定義され、一般的な使用のために特徴付けられています。これらは、弾性トラフィックの基本的なデフォルト転送（DF）動作、保証された転送（AF）動作、およびリアルタイム（非弾性）トラフィックの迅速な転送（EF）動作です。AFには4つのコードポイントが推奨され、EFに1つのコードポイントが推奨されるという事実は任意の選択肢であり、アーキテクチャにより、合理的な数の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]に記載されているクラスです。Best-Effortサービスは、「私はあなたのパケットを受け入れます」として要約される場合があり、通常、帯域幅保証で構成されています。輸送中のパケットは、ランダムに失われたり、並べ替えたり、複製されたり、遅延したりする場合があります。一般に、ネットワークはこの動作を制限するように設計されていますが、トラフィック負荷を変更すると、あらゆるネットワークがそのような状態に押し込まれます。
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]動作は、フレームリレーのDiscard適格（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値が提供され（2つまたは3つ、おそらくローカル値を使用して）、トラフィックを識別し、集合体を保存するための共通のキュー、およびネットワークを保護し、遅延を制限するアクティブキュー管理を識別します。トラフィックはネットワークに入るときに計量され、総計の到着率に応じてトラフィックはさまざまにマークされます。前提は、ユーザーが契約が規定するよりも多くの容量を使用することが時々普通であるということです。ただし、キューを管理するためにトラフィックをマークまたは紛失する必要がある場合、この余分なトラフィックは最初にマークまたは失われます。
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ネットワークを介した「ワイヤのような」動作を必要とするデータ情報の輸送に使用されます。Voiceは、容量の可用性に関係なく、コーデックが生成する速度でパケットを送信する非弾力性のある「リアルタイム」アプリケーションです。そのため、このサービスは、制御されていない場合、ネットワークを混乱または混雑させる可能性があります。また、虐待の可能性もあります。
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.
ネットワークを保護するために、少なくともさまざまな時点でトラフィックを警察する必要があります。キューの設計がオーバーランしないことを確認し、トラフィックに低遅延キューを与えられる必要があります（多くの場合、優先度を使用していますが、レートが主張されていますが - ベースのキューはこれを行うことができます）遅延の変動が問題ではないことを確認し、アプリケーションのニーズを満たすことができます。
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要件をサポートします。クラスセレクターDSフィールドは、[RFC2474]、セクション4に記載されているように、レガシー（diffserv以前の）プラクティスとの限られた後方互換性を提供します。後方互換性は2つの方法で対処されます。まず、すでに広く使用されているホップごとの動作があります（たとえば、[RFC1812]で指定されたIPv4の優先順位Queuing要件を満たしているもの）。さらに、IP優先順位フィールドの履歴使用に対応するコードポイントがいくつかあり、[RFC2474]で指定された一般的な要件を満たすPHBにマッピングするようにこれらのコードポイントを予約します。セクション4.2.2.2。
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]で定義されているように、IPv4 TOSオクテットの「DTR」またはタイプのサービス（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グループのセットで展開できます。また、ネットワーク管理者は、DSCPフィールドのビット3〜5に関係なく、コードポイントをPHBにマッピングするようにネットワークノードを構成して、履歴IPの優先順位の使用と互換性のあるネットワークを生成する場合があります。したがって、たとえば、CodePoint '011000'は、CodePoint '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.
入場管理（ポリシーのしきい値が相互に渡された場合の拒否を含む）は、帯域幅の可用性が負荷をかけることを保証することにより、高品質の通信を確保することができます。Voice Over Internet Protocol（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、メガコ、リソース予約プロトコル（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つのグループに分割することを選択しました。サービスの差別化を提供するために、各グループで異なるサービスクラスが定義されます。さらに、ネットワーク制御トラフィックグループは、2つのサービスクラスに分割できます（各サービスクラスの詳細な定義については、セクション3を参照してください）。
o "Network Control" for routing and network control function. o "OAM" (Operations, Administration, and Management) for network configuration and management functions.
o ルーティングおよびネットワーク制御機能の「ネットワーク制御」。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):
ユーザー/サブスクライバートラフィックグループは、10のサービスクラスに分類され、さまざまな種類のアプリケーション/サービスのサービス差別化を提供します（各サービスクラスの詳細な定義についてはセクション4を参照）。
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、Media Gateway Controlプロトコル（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 マルチメディア会議サービスクラスは、混雑の検出時に送信速度を下げることができるビデオ会議ソリューション用です。したがって、これらのフローは、レート適応として分類できます。現在、IPネットワーク（非弾性トラフィックを生成するものとレート適応トラフィックを生成するもの）で2種類のビデオ会議機器が使用されているため、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
Best-Effortカテゴリ
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は、各サービスクラスがサービスを提供するトラフィックの動作ビューを示しています。トラフィック特性列は、サービスされたフローの特性とプロファイルを定義し、損失、遅延、およびジッタの列に対する許容範囲は、フローが受ける処理を定義します。End-to-Endの定量的パフォーマンス要件は、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 CodePointの割り当ての間の推奨される関係を定義しています。この関係を端から端まで保存することをお勧めします。
------------------------------------------------------------------
| 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
図4.各サービスクラスに使用されるQoSメカニズムの概要
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 Edgeでのコンディショニングとは、トラフィックコンディショニングが、信頼されていないユーザーデバイスが接続されているDiffServネットワークのエッジで実行されるか、2つのDiffServネットワーク間で実行されることを意味します。o "sr bs"は、バーストサイズ制御を備えた単一レートを提供するポリシングメカニズムを表します。oシングルレート、3色マーカー（SRTCM）動作はRFC 2697と同等である必要があり、2レートの3色マーカー（TRTCM）動作はRFC 2698と同等でなければなりません。OリアルタイムインタラクティブのPHBサービスクラスは、高い帯域幅保証を提供するように構成する必要があります。リラックスしたパフォーマンスパラメーターとレートスケジューラを使用する2番目のEF PHBとして構成される場合があります。oブロードキャストビデオサービスクラスのPHBは、高い帯域幅保証を提供するように構成する必要があります。リラックスしたパフォーマンスパラメーターとレートスケジューラを使用する3番目のEF PHBとして構成される場合があります。o IP優先順位マーキングを使用するネットワークセグメントでは、2つのサービスクラスのうち1つのみをサポートできる、ハイスループットデータまたは低価格データ。サポートされていないサービスクラスのDSCP値を、イングレス時に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.
ネットワーク管理者は、顧客に提供するサービスのために、ネットワークで異なるパフォーマンスレベル（サービスの品質）を提供する必要があると判断します。彼は自分のネットワークが提供できるようにする必要があります：o信頼できる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現在のインターネットサービスをサポートするために、ネットワークを介して通常（未分化）転送処理を受けるすべてのトラフィックの標準サービスクラス。o VoIP（テレフォニー）ベアラートラフィック用のテレフォニーサービスクラス。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シングルレートの3色マーカー（SRTCM）動作は、RFC 2697と同等である必要があります。Oサポートされているサービスクラスで表されないDSCP値でマークされたパケットは、標準のサービスクラスを使用して転送する必要があります。
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 VoIP（テレフォニー）サービスを補完するSIPベースのデスクトップビデオ会議機能。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.
o MPEG-4の輸送のためのリアルタイムインタラクティブサービスクラスは、デスクトップビデオ会議をサポートするためのリアルタイムビデオフローをサポートします。ビデオ会議のコントロール/シグナリングは、シグナリングサービスクラスを使用して行われます。o IPTVブロードキャスト情報の輸送のためのブロードキャストビデオサービスクラス。チャネルの選択と制御は、信号サービスクラスにマッピングされたIGMPを介して行われます。o保存されたMPEG-2またはMPEG-4コンテンツの輸送のためのマルチメディアストリーミングサービスクラス。ストリーミング情報の選択と制御は、シグナリングサービスクラスを使用して行われます。このサービスに使用されるセットトップボックスには、弾性ストリーミング情報の帯域幅の変動を補うためのローカルバッファリング機能があるため、オンデマンドムービーサービス用のマルチメディアストリーミングサービスクラスの選択が選択されました。オンデマンド映画サービスの輸送が弾力性がない場合は、ブロードキャストビデオサービスクラスを使用する必要があることに注意してください。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シングルレートの3色マーカー（SRTCM）の動作はRFC 2697と同等であり、2レートの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通常の（未分化）転送治療を受けるすべてのトラフィックの標準サービスクラス。o VoIP（テレフォニー）ベアラートラフィック用のテレフォニーサービスクラス。o VoIPサービスを制御するためのテレフォニーシグナリングのシグナリングサービスクラス。o H.323/V2または同様の機器を使用した会議間の部屋のビデオ会議サービスのサポートのためのマルチメディア会議サービスクラス。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シングルレートの3色マーカー（SRTCM）の動作はRFC 2697と同等である必要があり、2レートの3色マーカー（TRTCM）の動作はRFC 2698に相当する必要があります。ODSCPでマークされたパケットサポートされているサービスクラスで表されない値は、標準のサービスクラスを使用して転送する必要があります。
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 Ingressで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 Control service class SHOULD be configured to use a Rate Queuing system such as defined in Section 1.4.1.2 of this document.
ネットワーク制御サービスクラスは、[RFC2474]で定義されているDiffServクラスセレクター（CS）PHBを使用して構成する必要があります。このサービスクラスは、パケットが常にタイムリーなサービスを受信できるように、トラフィックが最小帯域幅保証を受信するように構成する必要があります。ネットワーク制御サービスクラスの構成された転送リソースは、このサービスクラスでピーク負荷の下でパケットドロップの確率が非常に低くなるようにする必要があります。ネットワーク制御サービスクラスは、このドキュメントのセクション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可変サイズのパケット、通常は一度に1つのパケットですが、トラフィックも破裂する可能性があります（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が設置されているピアリングポイント（2つのDiffservネットワークの間）では、CS6マーク付きパケットをポリシングする必要があります。SLAで指定されています。O CS6マークされたパケットフローは、信頼できないソース（たとえば、エンドユーザーデバイス）から、Ingressで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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、最小控除はターゲットキューの深さを指定し、最大布地はすべてのトラフィックがドロップされるか、ECNがマークされているキューの深さを指定します。したがって、このサービスクラスでは、次の不平等がキュー構成に保持する必要があります。
o min-threshold CS6 < max-threshold CS6 o max-threshold CS6 <= memory assigned to the queue
o min-threshold cs6 <max-threshold cs6 o max-threshold 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（運用、管理、および管理）サービスクラスは、Simple Network Management Protocol（SNMP）、Trivial File Transfer Protocol（TFTP）、FTP、Telnet、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 Network Edgeで実行される推奨コンディショニング：
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]で定義されているMultifield（MF）分類方法を使用して、IngressでDiffservネットワークに検証する必要があります。o信頼されていないソース（エンドユーザーデバイス）からのパケットフローは、Ingressで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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、MIN-THRESHOLDは各DSCPのターゲットキューの深さを指定し、Max授業は、そのようなDSCPを使用したすべてのトラフィックがドロップされるか、ECNがマークされているキューの深さを指定します。したがって、このサービスクラスでは、次の不平等がキュー構成に保持する必要があります。
o min-threshold CS2 < max-threshold CS2 o max-threshold CS2 <= memory assigned to the queue
o min-threshold cs2 <max-threshold cs2 o max-threshold 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、メガコなど）を使用して、テレフォニーコールサーバー/ゲートキーパーによって実行されます。コアネットワークの帯域幅とサポートできる同時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およびその他のコーデック）。o IP（モデム、FAX）上の音声バンドデータ。o T.38 IP上のファックス。o IP、仮想ワイヤなどの回路エミュレーション。O単一レート、平均ネットワーク遅延を指定するIP IP仮想プライベートネットワーク（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.
o VoIP用の主に固定サイズのパケット（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およびその他のコーデック）。o IP（モデムとファックス）の音声バンドデータ。o T.38 IP上のファックス。o IP、仮想ワイヤなどの回路エミュレーション。
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]で定義されているMultifield（MF）分類方法を使用して、IngressでDiffservネットワークに検証する必要があります。o信頼されていないソース（エンドユーザーデバイス）からのパケットフローは、Ingressで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）の回路スイッチ交換にインターフェイスするVoIPサービスの呼び出しの開始時にリングクリッピングの可能性を最小限に抑えるには、シグナリングサービスクラスを構成して、パケットドロップまたは重要なキューイング遅延の確率を設定する必要があります。このインターフェイスを提供するIPネットワークセグメントでは、ピーク負荷は非常に低いです。「リングクリッピング」という用語は、ベアラーパスがすべての可聴リンギング信号を運ぶために時間内に利用できないため、リンギング信号のフロントエンドが変更されるインスタンスを指します。この状態は、回路スイッチ交換のトーンジェネレーターがオンになっている場合とIPネットワークを通るベアラーパスが有効になっている場合の間のレース条件のために発生する可能性があります。「リングクリッピング」の追加の説明については、セクション8.1を参照し、セクション5.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テレフォニーシグナリング（たとえば、SIP、H.323を使用）。oマルチメディアアプリケーション用のピアツーピアシグナリング（SIP、H.323の使用など）。oピアツーピアリアルタイム制御機能。o H.248、Megaco、MGCP、IPカプセル化ISDN、またはその他の独自のプロトコルを使用したクライアントサーバーIPテレフォニーシグナリング。o IGMPなどのプロトコルを使用してIPTVアプリケーションを制御するシグナリング。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 可変サイズのパケット、通常は一度に1つのパケット。o断続的なトラフィックフロー。oトラフィックが破裂する場合があります。o 2つのエンドポイント間で送信される遅延依存制御メッセージ。
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 Network Edgeで実行される推奨コンディショニング：
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).
o [RFC2475]で定義されたMultifield（MF）分類方法を使用して、信頼されていないソース（エンドユーザーデバイス）からのパケットフローマーキング（DSCP設定）は、IngressでDiffservネットワークに検証する必要があります。o信頼されていないソース（エンドユーザーデバイス）からのパケットフローは、Ingressで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機器で使用される1つのアプローチは、受信機が事前に構成されたレベルのパケット損失を検出すると、トランスミッターにパス中の鬱血の可能性を示すことです。利用可能な場合、トランスミッターはより低いレートエンコーディングコーデックを選択します。今日、多くのH.323/V2ビデオ会議ソリューションは、段階的なCBRに似たトラフィック、固定ステップ帯域幅の変化（通常はレートの削減）を実装することに注意してください。
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]で定義されているAssured Forwarding（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およびVideo Conferencingアプリケーションの後のバージョン（インタラクティブビデオ）。
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アプリケーションサーバーからアプリケーションサーバー非燃えるようなデータ転送非常に低い遅延が必要です。oネットワーク伝播遅延よりもわずかに長い2つのレートと平均ネットワーク遅延を指定する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レートの3色マーカーは、色覚異常モードで動作するように構成されます。
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".
o AF41 =指定されたレート「A」まで。o AF42 =指定されたレート「A」を超えるが、指定されたレート「B」以下。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".
o AF41 = H.323ビデオ会議オーディオストリームRTP/UDP。o AF41 = H.323ビデオ会議ビデオコントロールRTCP/TCP。o af41 = h.323ビデオ会議ビデオストリームを指定されたレート「a」まで。o AF42 = H.323ビデオ会議のビデオストリームは、指定されたレート「A」を超えるが、指定されたレート「B」以下で。o AF43 = H.323ビデオ会議ビデオストリームを指定されたレート「B」を超えるビデオストリーム。oここで、「a」<"b"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServ Network Edgeで実行される推奨コンディショニング：
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.
o TRTCM [RFC2698]で定義されている動作を提供するように、2レートの3色マーカーを構成する必要があります。oパケットが信頼できるソースまたは以前に信頼されていたDiffServドメインによってマークされており、カラーマーキングを保存する場合、2レートの3色マーカーをカラーアウェアモードで動作させるように構成する必要があります。oパケットマーキングが信頼されていない場合、またはカラーマーキングが保存されない場合、2レートの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]は、主に輻輳下でビデオエンコーディングレートを切り替えるために使用する必要があります。AF41トラフィックの損失の確率は、AF42トラフィックの損失の確率を超えてはなりません。これは、AF43トラフィックの損失の可能性を超えてはなりません。
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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、MIN-THRESHOLDは各DSCPのターゲットキューの深さを指定し、Max授業は、そのような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 min-threshold af43 <max-threshold af43 o max-threshold af43 <= min-thReshold af42 o min-thReshold af42 <max-threshold af42 o max-th-threshold af42 <= min-threshold af41 o min-threshold af41 <max-shersholdaf41 o最大閾値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.
注：この構成は、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で定義されているようなレートキューイングシステムを使用するように構成する必要があります。このサービスクラスは、リラックスしたパフォーマンスパラメーター、レートスケジューラ、およびCS4 DSCP値を使用する2番目のEF PHBとして構成される場合があることに注意してください。
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 Network Edgeで実行される推奨コンディショニング：
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).
o [RFC2475]で定義されたMultifield（MF）分類方法を使用して、信頼されていないソース（エンドユーザーデバイス）からのパケットフローマーキング（DSCP設定）は、IngressでDiffservネットワークに検証する必要があります。o信頼されていないソース（エンドユーザーデバイス）からのパケットフローは、Ingressで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]で定義されているAssured Forwarding（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ウェブキャスト。o 2つのレートを指定し、遅延とジッターに敏感ではない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.
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レートの3色マーカーは、色覚異常モードで動作するように構成されます。
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".
o AF31 =指定されたレート「A」まで。o AF32 =指定されたレート「A」を超えるが、指定されたレート「B」以下。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 Network Edgeで実行される推奨コンディショニング：
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.
o TRTCM [RFC2698]で定義されている動作を提供するように、2レートの3色マーカーを構成する必要があります。oパケットが信頼できるソースまたは以前に信頼されていたDiffServドメインによってマークされており、カラーマーキングを保存する場合、2レートの3色マーカーをカラーアウェアモードで動作させるように構成する必要があります。oパケットマーキングが信頼されていない場合、またはカラーマーキングが保存されない場合、2レートの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トラフィックの損失の確率は、AF32トラフィックの損失の確率を超えてはなりません。これは、AF33の損失の可能性を超えてはなりません。
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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、MIN-THRESHOLDは各DSCPのターゲットキューの深さを指定し、Max授業は、そのような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 min-threshold af33 <max-thReshold af33 o max-thReshold af33 <= min-thReshold af32 o min-thReshold af32 <max-thReshold af32 o max-th-thReshold af32 <= min-threshold af31 o min-threshold af31 <max-shersholdholdaf31 o max-threshold 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.
注：この構成は、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.
ブロードキャストビデオサービスクラスは、リアルタイムインタラクティブサービスクラスを使用してアプリケーションほど遅延に敏感ではない一定の速度と変動レートの非弾性交通源のパケット損失が非常に低いため、ほぼリアルタイムパケット転送を必要とするアプリケーションに推奨されます。このようなアプリケーションには、放送テレビ、ライブオーディオおよびビデオイベントのストリーミング、いくつかのビデオオンデマンドアプリケーション、ビデオ監視が含まれます。一般に、ブロードキャストビデオサービスクラスは、宛先エンドポイントにはdejitterバッファーがあると想定しています。ビデオアプリケーションでは通常2〜8のビデオフレームバッファー（66から数百ミリ秒）があり、したがって、遅延と遅延と低敏感であり、ジッター。
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 MAY be configured as a third EF PHB that uses relaxed performance parameter, a rate scheduler, and CS3 DSCP value.
ブロードキャストビデオサービスクラスは、[RFC2474]で定義されているクラスセレクター（CS）PHBを使用する必要があります。このサービスクラスは、CS3マークされたパケットの帯域幅の高い保証を提供して、それらが転送されることを確認するように構成する必要があります。ブロードキャストビデオサービスクラスは、このドキュメントのセクション1.4.1.2で定義されているようなレートキューイングシステムを使用するように構成する必要があります。このサービスクラスは、リラックスしたパフォーマンスパラメーター、レートスケジューラ、およびCS3 DSCP値を使用する3番目の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 ビデオ監視とセキュリティ（ユニキャスト）。o HDTV（マルチキャスト）を含むテレビ放送。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）CodePoint（s）は、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 Network Edgeで実行される推奨コンディショニング：
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 [RFC2475]で定義されたMultifield（MF）分類方法を使用して、信頼されていないソース（エンドユーザーデバイス）からのパケットフローマーキング（DSCP設定）は、IngressでDiffservネットワークに検証する必要があります。o信頼されていないソース（エンドユーザーデバイス）からのパケットフローは、Ingressで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ページでハイパーリンク（〜1ダースバイト）をクリックして、新しいWebページをロードするとき（データのKBYTES）です。このサービスクラスは、可変レートトラフィックソースのリアルタイムパケット転送を必要とする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]で定義されているAssured Forwarding（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 クライアント/サーバーアプリケーション。oシステムネットワークアーキテクチャ（SNA）端子をホストトランザクション（データリンクスイッチング（DLSW）を使用したSNAオーバーIP）。o Webベースのトランザクション（eコマース）。oクレジットカードトランザクション。o金融電信送金。oエンタープライズリソース計画（ERP）アプリケーション（SAP/BAANなど）。o最大2つのバーストサイズでコミットされた情報レート（CIR）をサポートする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可変パケット排出率。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 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としてマークする必要があります。注：この場合、シングルレートの3色マーカーは、色覚異常モードで動作するように構成されます。
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".
o AF21 =「A」バイトまでのパケットバーストサイズを備えたフローストリーム。o af22 =パケットバーストサイズを「a」を超えるが、「b」の下にあるフローストリーム。o AF23 =「B」バイトを超えるパケットバーストサイズを備えたフローストリーム。oここで、「a」<"b"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServ Network Edgeで実行される推奨コンディショニング：
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]で定義されている動作を提供するように、単一率の3色マーカーを構成する必要があります。oパケットが信頼できるソースまたは以前に信頼されていたDiffServドメインによってマークされ、色マークを保存する場合、シングルレートの3色マーカーをカラーアウェアモードで動作させるように構成する必要があります。oパケットマーキングが信頼されていない場合、またはカラーマーキングが保存されない場合、シングルレートの3色マーカーは、色盲モードで動作するように構成する必要があります。
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トラフィックの損失の確率は、AF22トラフィックの損失の確率を超えてはなりません。これは、AF23の損失の可能性を超えてはなりません。明示的な混雑通知（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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、MIN-THRESHOLDは各DSCPのターゲットキューの深さを指定し、Max授業は、そのような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 min-threshold af23 <max-threshold af23 o max-threshold af23 <= min-thReshold af22 o min-thReshold af22 <max-threshold af22 o max-th-threchold af22 <= min-threshold af21 o min-threshold af21 <max-shersholdholdaf21 o max-threshold 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.
注：この構成は、AF22より前にAF23トラフィックをAF22より前にAF21の前にドロップする傾向があります。他の多くの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]で定義されているAssured Forwarding（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メール。o 2つのレートをサポートする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変数。o TCPウィンドウサイズのパケットバースト付き。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レートの3色マーカーは、色覚異常モードで動作するように構成されます。
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".
o AF11 =指定されたレート「A」まで。o AF12 =指定されたレート「A」を超えるが、指定されたレート「B」以下。o af13 =指定されたレート「b」を超える。oここで、「a」<"b"。
RECOMMENDED conditioning performed at DiffServ network edge:
DiffServ Network Edgeで実行される推奨コンディショニング：
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.
o TRTCM [RFC2698]で定義されている動作を提供するように、2レートの3色マーカーを構成する必要があります。oパケットが信頼できるソースまたは以前に信頼されていたDiffServドメインによってマークされており、カラーマーキングを保存する場合、2レートの3色マーカーをカラーアウェアモードで動作させるように構成する必要があります。oパケットマーキングが信頼されていない場合、またはカラーマーキングが保存されない場合、2レートの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トラフィックの損失の確率は、AF12トラフィックの損失の確率を超えてはなりません。これは、AF13の損失の可能性を超えてはなりません。そのような場合、あるネットワークの顧客がかなりの過剰を運転しており、別のネットワークがリンクを使用しようとしている場合、損失は高額なユーザーが経験し、レートを引き下げます。明示的な混雑通知（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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、MIN-THRESHOLDは各DSCPのターゲットキューの深さを指定し、Max授業は、そのような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 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 AF11af11 o max-threshold 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.
注：この構成は、AF12の前とAF12の前にAF13より前に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ネットワークドメインの他のサポートされている転送サービスクラスの1つに分類されていないトラフィックに推奨されます。このサービスクラスは、インターネットの「最高の」転送動作を提供します。このサービスクラスには通常、最小帯域幅保証があります。
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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、最小控除はターゲットキューの深さを指定し、最大布地はすべてのトラフィックがドロップされるか、ECNがマークされているキューの深さを指定します。したがって、このサービスクラスでは、次の不平等がキュー構成に保持する必要があります。
o min-threshold DF < max-threshold DF o max-threshold DF <= memory assigned to the queue
o min-threshold df <max-threshold df o max-threshold 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]を介して輸送を実行するアプリケーションにサービスを提供し、ユーザーは保証なしでサービスを受け入れることをいとわないことを提供します。このサービスクラスは、[RFC3662]および[QBSS]で指定されています。
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 帯域幅保証を必要としないDiffServ対応ネットワークを介して輸送されるTCPベースのアプリケーション/パケットフロー。
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].
一般的な構成では、明示的な輻輳通知[RFC3168]またはランダム損失を使用して、アクティブキュー管理[RFC2309]を実装する必要があります。
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:
赤[RFC2309]がAQMアルゴリズムとして使用されている場合、最小控除はターゲットキューの深さを指定し、最大布地はすべてのトラフィックがドロップされるか、ECNがマークされているキューの深さを指定します。したがって、このサービスクラスでは、次の不平等がキュー構成に保持する必要があります。
o min-threshold CS1 < max-threshold CS1 o max-threshold CS1 <= memory assigned to the queue
o min-threshold cs1 <max-threshold cs1 o max-threshold 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).
o H.248、Megaco、MGCP、IPカプセル化ISDN、または独自のプロトコルを使用したIPテレフォニーの多くの実装で使用されるクライアントサーバーシグナリングには、CS5 DSCPがマークされています（シグナリングサービスクラスを使用）。o SIP、SIP-T、またはIPカプセル化されたISUPを使用したキャリアのネットワークのコールサーバーまたはソフトスイッチ間のシグナリングには、CS5 DSCPがマークされています（シグナリングサービスクラスを使用）。o RSVPシグナル伝達はアプリケーションに依存します。RSVPシグナル伝達がINTSERVで使用されているように「オンパス」である場合、同じキュー（サービスクラス）から転送し、制御しているアプリケーションデータと同じDSCP値でマークする必要があります。これは、シグナリング（NSIS）プロトコルの「オンパス」次のステップにも適用される場合があります。o IGMPがIPTVシステムのチャネル変更などのマルチキャストセッションコントロールに使用される場合、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.
o 管理者（キャリア）ネットワーク内またはエンドユーザー/クライアントに高精度のタイミングを提供するためにNTPが使用される場合、テレフォニーサービスクラスを使用する必要があり、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]は、Diffservアーキテクチャとさまざまな形のIPトンネルとの相互作用を考慮します。さらに、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.
o PHBまたはPHBグループを表すために/使用されるDSCP値は、DSCPの発言がトンネルの侵入/出口処理関数として行われない限り、VPNトンネルの両端のネットワークで同じでなければなりません。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トラフィック転送行動にマッピングされます。o VPNサービスを提供しているネットワーク内のトラフィック処理は、カプセル化されたサービスクラスまたはクラスが遅延、ジッター、パケット損失の観点から同等の動作とパフォーマンスを受け取り、それらが指定されたサービスの制限内にあるようにする必要があります。。o VPNサービスを提供するネットワークを介して転送されたパケットの外部ヘッダーのDSCP値は、使用されるDSCP値とは異なる場合があります。o 2つ以上のサービスクラスを、VPNサービスを提供しているネットワーク内の単一のトラフィック転送処理に集約するためのガイドラインは、さらなる研究のためです。
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 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が彼がそれを使用することを許可したり、指定されたレートまで使用することを許可した場合の問題ではありません。そのような場合、差別化されたサービスアーキテクチャでは簡単なポリシングが使用されます。ネットワーク制御などの一部のサービスクラスは、ユーザーがまったく使用することは許可されていません。このようなトラフィックは、イングレスフィルターによって落とすか、声を出す必要があります。ユーザーの全人口ではなく、認証されたユーザーにのみ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.
著者は、TSVWGレビュアー、デビッドブラック、ブライアンE.カーペンター、およびアランオニールに、この文書のレビューと入力について感謝します。
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.
著者は、特にブルース・デイビー、デイブ・オラン、ラルフ・サンティトロ、ゲイリー・ケンワード、フランソワ・オーデット、モーガン・リトルウッド、ロバート・ミルン、ジョン・シュラー、ナリン・ミストリー、アル・モートン、マイク・ピアス、エド・ケーラー・ジュニア、ティムRahrer、Fil Dickinson、Mike Fidler、およびShane Amante。キンバリー・キング、ジョー・ゼバルト、アリステア・マンローはそれぞれ徹底的な校正を行い、その文書は彼らの貢献のためにより良いものです。
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.
BEARER PATHセットアップ遅延ターゲットは、ISUP初期アドレスメッセージ（IAM） /アドレス完全メッセージ（ACM）の往復遅延として定義されます。ISUPは、ITU-Tで定義されているように、Signaling System No. 7（SS7）のISDNユーザー部分を指します。これは、ISUP初期アドレスメッセージ（IAM）がトランジット交換を離れ、SS7ネットワーク（該当するSTPSを含む、またはシグナリング転送ポイントを含む）を離れるのにかかる時間で構成され、最終交換によって処理されるためアドレスは、メッセージ（ACM）を完了し、ACMがSS7ネットワークを介して移動してトランジット交換に戻ることができます。Bearer Pathがソフトスイッチメディアゲートウェイと、ACMが発信エンドエクスチェンジに転送されるまでにトランジット交換機能を実行しているIPネットワーク内にセットアップされていない場合、リングクリッピングとして知られる現象が発生する可能性があります。ソフトスイッチメディアゲートウェイ内のACM処理とIPネットワークを介した遅延が過剰になると、Bearer Pathのセットアップが遅れ、したがって着信音の切り抜きが聞こえる可能性があります。
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ミリ秒の遅延予算のうち、200msは交差交差遅延（ソフトスイッチとメディアゲートウェイ）、ネットワーク遅延（キューイングと距離）の40msとして割り当てられます。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、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.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、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] Bless、R.、Nichols、K。、およびK. Wehrle、「差別化されたサービスのドメインごとの挙動（PDB）の低い」、RFC 3662、2003年12月。
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, September 2005.
[Authmech] Rescorla、E。、「認証メカニズムの調査」、2005年9月、進行中の作業。
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 Technical Report Proposed Service Definition, March 2001.
[QBSS]「Qbone Scavenger Service（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] Braden、R.、Clark、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「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. Guerin、「単一レート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. Guerin、「A Rate Three Color Marker」、RFC 2698、1999年9月。
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for Differentiated Services", RFC 2963, October 2000.
[RFC2963] Bonaventure、O。およびS. de Cnodder、「差別化されたサービスのためのレート適応シェーパー」、RFC 2963、2000年10月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、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] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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.、Blake、S.、Grossman、D。、およびA. Smith、「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] Floyd、S.、Henderson、T。、およびA. Gurtov、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 3782、2004年4月。
Authors' Addresses
著者のアドレス
Jozef Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
Jozef Babiarz Nortel Networks 3500 Carling Avenue Ottawa、ONT。K2H 8E9カナダ
Phone: +1-613-763-6098
Fax: +1-613-765-7462
EMail: babiarz@nortel.com
Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica、MA 01821 US
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッド・ベイカー・シスコ・システム1121
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。