[要約] RFC 5865は、容量確保トラフィックのための異なるサービスコードポイント（DSCP）を定義しています。その目的は、ネットワーク上で容量確保されたトラフィックを識別し、優先的に処理することです。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 5865 J. Polk
Updates: 4542, 4594 Cisco Systems
Category: Standards Track M. Dolly
ISSN: 2070-1721 AT&T Labs
May 2010
A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
容量補助トラフィックの差別化されたサービスコードポイント（DSCP）
Abstract
概要
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.
このドキュメントでは、リアルタイムトラフィックのクラスに対して、インターネットに割り当てられた数字局（IANA）から差別化されたサービスコードポイント（DSCP）を要求します。このトラフィッククラスは、迅速な転送ごとの動作に準拠しています。このトラフィックは、認証、承認、および容量入学を含むコール入場制御（CAC）手順を使用して、ネットワークによって認められます。これは、迅速な転送ごとの動作に適合するが、容量入場の対象ではなく、非常に粗い容量入場の対象ではないリアルタイムトラフィッククラスとは異なります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5865.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5865で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Candidate Implementations of the Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . 9
2.3. Recommendations on implementation of an Admitted
Telephony Service Class . . . . . . . . . . . . . . . . . 10
3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This class conforms to the Expedited Forwarding (EF) [RFC3246] [RFC3247] Per-Hop Behavior. It is also admitted using a CAC procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.
このドキュメントでは、リアルタイムトラフィックのクラスに対して、インターネットに割り当てられた数字局（IANA）から差別化されたサービスコードポイント（DSCP）を要求します。このクラスは、迅速な転送（EF）[RFC3246] [RFC3247] 1ホップの動作に準拠しています。また、認証、承認、および容量入場を含むCAC手順を使用して認められています。これは、迅速な転送ごとの動作に適合するが、容量入場の対象ではなく、非常に粗い容量入場の対象ではないリアルタイムトラフィッククラスとは異なります。
In addition, this document recommends that certain classes of video described in [RFC4594] be treated as requiring capacity admission.
さらに、このドキュメントでは、[RFC4594]に記載されている特定のクラスのビデオを容量入場を必要とするものとして扱うことを推奨しています。
Real-time traffic flows have one or more potential congestion points between the endpoints. Reserving capacity for these flows is important to application performance. All of these applications have low tolerance to jitter (aka delay variation) and loss, as summarized in Section 2, and most (except for multimedia conferencing) have inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow behavior and low jitter/loss tolerance are the service characteristics that define the need for admission control behavior.
リアルタイムのトラフィックフローには、エンドポイント間に1つ以上の潜在的な混雑ポイントがあります。これらのフローの予約能力は、アプリケーションのパフォーマンスにとって重要です。これらのアプリケーションはすべて、セクション2で要約されているように、ジッター（別名遅延変動）と損失に対する耐性が低く、ほとんど（マルチメディア会議を除く）は、[RFC4594]の図1から弾力性のない流れの挙動を持っています。非弾性フロー挙動と低ジッター/損失耐性は、入場制御行動の必要性を定義するサービス特性です。
One of the reasons behind the requirement for capacity admission is the need for classes of traffic that are handled under special policies. Service providers need to distinguish between special-policy traffic and other classes, particularly the existing Voice over IP (VoIP) services that perform no capacity admission or only very coarse capacity admission and can exceed their allocated resources.
容量入場の要件の背後にある理由の1つは、特別なポリシーの下で処理されるトラフィックのクラスの必要性です。サービスプロバイダーは、特別なポリシートラフィックと他のクラス、特に容量入場を実行しない、または非常に粗い容量入場のみを実行し、割り当てられたリソースを超えることができる既存の音声（VOIP）サービスを区別する必要があります。
The requested DSCP applies to the Telephony Service Class described in [RFC4594].
要求されたDSCPは、[RFC4594]で説明されているテレフォニーサービスクラスに適用されます。
Since video classes have not had the history of mixing admitted and non-admitted traffic in the same Per-Hop Behavior (PHB) as has occurred for EF, an additional DSCP code point is not recommended within this document for video. Instead, the recommended "best practice" is to perform admission control for all traffic in three of the video classes from [RFC4594]:
ビデオクラスには、EFで発生したのと同じホップあたりの動作（PHB）で入院した混合と非適切なトラフィックの履歴がなかったため、このドキュメントではビデオのDSCPコードポイントを追加することは推奨されません。代わりに、推奨される「ベストプラクティス」は、[RFC4594]の3つのビデオクラスですべてのトラフィックの入場制御を実行することです。
o The Interactive Real-Time Traffic (CS4, used for Video conferencing and Interactive gaming),
o インタラクティブなリアルタイムトラフィック（ビデオ会議とインタラクティブゲームに使用されるCS4）、
o The Broadcast TV (CS3) for use in a video on demand context, and
o ビデオオンデマンドコンテキストで使用するための放送テレビ（CS3）、および
o The AF4 Multimedia Conferencing (video conferencing).
o AF4マルチメディア会議（ビデオ会議）。
Other video classes are believed not to have the current problem of confusion with unadmitted traffic and therefore would not benefit from the notion of a separate DSCP for admitted traffic. Within an ISP and on inter-ISP links (i.e., within networks whose internal paths are uniform at hundreds of megabits per second or faster), one would expect all of this traffic to be carried in the Real-Time Traffic (RTP) class described in [RFC5127].
他のビデオクラスは、現在の混乱のないトラフィックとの混乱の問題を抱えていないと考えられているため、入院したトラフィックのための別のDSCPの概念から恩恵を受けません。ISP内およびISP間のリンク内（つまり、内部パスが数百秒あたりのメガビットまたは速度で均一なネットワーク内）では、このトラフィックがすべてリアルタイムトラフィック（RTP）クラスで記載されていることを期待するでしょう。[RFC5127]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The following terms and acronyms are used in this document.
このドキュメントでは、以下の用語と頭字語が使用されています。
PHB: A Per-Hop Behavior (PHB) is the externally observable forwarding behavior applied at a Differentiated Services compliant node to a DS behavior aggregate [RFC2475]. It may be thought of as a program configured on the interface of an Internet host or router, specified in terms of drop probabilities, queuing priorities or rates, and other handling characteristics for the traffic class.
PHB：ホップごとの動作（PHB）は、DS動作の集約[RFC2475]に差別化されたサービスに準拠したノードに適用される外部観察可能な転送動作です。インターネットホストまたはルーターのインターフェイスで構成されたプログラムと考えられる場合があります。これは、ドロップ確率、優先順位または料金をキューする、およびトラフィッククラスのその他の処理特性の観点から指定されています。
DSCP: The Differentiated Services Code Point (DSCP), as defined in [RFC2474], is a value that is encoded in the DS field, and that each DS Node MUST use to select the PHB that is to be experienced by each packet it forwards [RFC3260]. It is a 6-bit number embedded into the 8-bit TOS (type of service) field of an IPv4 datagram or the Traffic Class field of an IPv6 datagram.
DSCP：[RFC2474]で定義されている差別化されたサービスコードポイント（DSCP）は、DSフィールドでエンコードされた値であり、各DSノードは各パケットが経験するPHBを選択するために使用する必要があります。[RFC3260]。これは、IPv4データグラムの8ビットTOS（サービスのタイプ）フィールドまたはIPv6データグラムのトラフィッククラスフィールドに埋め込まれた6ビット番号です。
CAC: Call Admission Control includes concepts of authorization and capacity admission. "Authorization" refers to any procedure that identifies a user, verifies the authenticity of the identification, and determines whether the user is authorized to use the service under the relevant policy. "Capacity Admission" refers to any procedure that determines whether capacity exists supporting a session's requirements under some policy.
CAC：コール入場制御には、承認と容量の入場の概念が含まれています。「承認」とは、ユーザーを識別し、識別の信頼性を確認し、関連するポリシーの下でサービスを使用することをユーザーが許可されているかどうかを決定する手順を指します。「容量入場」とは、一部のポリシーに基づくセッションの要件をサポートする容量が存在するかどうかを決定する手順を指します。
In the Internet, these are separate functions; while in the Public Switched Telephone Network (PSTN), they and call routing are carried out together.
インターネットでは、これらは個別の機能です。公開された電話ネットワーク（PSTN）にある間、彼らと呼び出しルーティングが一緒に実行されます。
UNI: A User/Network Interface (UNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that do not trust each other, and in which one (the user) purchases connectivity services from the other (the network).
UNI：ユーザー/ネットワークインターフェイス（UNI）は、インターフェイス（多くの場合、物理リンクまたは仮想等価物です）は、お互いを信頼していない2つのエンティティを接続し、1つ（ユーザー）が他方から接続サービスを購入するもの（通信網）。
Figure 1 shows two user networks connected by what appears to each of them to be a single network ("The Internet", access to which is provided by their service provider) that provides connectivity services to other users.
図1は、他のユーザーに接続サービスを提供する単一のネットワーク（「インターネット」、サービスプロバイダーが提供するアクセス）であると思われる2つのユーザーネットワークを示しています。
UNIs tend to be the bottlenecks in the Internet, where users purchase relatively low amounts of bandwidth for cost or service reasons, and as a result are most subject to congestion issues and therefore issues requiring traffic conditioning and service prioritization.
UNIはインターネットのボトルネックである傾向があり、ユーザーはコストまたはサービスの理由で比較的少ない帯域幅を購入するため、その結果、混雑の問題が最も多く、したがってトラフィックコンディショニングとサービスの優先順位付けを必要とする問題があります。
NNI: A Network/Network Interface (NNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that trust each other within limits, and in which the two are seen as trading services for value. Figure 1 shows three service networks that together provide the connectivity services that we call "the Internet". They are different administrations and are very probably in competition, but exchange contracts for connectivity and capacity that enable them to offer specific services to their customers.
NNI：ネットワーク/ネットワークインターフェイス（NNI）は、制限内で互いに信頼する2つのエンティティを接続するインターフェイス（多くの場合、物理リンクまたはその仮想等価物）です。図1は、「インターネット」と呼ばれる接続サービスを一緒に提供する3つのサービスネットワークを示しています。彼らは異なる管理者であり、おそらく競争中ですが、顧客に特定のサービスを提供できるようにするための接続性と能力と交換します。
NNIs may not be bottlenecks in the Internet if service providers contractually agree to provision excess capacity at them, as they commonly do. However, NNI performance may differ by ISP, and the performance guarantee interval may range from a month to a much shorter period. Furthermore, a peering point NNI may not have contractual performance guarantees or may become overloaded under certain conditions. They are also policy-controlled interfaces, especially in BGP. As a result, they may require a traffic prioritization policy.
サービスプロバイダーが一般的にそうであるように、サービスプロバイダーが彼らに過剰な容量を提供することに契約上同意した場合、NNISはインターネット内のボトルネックではないかもしれません。ただし、NNIのパフォーマンスはISPによって異なる場合があり、パフォーマンス保証間隔は月からはるかに短い期間までの範囲です。さらに、ピアリングポイントNNIは、契約上のパフォーマンス保証がない場合があるか、特定の条件下で過負荷になる場合があります。また、特にBGPでは、政策制御のインターフェイスでもあります。その結果、トラフィックの優先順位付けポリシーが必要になる場合があります。
Queue: There are multiple ways to build a multi-queue scheduler. Weighted Round Robin (WRR) literally builds multiple lists and visits them in a specified order, while a calendar queue (often used to implement Weighted Fair Queuing, or WFQ) builds a list for each time interval and queues at most a stated amount of data in each such list for transmission during that time interval. While these differ dramatically in implementation, the external difference in behavior is generally negligible when they are properly configured. Consistent with the definitions used in the Differentiated Services Architecture [RFC2475], these are treated as equivalent in this document, and the lists of WRR and the classes of a calendar queue will be referred to uniformly as "queues".
キュー：マルチキュースケジューラを構築するには、複数の方法があります。重み付きラウンドロビン（WRR）は文字通り複数のリストを構築し、指定された順序でそれらを訪問しますが、カレンダーキュー（重み付き公正キューイングまたはWFQの実装によく使用されることが多い）は、各時間間隔とキューのリストを作成し、最大量のデータを作成します。その時間間隔中の送信用の各リストで。これらの実装は劇的に異なりますが、動作の外部の違いは、適切に構成されている場合、一般に無視できます。差別化されたサービスアーキテクチャ[RFC2475]で使用される定義と一致して、これらはこのドキュメントで同等のものとして扱われ、WRRのリストとカレンダーキューのクラスは「キュー」と均一に呼ばれます。
_.--------.
,-'' `--.
,-' `-.
,-------. ,',-------. `.
,' `. ,',' `. `.
/ User \ UNI / / Service \ \
( Network +-----+ Network ) `.
\ / ; \ / :
`. ,' ; `. .+ :
'-------' / '-------' \ NNI \
; \ :
; "The Internet" \ ,-------. :
; +' `. :
UNI: User/Network Interface / Service \ |
| ( Network ) |
NNI: Network/Network Interface \ / |
: +. ,' ;
: / '-------' ;
: / ;
,-------. \ ,-------. / NNI /
,' `. : ,' `+ ;
/ User \ UNI / Service \ ;
( Network +-----+ Network ) ,'
\ / \ \ / /
`. ,' `.`. ,' ,'
'-------' `.'-------' ,'
`-. ,-'
`--. _.-'
`--------''
Figure 1: UNI and NNI Interfaces
図1：UNIおよびNNIインターフェイス
In short, the Telephony Service Class, described in [RFC4594], permits the use of capacity admission in implementing the service, but present implementations either provide no capacity admission services or do so in a manner that depends on specific traffic engineering. In the context of the Internet backbone, the two are essentially equivalent; the edge network depends on specific engineering by the service provider that might not be present, especially in a mobile environment.
要するに、[RFC4594]に記載されているテレフォニーサービスクラスでは、サービスの実装に容量入場の使用が許可されていますが、実装は容量入場サービスを提供しないか、特定のトラフィックエンジニアリングに依存する方法でそうします。インターネットバックボーンのコンテキストでは、2つは本質的に同等です。エッジネットワークは、特にモバイル環境では存在しない可能性のあるサービスプロバイダーによる特定のエンジニアリングに依存します。
However, services are being requested of the network that would specifically make use of capacity admission, and would distinguish among users or the uses of available Voice-over-IP or Video-over-IP capacity in various ways. Various agencies would like to provide services as described in RFC [RFC4190] or in Section 2.6 of [RFC4504].
ただし、容量入場を特に使用するネットワークのサービスは、さまざまな方法でユーザーまたは利用可能なボイスオーバーIPまたはビデオオーバーIPの容量の使用を区別します。さまざまな機関は、RFC [RFC4190]または[RFC4504]のセクション2.6で説明されているようにサービスを提供したいと考えています。
This requires the use of capacity admission to differentiate among users to provide services to them that are not afforded to non-capacity admitted customer-to-customer IP telephony sessions.
これには、容量のない顧客から顧客へのIPテレフォニーセッションに提供されていないサービスを提供するために、ユーザー間を区別するために容量入場を使用する必要があります。
There are at least two possible ways to implement isolation between the Capacity Admitted PHB and the Expedited Forwarding PHB in this model. They are to implement separate classes as a set of
このモデルで認められたPHBと迅速な転送PHBとの間に分離を実装するには、少なくとも2つの可能な方法があります。彼らは一連のセットとして個別のクラスを実装することです
o Multiple data plane traffic classes, each consisting of a policer and a queue, with the queues enjoying different priorities, or
o それぞれがポリサーとキューで構成される複数のデータプレーントラフィッククラス、キューが異なる優先順位を享受している、または
o Multiple data plane traffic classes, each consisting of a policer but feeding into a common queue or multiple queues at the same priority.
o 複数のデータプレーントラフィッククラスは、それぞれがポリサーで構成されていますが、同じ優先順位で共通のキューまたは複数のキューに供給します。
We will explain the difference and describe in what way they differ in operation. The reason this is necessary is that there is current confusion in the industry.
違いを説明し、動作がどのように異なるかを説明します。これが必要な理由は、業界に現在の混乱があるからです。
The multi-priority model is shown in Figure 2. In this model, traffic from each service class is placed into a separate priority queue. If data is present in more than one queue, traffic from one of them will always be selected for transmission. This has the effect of transferring jitter from the higher-priority queue to the lower-priority queues, and reordering traffic in a way that gives the higher-priority traffic a smaller average queuing delay. Each queue must have its own policer, however, to protect the network from errors and attacks; if a traffic class thinks it is carrying a certain data rate but an abuse sends significantly more, the effect of simple prioritization would not preserve the lower priorities of traffic, which could cause routing to fail or otherwise impact a service level agreement (SLA).
多重度モデルを図2に示します。このモデルでは、各サービスクラスからのトラフィックが別の優先キューに配置されます。データが複数のキューに存在する場合、そのうちの1つからのトラフィックは常に送信用に選択されます。これには、ジッターをより優先順位のキューからより低い優先順位のキューに転送し、より優先順位のトラフィックに平均キューイング遅延が低い方法でトラフィックを並べ替える効果があります。ただし、ネットワークをエラーや攻撃から保護するには、各キューに独自のポリサーが必要です。トラフィッククラスが特定のデータレートを運んでいるが、悪用が大幅に送信すると考えている場合、単純な優先順位付けの効果はトラフィックの優先順位を低くしないため、ルーティングが失敗したり、サービスレベル契約に影響を与えたりする可能性があります（SLA）。
.
policers priorities |`.
Admitted EF <=> ----------||----+ `.
high| `.
Unadmitted EF <=> ----------||----+ .'-----------
. medium .'
rate queues |`. +-----+ .' Priority
AF1------>||----+ `. / low |' Scheduler
| `. /
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
Figure 2: Implementation as a Data Plane Priority
図2：データプレーンの優先順位としての実装
The multi-policer model is shown in Figure 3. In this model, traffic from each service class is policed according to its SLA requirements, and then placed into a common priority queue. Unlike the multi-priority model, the jitter experienced by the traffic classes in this case is the same, as there is only one queue, but the sum of the traffic in this higher-priority queue experiences less average jitter than the elastic traffic in the lower-priority.
マルチポールモデルを図3に示します。このモデルでは、各サービスクラスからのトラフィックがSLA要件に従ってポリシングされ、その後、共通の優先キューに配置されます。マルチプリアリティモデルとは異なり、この場合のトラフィッククラスが経験するジッターは同じです。キューは1つしかないためですが、この優先順位のキューのトラフィックの合計は、平均的なジッターの平均ジッターよりも少ない平均ジッターを経験します。より低い。
policers priorities .
Admitted EF <=> -------\ |`.
--||----+ `.
Unadmitted EF <=> -------/ high| `.
. | .'--------
rate queues |`. +-----+ .'
AF1------>||----+ `. / low | .' Priority
| `. / |' Scheduler
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)
Figure 3: Implementation as a Data Plane Policer
図3：データプレーンポリサーとしての実装
The difference between the two operationally is, as stated, the issues of loss due to policing and distribution of jitter.
2つの操作的に違いは、述べたように、ジッターのポリシングと分布による損失の問題です。
If the two traffic classes are, for example, voice and video, datagrams containing video data can be relatively large (often of variable sizes up to the path MTU), while datagrams containing voice are relatively small, on the order of only 40 to 200 bytes, depending on the codec. On lower-speed links (less than 10 MBPS), the jitter introduced by video to voice can be disruptive, while at higher speeds, the jitter is nominal compared to the jitter requirements of voice. Therefore, at access network speeds, [RFC4594] recommends the separation of video and voice into separate queues, while at optical speeds, [RFC5127] recommends that they use a common queue.
たとえば、2つのトラフィッククラスが音声とビデオである場合、ビデオデータを含むデータグラムは比較的大きく（多くの場合、パスMTUまでのさまざまなサイズの）、音声を含むデータグラムは40〜200の順序で比較的小さい場合があります。バイト、コーデックに応じて。低速リンク（10 Mbps未満）では、Video To Voiceによって導入されたジッターは破壊的である可能性がありますが、高速では、ジッターは音声のジッター要件と比較して名目上です。したがって、アクセスネットワーク速度では、[RFC4594]はビデオと音声を個別のキューに分離することを推奨しますが、光学速度では[RFC5127]は共通のキューを使用することを推奨します。
If, on the other hand, the two traffic classes are carrying the same type of application with the same jitter requirements, then giving one preference in this sense does not benefit the higher-priority traffic and may harm the lower-priority traffic. In such a case, using separate policers and a common queue is a superior approach.
一方、2つのトラフィッククラスが同じタイプのアプリケーションを同じジッター要件で運んでいる場合、この意味で1つの優先度を与えることは、より優先順位のトラフィックに利益をもたらさず、より低い形のトラフィックに害を及ぼす可能性があります。そのような場合、個別のポリサーと共通のキューを使用することは優れたアプローチです。
There are at least six major ways that capacity admission is done or has been proposed to be done for real-time applications. Each will be described below, and Section 3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class. These include:
容量入場が行われるか、リアルタイムアプリケーションのために行われることが提案されている少なくとも6つの主要な方法があります。それぞれを以下に説明し、セクション3では、どの程度が認められたテレフォニーサービスクラスの要件を満たす可能性があるかを判断します。これらには以下が含まれます：
o Drop Precedence used to force sessions to voluntarily exit,
o セッションに自発的に終了するように強制するために使用される優先順位を落とす、
o Capacity admission control by assumption or engineering,
o 仮定またはエンジニアリングによる能力入場制御、
o Capacity admission control by call counting,
o コールカウントによる容量入場制御、
o Endpoint capacity admission performed by probing the network,
o ネットワークを調査することで実行されるエンドポイント容量入場、
o Centralized capacity admission control via bandwidth broker, and
o 帯域幅ブローカーを介した集中能力入場制御、および
o Distributed capacity admission control using protocols such as Resource Reservation Protocol (RSVP) or Next Steps in Signaling (NSIS).
o リソース予約プロトコル（RSVP）などのプロトコルまたはシグナリングの次のステップ（NSIS）などのプロトコルを使用した分散容量入場制御。
The problem with dropping traffic to force users to hang up is that it affects a broad class of users -- if there is capacity for N calls and the N+1 calls are active, data is dropped randomly from all sessions to ensure that offered load doesn't exceed capacity. On very fast links, that is acceptable, but on lower speed links it can seriously affect call quality. There is also a behavioral issue involved here, in which users who experience poor quality calls tend to hang up and call again, making the problem better -- then worse.
トラフィックをドロップしてユーザーにハングアップに強制する問題は、幅広いクラスのユーザーに影響を与えることです。Nコールの容量があり、n 1コールがアクティブな場合、データはすべてのセッションからランダムに削除され、提供された負荷がないことを確認します。'tを超える容量を超えます。非常に高速なリンクでは、それは許容されますが、低速リンクではコールの品質に深刻な影響を与える可能性があります。また、ここには行動上の問題が関係しています。そこでは、質の悪いコールを経験したユーザーが電話を切って再び電話をかける傾向があり、問題を改善する傾向があります。
The problem with capacity admission by assumption, which is widely deployed in today's VoIP environment, is that it depends on the assumptions made. One can do careful traffic engineering to ensure needed bandwidth, but this can also be painful, and has to be revisited when the network is changed or network usage changes.
今日のVoIP環境で広く展開されている仮定による容量入場の問題は、それが行われた仮定に依存することです。必要な帯域幅を確保するために慎重なトラフィックエンジニアリングを行うことができますが、これも痛みを伴う可能性があり、ネットワークが変更されたり、ネットワークの使用が変更されたときに再検討する必要があります。
The problem with call-counting-based admission control is that it gets exponentially worse the farther you get from the control point (e.g., it lacks sufficient scalability on the outskirts of the network).
コールカウントベースの入場制御の問題は、コントロールポイントからより遠くになるほど指数関数的に悪化することです（たとえば、ネットワークの郊外では十分なスケーラビリティがありません）。
There are two fundamental problems with depending on the endpoint to perform capacity admission: it may not be able to accurately measure the impact of the traffic it generates on the network, and it tends to be greedy (e.g., it doesn't care). If the network operator is providing a service, he must be able to guarantee the service, which means that he cannot trust systems that are not controlled by his network.
エンドポイントに応じて容量入学を実行することには2つの根本的な問題があります。ネットワーク上のトラフィックの影響を正確に測定できない場合があり、貪欲である傾向があります（たとえば、気にしません）。ネットワークオペレーターがサービスを提供している場合、彼はサービスを保証できる必要があります。つまり、彼は自分のネットワークによって制御されていないシステムを信頼できないことを意味します。
The problem with capacity controls via a bandwidth broker is that centralized servers lack far away awareness, and also lack effective real-time reaction to dynamic changes in all parts of the network at all instances of time.
帯域幅ブローカーを介した容量制御の問題は、集中サーバーが遠くの認識を欠いており、すべての場合にネットワークのすべての部分で動的な変化に対する効果的なリアルタイムの反応がないことです。
The problem with mechanisms that do not enable the association of a policy with the request is that they do not allow for multi-policy services, which are becoming important.
ポリシーとリクエストとの関連性を有効にしないメカニズムの問題は、それらが重要になっているマルチポリシーサービスを許可していないことです。
The operator's choice of admission procedure MUST, for this DSCP, ensure the following:
オペレーターの入場手順の選択は、このDSCPでは、次のことを確認する必要があります。
o The actual links that a session uses have enough bandwidth to support it.
o セッションが使用する実際のリンクには、サポートするのに十分な帯域幅があります。
o New sessions are refused admission if there is inadequate bandwidth under the relevant policy.
o 関連するポリシーの下で帯域幅が不十分な場合、新しいセッションは入場を拒否されます。
o A user is identified and the correct policy is applied if multiple policies are in use in a network.
o ユーザーが特定され、ネットワークで複数のポリシーが使用されている場合、正しいポリシーが適用されます。
o Under periods of network stress, the process of admission of new sessions does not disrupt existing sessions, unless the service explicitly allows for disruption of calls.
o ネットワークストレスの期間では、新しいセッションの入場プロセスは、サービスが明示的に通話の混乱を許可しない限り、既存のセッションを混乱させません。
When coupled with adequate Authentication, Authorization, and Accounting (AAA) and capacity admission procedures as described in Section 2.2, either of the two PHB implementations described in Section 2.1 is sufficient to provide the services required for an Admitted Telephony service class. If preemption is required, Section 2.3.5.2 of [RFC4542] provides the tools for carrying out the preemption. If preemption is not in view, or if used in addition to preemptive services, the application of different thresholds depending on call precedence has the effect of improving the probability of call completion by admitting preferred calls at a time when other calls are being refused. Routine and priority traffic can be admitted using the same DSCP value, as the choice of which calls are admitted is handled in the admission procedure executed in the control plane, not the policing of the data plane.
セクション2.2で説明されているように、適切な認証、承認、および会計（AAA）および容量入学手順と組み合わせた場合、セクション2.1で説明されている2つのPHB実装のいずれかが、認められたテレフォニーサービスクラスに必要なサービスを提供するのに十分です。先制が必要な場合、[RFC4542]のセクション2.3.5.2は、先制を実行するためのツールを提供します。先制が視界にない場合、または先制サービスに加えて使用されている場合、コールの優先順位に応じて異なるしきい値を適用すると、他の呼び出しが拒否された時点で優先通話を認めることにより、コール完了の確率を改善する効果があります。通常のDSCP値を使用して、定期的および優先的なトラフィックは、データプレーンのポリシングではなく、コントロールプレーンで実行された入場手順で処理されるため、同じDSCP値を使用して入院できます。
On the point of what protocols and procedures are required for authentication, authorization, and capacity admission, we note that clear standards do not exist at this time for bandwidth brokers, NSIS has not been finalized at this time and in any event is limited to unicast sessions, and that RSVP has been standardized and has the relevant services. We therefore RECOMMEND the use of a protocol, such as RSVP, at the UNI. Procedures at the NNI are business matters to be discussed between the relevant networks, and are RECOMMENDED but NOT REQUIRED.
認証、承認、および容量の入場にプロトコルと手順が必要なポイントでは、現時点では明確な標準が存在しないことに注意してください。NSIは現時点では最終決定されておらず、いずれの場合でもユニキャストに限定されています。セッション、およびそのRSVPは標準化されており、関連するサービスがあります。したがって、UNIでRSVPなどのプロトコルを使用することをお勧めします。NNIでの手順は、関連するネットワーク間で議論されるビジネス上の問題であり、推奨されますが、必須ではありません。
To summarize, there are two changes to [RFC4594] discussed in this document:
要約すると、このドキュメントで説明した[RFC4594]には2つの変更があります。
Telephony class: The Telephony Service Class in RFC 4594 does not involve capacity admission, but depends on application layer admission that only estimates capacity, and does that through static engineering. In addition to that class, a separate Admitted Telephony Class is added that performs capacity admission dynamically.
テレフォニークラス：RFC 4594のテレフォニーサービスクラスは、容量入場を伴うものではなく、容量のみを推定するアプリケーション層の入場に依存し、静的エンジニアリングを通じてそれを行います。そのクラスに加えて、容量入学を動的に実行する別の認められたテレフォニークラスが追加されます。
Video classes: Capacity admission is added to three video classes. These are the Interactive Real-Time Traffic class, Broadcast TV class when used for video on demand, and the Multimedia Conferencing class.
ビデオクラス：3つのビデオクラスに容量入場が追加されます。これらは、インタラクティブなリアルタイムトラフィッククラス、ビデオオンデマンドで使用される場合の放送TVクラス、およびマルチメディア会議クラスです。
IANA assigned a DSCP value to a second EF traffic class consistent with [RFC3246] and [RFC3247] in the "Differentiated Services Field Codepoints" registry. It implements the Telephony Service Class described in [RFC4594] at lower speeds and is included in the Real-Time Treatment Aggregate [RFC5127] at higher speeds. The code point value should be from pool 1 within the dscp-registry. The value is parallel with the existing EF code point (101110), as IANA assigned the code point 101100 -- keeping the (left-to-right) first 4 binary values the same in both. The code point described in this document is referred to as VOICE-ADMIT and has been registered as follows:
IANAは、[RFC3246]および[RFC3247]と一致する2番目のEFトラフィッククラスに、「Distementiated Services Field CodePoints」レジストリにDSCP値を割り当てました。[RFC4594]に記載されているテレフォニーサービスクラスを低速で実装し、高速でリアルタイム治療の集約[RFC5127]に含まれています。コードポイント値は、DSCP-Registry内のプール1からのものでなければなりません。IANAがコードポイント101100を割り当てたため、値は既存のEFコードポイント（101110）と並行しています。このドキュメントで説明されているコードポイントは、音声アドミットと呼ばれ、次のように登録されています。
Sub-registry: Pool 1 Codepoints Reference: [RFC2474] Registration Procedures: Standards Action
サブレジストリ：プール1コードポイントリファレンス：[RFC2474]登録手順：標準アクション
Registry:
Name Space Reference
--------- ------- ---------
VOICE-ADMIT 101100 [RFC5865]
This traffic class REQUIRES the use of capacity admission, such as RSVP services together with AAA services, at the User/Network Interface (UNI); the use of such services at the NNI is at the option of the interconnected networks.
このトラフィッククラスでは、RSVPサービスとAAAサービスなど、ユーザー/ネットワークインターフェイス（UNI）で容量入場を使用する必要があります。NNIでのそのようなサービスの使用は、相互接続されたネットワークのオプションにあります。
A major requirement of this service is effective use of a signaling protocol, such as RSVP, with the capabilities to identify its user as either an individual or a member of some corporate entity, and assert a policy such as "normal", "routine", or some level of "priority".
このサービスの主要な要件は、RSVPなどのシグナルプロトコルの効果的な使用であり、ユーザーを個人または一部の企業エンティティのメンバーとして識別し、「通常」、「ルーチン」などのポリシーを主張する機能を備えています。、またはある程度の「優先度」。
This capability, one has to believe, will be abused by script kiddies and others if the proof of identity is not adequately strong or if policies are written or implemented improperly by the carriers. This goes without saying, but this section is here for it to be said.
この能力は、アイデンティティの証明が適切に強力でない場合、またはキャリアによってポリシーが不適切に書かれたり実装されたりした場合、スクリプトの子供や他の人々によって乱用されると信じなければなりません。言うまでもなく、このセクションは言われるべきです。
Many of the security considerations from RFC 3246 [RFC3246] apply to this document, as well as the security considerations in RFC 2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some gap analysis to the NSIS WG as they started their work. Keep in mind that this document is advocating RSVP at the UNI only, while RFC 4230 discusses (mostly) RSVP from a more complete point of view (i.e., e2e and edge2edge). When considering the RSVP aspect of this document, understanding Section 6 of RFC 4230 is a good source of information.
RFC 3246 [RFC3246]からのセキュリティ上の考慮事項の多くは、このドキュメントに適用され、RFC 2474およびRFC 4542のセキュリティ上の考慮事項が適用されます。RFC4230[RFC4230]はRSVPを分析し、NSIS WGにいくつかのギャップ分析を提供し、仕事を始めたときにギャップ分析を提供します。。このドキュメントはUNIのみでRSVPを提唱していることに留意してください。RFC4230は、より完全な観点（つまり、E2EおよびEDGE2EDGE）から（ほとんど）RSVPを議論しています。このドキュメントのRSVPの側面を検討する場合、RFC 4230のセクション6を理解することは、良い情報源です。
Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe commented and offered text. The impetus for including video in the discussion, which initially only targeted voice, is from Dave McDysan.
Kwok Ho Chan、Georgios Karagiannis、Dan Voce、およびBob Briscoeがコメントし、テキストを提供しました。ディスカッションにビデオを含めるための推進力は、最初はターゲットを絞った声のみがデイブマクディーサンからのものです。
[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月。
[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月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、Bennet、J.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[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、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[RFC3247] Charny、A.、Bennet、J.、Benson、K.、Boudec、J.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C。、およびKRamakrishnan、「EF PHBの新しい定義の補足情報（HOPごとの動作ごとに迅速化された転送）」、RFC 3247、2002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190] Carlberg、K.、Brown、I。、およびC. Beard、「IPテレフォニーでの緊急通信サービス（ETS）をサポートするためのフレームワーク」、RFC 4190、2005年11月。
[RFC4504] Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[RFC4504] Sinnreich、H.、ed。、Lass、S。、およびC. Stredicke、「SIP Telephony Device Recomations and Configuration」、RFC 4504、2006年5月。
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4542] Baker、F。およびJ. Polk、「インターネットプロトコルスイートでのリアルタイムサービス用の緊急通信サービス（ETS）の実施」、RFC 4542、2006年5月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、2006年8月。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008.
[RFC5127] Chan、K.、Babiarz、J。、およびF. Baker、「Diffserv Service Classeの集約」、RFC 5127、2008年2月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230] Tschofenig、H。およびR. Graveman、「RSVPセキュリティプロパティ」、RFC 4230、2005年12月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
Phone: +1-408-526-4257
EMail: fred@cisco.com
James Polk Cisco Systems Richardson, Texas 75082 USA
ジェームズポークシスコシステムリチャードソン、テキサス75082 USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA
マーティンドリーAT＆Tラボミドルタウンタウンシップ、ニュージャージー07748 USA
Phone: +1-732-420-4574
EMail: mdolly@att.com