Network Working Group K. Nichols
Request for Comments: 3086 Packet Design
Category: Informational B. Carpenter
IBM
April 2001
Definition of Differentiated Services Per Domain Behaviors
and Rules for their Specification
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes.
差別化サービスフレームワークは、トラフィック凝集体を作成するために、縁部にルールを適用し、IPヘッダ内のコードポイントを使用することによって、ドメイン内の特定の転送パスの処理でこれらの各々を結合することによって、ネットワークドメイン内のサービス品質プロビジョニングを可能にします。 DiffServのWGは、差別化サービスのための一般的なアーキテクチャを定義していると「ホップごとの転送動作」（またはのPHB）として知られているルータに必要な転送パスの動作、に焦点を当ててきました。 WGはまた規則に従ってDiffServのに必要な機能（DS）ドメイン（分類）を選択するエッジと条件（例えば、ポリシング及びシェーピング）トラフィックを論じています。 DSドメインのQoS目標で短期の変化は、必ずしも内部ネットワークノードの動作を再設定することなく、これらのエッジの行動の構成のみを変更することで実現されています。
The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and
次のステップは、転送パス成分（のPHB、分類、およびトラフィックコンディショナー）がトラフィックを構成するために使用することができる方法の例を定式化することで、そのパケット彼らトランジット差別化サービスドメインと特定の転送特性を経験集約。 WGは、彼らがDSドメインを越えてパケットの特定のセットが経験した振る舞いを記述するために、用語ごとのドメイン行動、またはPDBを使用することを決定しました。 PDBは、特定のDSCP（またはのDSCPのセット）で処理するパケットのセットを定量化する特定のメトリックによって特徴付けられ、それはDSドメインを横切るように受信します。 PDBは、トラフィック集約のための転送パス処理を指定すると、エッジの特定の選択肢その役割に起因すると
PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge.
その結果、属性におけるPHBの設定演劇、それは転送パスとコントロールプレーンが相互作用するところです。 PDBの測定可能なパラメータは、ネットワークエッジでのサービスレベルの仕様での使用に適したものでなければなりません。
This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions.
この文書では、定義と説明しドメイン単位の行動を詳細にし、フォーマットとのPDBとWG製品として進めるために、個々のPDB仕様に適用される手続き上のDiffserv WGへの貢献のために必要なコンテンツをレイアウトします。この形式は、PDB提出のワーキンググループの審査を迅速化するために指定されています。
Table of Contents
目次
1. Introduction ................................................ 2
2. Definitions ................................................. 4
3. The Value of Defining Edge-to-Edge Behavior ................. 5
4. Understanding PDBs .......................................... 7
5. Format for Specification of Diffserv Per-Domain Behaviors ...13
6. On PDB Attributes ...........................................16
7. A Reference Per-Domain Behavior .............................19
8. Guidelines for Advancing PDB Specifications .................21
9. Security Considerations .....................................22
10. Acknowledgements ............................................22
References ..................................................22
Authors' Addresses ..........................................23
Full Copyright Statement ....................................24
1 Introduction
1はじめに
Differentiated Services allows an approach to IP Quality of Service that is modular, incrementally deployable, and scalable while introducing minimal per-node complexity [RFC2475]. From the end user's point of view, QoS should be supported end-to-end between any pair of hosts. However, this goal is not immediately attainable. It will require interdomain QoS support, and many untaken steps remain on the road to achieving this. One essential step, the evolution of the business models for interdomain QoS, will necessarily develop outside of the IETF. A goal of the diffserv WG is to provide the firm technical foundation that allows these business models to develop. The first major step will be to support edge-to-edge or intradomain QoS between the ingress and egress of a single network, i.e., a DS Domain in the terminology of RFC 2474. The intention is that this edge-to-edge QoS should be composable, in a purely technical sense, to a quantifiable QoS across a DS Region composed of multiple DS domains.
差別化サービスは、最小単位のノード複雑[RFC2475]を導入しながら、モジュラー増分展開、およびスケーラブルであるIPサービス品質へのアプローチを可能にします。ビューのエンドユーザの視点からは、QoSは、エンドツーエンドホストの任意のペアの間をサポートする必要があります。しかし、この目標はすぐに達成可能ではありません。これは、ドメイン間のQoSサポートを必要とし、多くのuntakenの手順は、これを達成するために道路上に残ります。一つの基本的なステップ、ドメイン間のQoSのためのビジネスモデルの進化は、必ずしもIETFの外を開発します。 diffserv WGの目標は、これらのビジネスモデルを開発することができます確固たる技術的基盤を提供することです。最初の重要なステップは、意図は、このエッジ・ツー・エッジのQoSがすべきことであるRFC 2474の用語で、つまり、単一ネットワークの入口と出口の間でDSドメインをエッジ・エッジまたはドメイン内のQoSをサポートすることになります複数のDSドメインで構成DS地域全体の定量化可能なQoSに、純粋に技術的な意味では、構成可能なこと。
The Diffserv WG has finished the first phase of standardizing the behaviors required in the forwarding path of all network nodes, the per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474, 2597 and 2598 give a rich toolbox for differential packet handling by individual boxes. The general architectural model for diffserv has been documented in RFC 2475. An informal router model [MODEL] describes a model of traffic conditioning and other forwarding behaviors. However, technical issues remain in moving "beyond the box" to intradomain QoS models.
DiffservのWGは、ホップごとの転送動作またはのPHBをすべてのネットワークノードの転送パスで必要な振る舞いを標準化の第一段階を終了しました。 RFC 2474、2597および2598で定義されたのPHBは、個々の箱で差動パケット処理のための豊富なツールボックスを与えます。 DiffServのための一般的なアーキテクチャモデルは、非公式のルータモデル[MODEL]はトラフィック調整や他の転送動作のモデルについて説明RFC 2475.に記載されています。しかし、技術的な問題は、QoSモデルをドメイン内する「ボックスを超えて」移動中に残っています。
The ultimate goal of creating scalable end-to-end QoS in the Internet requires that we can identify and quantify behavior for a group of packets that is preserved when they are aggregated with other packets as they traverse the Internet. The step of specifying forwarding path attributes on a per-domain basis for a set of packets distinguished only by the mark in the DS field of individual packets is critical in the evolution of Diffserv QoS and should provide the technical input that will aid in the construction of business models. This document defines and specifies the term "Per-Domain Behavior" or PDB to describe QoS attributes across a DS domain.
インターネットでスケーラブルなエンドツーエンドのQoSを作成するための究極の目標は、我々は、彼らがインターネットを横断する彼らは他のパケットと集約されたときに保存されたパケットのグループのための行動を識別し、定量化することができることが必要です。転送パスを指定するステップは、個々のパケットのDSフィールド内のマークによってのみ区別されるパケットのセットのためのドメインごとに属性をすることのDiffservのQoSの進化に重要であると建設に役立つ技術的な入力を提供しなければなりませんビジネスモデルの。この文書では、QoSがDSドメイン間での属性記述するために用語「ドメイン単位の動作」またはPDBを定義して指定します。
Diffserv classification and traffic conditioning are applied to packets arriving at the boundary of a DS domain to impose restrictions on the composition of the resultant traffic aggregates, as distinguished by the DSCP marking , inside the domain. The classifiers and traffic conditioners are set to reflect the policy and traffic goals for that domain and may be specified in a TCA (Traffic Conditioning Agreement). Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to group packets solely according to the behavior they receive at each hop (as selected by the DSCP). This approach has well-known scaling advantages, both in the forwarding path and in the control plane. Less well recognized is that these scaling properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets. Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold regardless of how the temporal characteristics of the marked traffic aggregate change as it traverses the domain, then that PDB scales. (Clearly this assumes that numerical parameters such as bandwidth allocated to the particular PDB may be different at different points in the network, and may be adjusted dynamically as traffic volume varies.) If there are limits to where the properties hold, that translates to a limit on the size or topology of a DS domain that can use that PDB. Although useful single-link DS domains might exist, PDBs that are invariant with network size or that have simple relationships with network size and whose properties can be recovered by reapplying rules (that is, forming another diffserv boundary or edge to re-enforce the rules for the traffic aggregate) are needed for building scalable end-to-end quality of service.
ドメイン内で、DSCPマーキングによって区別されるようDiffservの分類とトラフィック調整は、結果として生じるトラフィック凝集体の組成に制限を課すためにDSドメインの境界に到着するパケットに適用されます。クラシファイアと交通コンディショナーは、そのドメインのポリシーとトラフィックの目標を反映するように設定されており、TCA（交通コンディショニング協定）で指定することができます。パケットがDSの境界を越えたら、DiffServの原則の順守は、単に（DSCPによって選択されるように）それらが各ホップで受信動作に従ってグループパケットすることができます。このアプローチは、転送パスおよび制御プレーンの両方において、よく知られたスケーリングの利点を有します。あまりよく知らホップ単位の動作の定義は、集計の下で不変の特定のタイプを生じさせる場合には、これらのスケーリングの特性は結果だけということです。そのPHBのためにマークされたパケットのセットは、すべてのノードで異なるかもしれないがホップ単位動作は、ドメイン内のすべてのノードに対して同等でなければならないので、のPHBは、その特性は、関連のトラフィック量に依存しないように定義されなければなりませんルータの入口リンク上でもパケットで撮影したDSドメインを介し、特定のパス上のBA。具体的には、同じトラフィック集合マージおよび分割に属するトラフィックの異なるストリームは、それらがネットワークを横断するように。特定のPHBを使用してPDBの性質にかかわらず、それがそのPDBスケール、その後、ドメインをマークされたトラフィックの集約変化の時間特性を横断するときにどのように保持している場合。 Aに変換特性が保持場所に制限がある場合（これは明らかに特定のPDBに割り当てられた帯域幅などの数値パラメータは、ネットワーク内の異なる点で異なっていてもよく、交通量が変化するように動的に調整することができること。想定しています）そのPDBを使用することができDSドメインのサイズやトポロジーの制限。有用なシングルリンクDSドメインが存在するかもしれないが、ネットワークのサイズ又はそれに不変であるのPDBは、ネットワークサイズ及び特性ルールを再適用することによって回収することができるとの単純な関係を有する（すなわち、再施行規則別のDiffServ境界またはエッジを形成する、ですトラフィック集約のための）サービスのスケーラブルなエンドツーエンドの品質を構築するために必要とされています。
There is a clear distinction between the definition of a Per-Domain Behavior in a DS domain and a service that might be specified in a Service Level Agreement. The PDB definition is a technical building block that permits the coupling of classifiers, traffic conditioners, specific PHBs, and particular configurations with a resulting set of specific observable attributes which may be characterized in a variety of ways. These definitions are intended to be useful tools in configuring DS domains, but the PDB (or PDBs) used by a provider is not expected to be visible to customers any more than the specific PHBs employed in the provider's network would be. Network providers are expected to select their own measures to make customer-visible in contracts and these may be stated quite differently from the technical attributes specified in a PDB definition, though the configuration of a PDB might be taken from a Service Level Specification (SLS). Similarly, specific PDBs are intended as tools for ISPs to construct differentiated services offerings; each may choose different sets of tools, or even develop their own, in order to achieve particular externally observable metrics. Nevertheless, the measurable parameters of a PDB are expected to be among the parameters cited directly or indirectly in the Service Level Specification component of a corresponding SLA.
DSドメイン内のドメイン単位の行動の定義やサービスレベル契約で指定される可能性がありますサービスとの間の明確な区別があります。 PDB定義は、様々な方法で特徴付けることができる特定の観察可能な属性の結果セットで分類、交通コンディショナー、特定のPHB、及び特定の構成の結合を可能にする技術的なビルディング・ブロックです。これらの定義は、DSドメインを構成する上で有用なツールであることを意図したものではなく、PDB（またはのPDB）プロバイダによって使用されているプロバイダのネットワークで使用される具体的なのPHBは場合よりも、顧客に見える、それ以上であることが予想されていません。ネットワークプロバイダは、契約における顧客見えるようにするために、独自の対策を選択することが予想され、PDBの構成はサービス・レベル仕様（SLS）から取られるかもしれませんが、これらは、全く異なるPDB定義で指定された技術属性から記述することができます。 。同様に、特定のPDBは、差別化サービスの提供を構築するISPのためのツールとして意図されています。各ツールの異なるセットを選択する、あるいは特定の外部から観察可能な指標を達成するために、自分自身を開発することがあります。それにもかかわらず、PDBの測定可能なパラメータは、対応するSLAのサービス・レベル仕様成分に直接的または間接的に引用されたパラメータの中であると期待されます。
This document defines Differentiated Services Per-Domain Behaviors and specifies the format that must be used for submissions of particular PDBs to the Diffserv WG.
この文書では、ドメインごとの行動差別化サービスを定義し、DiffservのWGへの特定のPDBの提出のために使用されなければならない形式を指定します。
2 Definitions
2つの定義
The following definitions are stated in RFCs 2474 and 2475 and are repeated here for easy reference:
以下の定義は、RFCの2474年と2475年に記載されており、簡単に参照のためにここで繰り返されています。
" Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction.
「行動集計：特定の方向にあるリンクを横切る同じコードポイントのパケットの集まり。
" Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain.
「差別化サービスドメインは：差別化サービス政策の一貫性を協調様式で投与され、その上、インターネットの連続部分は、差別化サービスのドメインは、例えば、異なる管理ドメインまたは自律システム、異なる信頼領域、異なるネットワーク技術を（表すことができますセル/フレーム）、ホストとルータなどもDSドメイン。
" Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary.
「差別化サービス境界：分類とトラフィックコンディショナが展開される可能性があるDSドメインのエッジは、差別化サービス境界は、さらに細分入口及び出口ノードに、入口/出口ノードは、上流/下流にあることができます所与のトラフィックの方向における境界リンクのノード。差別化サービス境界は、典型的には、ホストのパケットが横断する、または直前に入っての出口でいることを第一ホップ差別化サービス対応ルータ（またはネットワークノード）への入口で見出されますホストに到達する前に通過するパケット差別化サービス対応ルータまたはネットワークノードをホップ。これは時々葉ルータにおける境界と呼ばれている。差別化サービス境界は、ローカルポリシーの対象ホストと同じ場所に配置されてもよい。またDS境界。
To these we add:
これらに、私たちは追加します。
" Traffic Aggregate: a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network.
fooのトラフィック集約：「トラフィック集計。通常、DSドメインやDSドメインのサブセットでは、同じPHBにマップコードポイントを持つパケットの収集のfoo PHBのためにマークされたトラフィックの集約は、と呼ばれています 『』か「FOOの集約」は、交換可能。これにより、ネットワークへのリンクから行動集計の概念を一般化します。
" Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.
「ごとのドメイン動作は：パケットの識別可能な又はターゲットグループから受ける期待治療 『エッジ・ツー・エッジ』 DSドメインの（またPDB。）特定のPHB（又は、該当する場合、のPHBのリスト）。そして、トラフィック調整要件は、各PDBに関連しています。
" A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain. It is expected to include specific values or bounds for PDB parameters.
「サービス・レベル仕様（SLS）は、一緒にDSドメインによってトラフィックストリームに提供されるサービスを定義するパラメータとその値のセットがある。PDBのパラメータの特定の値または範囲を含めることが予想されます。
3 The Value of Defining Edge-to-Edge Behavior
定義エッジ間行動の3値
As defined in section 2, a PDB describes the edge-to-edge behavior across a DS domain's "cloud." Specification of the transit expectations of packets matching a target for a particular diffserv behavior across a DS domain will both assist in the deployment of single-domain QoS and will help enable the composition of end-to-end, cross-domain services. Networks of DS domains can be connected to create end-to-end services by building on the PDB characteristics without regard to the particular PHBs used. This level of abstraction makes it easier to compose cross-domain services as well as making it possible to hide details of a network's internals while exposing information sufficient to enable QoS.
セクション2で定義されているように、PDBはDSドメインの間で端から端までの動作を説明する「クラウド」。 DSのドメイン全体、特定のDiffServの行動のためのターゲットに一致するパケットのトランジット期待の仕様は、両方の単一ドメインのQoSの導入を支援し、エンド・ツー・エンド、クロスドメインサービスの構成を可能にするのに役立ちます。 DSドメインのネットワークは、使用される特定のPHBに関係なく、PDB特性に構築することにより、エンド・ツー・エンドのサービスを作成するために接続することができます。このレベルの抽象化は、それが簡単にクロスドメインサービスを構成することができますだけでなく、QoSをイネーブルにするのに十分な情報を露出させ、ネットワークの内部の詳細を非表示にすることが可能となります。
Today's Internet is composed of multiple independently administered domains or Autonomous Systems (ASs), represented by the "clouds" in figure 1. To deploy ubiquitous end-to-end quality of service in the Internet, business models must evolve that include issues of charging and reporting that are not in scope for the IETF. In the meantime, there are many possible uses of quality of service within an AS and the IETF can address the technical issues in creating an intradomain QoS within a Differentiated Services framework. In fact, this approach is quite amenable to incremental deployment strategies.
今日のインターネットは、インターネットでのサービスのユビキタスエンドツーエンドの品質を展開するには、図1で「雲」に代表される複数の独立して管理ドメインまたは自律システム（ASの）、で構成され、ビジネスモデルは、充電の問題が含まれている進化しなければなりませんそしてIETFのスコープではありません報告。一方、ASおよびIETF内のサービスの質の多くの可能な用途は、差別化サービスフレームワーク内で、ドメイン内のQoSを作成する際に技術的な問題に対処することができますがあります。実際には、このアプローチは、増分展開戦略に非常に適しています。
Where DS domains are independently administered, the evolution of the necessary business agreements and future signaling arrangements will take some time, thus, early deployments will be within a single administrative domain. Putting aside the business issues, the same technical issues that arise in interconnecting DS domains with homogeneous administration will arise in interconnecting the autonomous systems (ASs) of the Internet.
DSドメインが独立して管理されている場合は、必要に応じて業務契約および将来のシグナリング配置の進化は、しばらく時間がかかりますので、早い展開では、単一の管理ドメイン内にあるであろう。ビジネス上の問題を脇に置く、均質な投与とDSドメインを相互接続で発生する同じ技術的な問題は、インターネットの自律システム（ASの）を相互接続するに発生します。
----------------------------------------
| AS2 |
| |
------- | ------------ ------------ |
| AS1 |------|-----X | | | |
------- | | | Y | | -------
| | | /| X----|--------| AS3 |
| | | / | | | -------
| | | / ------------ |
| | Y | |
| | | \ ------------ |
------- | | | \ | | |
| AS4 |------|-----X | \| | |
------- | | | Y X----|------
| | | | | |
| ------------ ------------ |
| |
| |
----------------------------------------
Figure 1: Interconnection of ASs and DS Domains
図1：お尻とDSドメインの相互接続
A single AS (e.g., AS2 in figure 1) may be composed of subnetworks and, as the definition allows, these can be separate DS domains. An AS might have multiple DS domains for a number of reasons, most notable being to follow topological and/or technological boundaries and to separate the allocation of resources. If we confine ourselves to the DS boundaries between these "interior" DS domains, we avoid the non-technical problems of setting up a service and can address the issues of creating characterizable PDBs.
単一のASは、（例えば、図1のAS2）の定義が可能となるように、これらは別個のDSドメインであることができ、サブネットワークから構成されてもよいです。 ASは、トポロジカルおよび/または技術的な境界を追跡して、リソースの割り当てを分離するために、最も注目すべきであること、多くの理由から、複数のDSドメインを持っているかもしれません。私たちはこれらの「内部」DSドメイン間のDS境界に自分自身を閉じ込める場合、我々はサービスを設定するの非技術的な問題を回避し、特徴づけるのPDBを作成する問題に対処することができます。
The incentive structure for differentiated services is based on upstream domains ensuring their traffic conforms to the Traffic Conditioning Agreements (TCAs) with downstream domains and downstream domains enforcing that TCA, thus metrics associated with PDBs can be sensibly computed. The letters "X" and "Y" in figure 1 represent the DS boundary routers containing traffic conditioners that ensure and enforce conformance (e.g., shapers and policers). Although policers and shapers are expected at the DS boundaries of ASs (the "X" boxes), they might appear anywhere, or nowhere, inside the AS. Specifically, the boxes at the DS boundaries internal to the AS (the "Y" boxes) may or may not condition traffic. Technical guidelines for the placement and configuration of DS boundaries should derive from the attributes of a particular PDB under aggregation and multiple hops.
差別化サービスのためのインセンティブ構造は、そのトラフィックがそのTCAを強制下流ドメイン及び下流のドメインとトラフィックコンディショニング契約（TCAは）に準拠して確保上流のドメインに基づいている、のPDBに関連付けられ、したがってメトリックは賢明計算することができます。図1における文字「X」と「Y」が確実と適合性（例えば、シェーパおよびポリサー）を強制トラフィックコンディショナーを含むDS境界ルータを表します。ポリサーとシェイパーがのAS（「X」ボックス）のDS境界で期待されているが、それらはどこか、またはどこにも、AS内部に表示される場合があります。具体的には、AS（「Y」のボックス）の内部DS境界でボックスは、またはトラフィックを調整しない場合があります。 DS境界の配置や構成のための技術的なガイドラインが集約し、複数のホップの下で特定のPDBの属性から派生する必要があります。
This definition of PDB continues the separation of forwarding path and control plane described in RFC 2474. The forwarding path characteristics are addressed by considering how the behavior at every hop of a packet's path is affected by the merging and branching of traffic aggregates through multiple hops. Per-hop behaviors in nodes are configured infrequently, representing a change in network infrastructure. More frequent quality-of-service changes come from employing control plane functions in the configuration of the DS boundaries. A PDB provides a link between the DS domain level at which control is exercised to form traffic aggregates with quality-of-service goals across the domain and the per-hop and per-link treatments packets receive that results in meeting the quality-of-service goals.
PDBのこの定義は、RFC 2474路特性がパケットのパスのすべてのホップでの挙動をマージすることによって影響を受けたトラフィックの分岐が複数のホップを介して集約された方法を検討することによって対処される転送に記載の転送経路と制御プレーンの分離を継続します。ノード内のホップごとの挙動は、ネットワークインフラの変化を示す、まれに構成されています。より頻繁なサービス品質の変化は、DSの境界の構成に制御プレーン機能を用いから来ます。 PDBは、ドメイン全体のサービス品質目標にトラフィックを形成するために行使された制御れるDSドメインレベルとの間のリンクを集約し提供し、ホップごと、リンクの治療のパケットが受信その品質・オブ・ミーティングでの結果サービス目標。
4 Understanding PDBs
4のPDBを理解します
RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate as "a collection of packets with the same DS codepoint crossing a link in a particular direction" and further state that packets with the same DSCP get the same per-hop forwarding treatment (or PHB) everywhere inside a single DS domain. Note that even if multiple DSCPs map to the same PHB, this must hold for each DSCP individually. In section 2 of this document, we introduced a more general definition of a traffic aggregate in the diffserv sense so that we might easily refer to the packets which are mapped to the same PHB everywhere within a DS domain. Section 2 also presented a short definition of PDBs which we expand upon in this section:
RFC 2474と同じDSCPを持つパケットは、同じホップごとの転送処理（またはPHB）を取得することと、さらに状態「同じDSは、特定の方向にリンクを横切るコードポイントとパケットのコレクション」として差別化サービス動作の集合を定義する2475年どこでも、単一のDSドメインの内部。複数のDSCPが同じPHBにマッピングしても、これは個別に各DSCPのために保持しなければならないことに注意してください。我々は簡単にDSドメイン内のどこでも同じPHBにマッピングされたパケットを参照してください可能性があるように、このドキュメントのセクション2では、我々は、DiffServの意味でのトラフィック集約のより一般的な定義を導入しました。第2節はまた、我々は、このセクションの上に広げるのPDBの短い定義を提示しました：
Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge to edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.
ドメイン単位の行動：パケットの特定可能またはターゲットグループがDSドメインの「エッジにエッジ」から受け取ることになります期待される治療法。特定のPHB（又は、該当する場合、のPHBのリスト）と交通調節要件は、各PDBに関連付けられています。
Each PDB has measurable, quantifiable, attributes that can be used to describe what happens to its packets as they enter and cross the DS domain. These derive from the characteristics of the traffic aggregate that results from application of classification and traffic conditioning during the entry of packets into the DS domain and the forwarding treatment (PHB) the packets get inside the domain, but can also depend on the entering traffic loads and the domain's topology. PDB attributes may be absolute or statistical and they may be parameterized by network properties. For example, a loss attribute might be expressed as "no more than 0.1% of packets will be dropped when measured over any time period larger than T", a delay attribute might be expressed as "50% of delivered packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms." A wide range of metrics is possible. In general they will be expressed as bounds or percentiles rather than as absolute values.
各PDBは、彼らが入ると、DSドメインを越えてそのパケットに何が起こるかを記述するために使用することができ、測定、定量化、属性を持っています。これらのパケットは、ドメインの中に入るDSドメインへのパケットの入口と転送処理（PHB）中分類とトラフィックコンディショニングのアプリケーションから生じるトラフィック集合体の特性に由来するだけでなく、進入トラフィック負荷に依存することができますドメインのトポロジ。 PDBの属性は、絶対的または統計することができ、彼らはネットワークプロパティによってパラメータ化することができます。例えば、損失属性は、遅延属性は、渡されたパケットの50％がより少なく表示されます」のように表現されるかもしれない「Tよりも大きい任意の期間にわたって測定した場合のパケットの0.1％が削除されます超えない」と表現されるかもしれませんDミリ秒の遅延は、30％が2Dミリ秒未満の遅延は、20％が3Dミリ秒未満の遅延が表示されます表示されます。」メトリックの広い範囲が可能です。一般に、それらは境界またはパーセンタイルではなく絶対値として表現されます。
A PDB is applied to a target group of packets arriving at the edge of the DS domain. The target group is distinguished from all arriving packets by use of packet classifiers [RFC2475] (where the classifier may be "null"). The action of the PDB on the target group has two parts. The first part is the the use of traffic conditioning to create a traffic aggregate. During traffic conditioning, conformant packets are marked with a DSCP for the PHB associated with the PDB (see figure 2). The second part is the treatment experienced by packets from the same traffic aggregate transiting the interior of a DS domain, between and inside of DS domain boundaries. The following subsections further discuss these two effects on the target group that arrives at the DS domain boundary.
PDBはDSドメインのエッジに到着するパケットのターゲットグループに適用されます。ターゲットグループは、（分類器が「NULL」であってもよい）、パケット分類[RFC2475]を使用することによって、すべての到着パケットから区別されます。ターゲットグループのPDBのアクションは2つの部分があります。最初の部分は、トラフィックの集約を作成するために、トラフィック調整を使用することです。トラフィック調整時には、準拠パケットはPDBに関連したPHBのためのDSCPでマークされます（図2を参照）。第二部は、間とDSドメイン境界の内側に、DSドメインの内部を通過する同じトラフィック集計からのパケットが経験する治療法です。以下のサブセクションでは、さらにDSドメインの境界に到達したターゲットグループにこれら二つの効果を議論します。
----------- ------------ -------------------- foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets | | |of packets | |& marking (for foo) | aggregate
----------- ------------ --------------------
Figure 2: Relationship of the traffic aggregate associated
with a PDB to arriving packets
4.1.1 Crossing the DS edge: the effects of traffic conditioning on the target group
ターゲットグループのトラフィック調整の効果：DSのエッジを横断4.1.1
This effect is quantified by the relationship of the emerging traffic aggregate to the entering target group. That relationship can depend on the arriving traffic pattern as well as the configuration of the traffic conditioners. For example, if the EF PHB [RFC2598] and a strict policer of rate R are associated with the foo PDB, then the first part of characterizing the foo PDB is to write the relationship between the arriving target packets and the departing foo traffic aggregate. In this case, "the rate of the emerging foo traffic aggregate is less than or equal to the smaller of R and the arrival rate of the target group of packets" and additional temporal characteristics of the packets (e.g., burst) may be specified as desired. Thus, there is a "loss rate" on the arriving target group that results from sending too much traffic or the traffic with the wrong temporal characteristics. This loss rate should be entirely preventable (or controllable) by the upstream sender conforming to the traffic conditioning associated with the PDB specification.
この効果は入るターゲットグループに新たなトラフィック集約の関係によって定量化されます。その関係は、到着トラフィックパターンだけでなく、交通コンディショナーの設定に依存することができます。 EF PHB [RFC2598]とレートRの厳密ポリサーがFOOのPDBに関連付けられている場合、例えば、その後のfoo PDBを特徴付けるの最初の部分は、到来するターゲット・パケットおよび逸脱FOOトラフィック集合間の関係を記述することです。この場合、パケットの付加的な時間特性「新興FOOトラフィック凝集の速度は以下のR小さく、ターゲット・パケットのグループの到着レートに等しい」（例えば、バースト）として指定することができます希望。このように、あまりにも多くのトラフィックや間違った時間的特性を持つトラフィックを送信した結果到着ターゲットグループの「損失率」があります。この損失率は、PDB仕様に関連付けられたトラフィック調整に準拠上流の送信者によって完全に予防（または制御可能）でなければなりません。
The issue of "who is in control" of the loss (or demotion) rate helps to clearly delineate this component of PDB performance from that associated with transiting the domain. The latter is completely under control of the operator of the DS domain and the former is used to ensure that the entering traffic aggregate conforms to the traffic profile to which the operator has provisioned the network. Further, the effects of traffic conditioning on the target group can usually be expressed more simply than the effects of transiting the DS domain on the traffic aggregate's traffic profile.
損失（または降格）率の「制御している」の問題は明らかにドメインを通過するに関連付けられていることから、PDB性能のこのコンポーネントを描写するのに役立ちます。後者は完全にDSドメインのオペレータの制御下にあり、前者は入るトラフィック集合は、オペレータがネットワークをプロビジョニングしていたトラフィックプロファイルに準拠していることを保証するために使用されます。さらに、ターゲットグループのトラフィック調整の効果は、通常、トラフィック集約のトラフィックプロファイルのDSドメインを通過する効果よりも、より簡単に表現することができます。
A PDB may also apply traffic conditioning at DS domain egress. The effect of this conditioning on the overall PDB attributes would be treated similarly to the ingress characteristics (the authors may develop more text on this in the future, but it does not materially affect the ideas presented in this document.)
PDBはまた、DSドメインの出口でトラフィックコンディショニングを適用することができます。全体的なPDBの属性上、このコンディショニングの効果は入力特性と同様に扱われます（著者は将来的にこの上の複数のテキストを開発するかもしれないが、それは実質この文書のアイデアには影響しません。）
The second component of PDB performance is the metrics that characterize the transit of a packet of the PDB's traffic aggregate between any two edges of the DS domain boundary shown in figure 3. Note that the DS domain boundary runs through the DS boundary routers since the traffic aggregate is generally formed in the boundary router before the packets are queued and scheduled for output. (In most cases, this distinction is expected to be important.)
PDB性能の第二の成分は、DSドメイン境界がトラフィックのでDS境界ルータを介して実行されることを図3に示すノートDSドメイン境界のいずれか2つのエッジ間のPDBの交通集合のパケットの通過を特徴付ける指標でありますパケットが出力キューに入れると、予定されている前に、集計は、一般的に、境界ルータに形成されています。 （ほとんどの場合、この区別は重要であると期待されています。）
DSCPs should not change in the interior of a DS domain as there is no traffic conditioning being applied. If it is necessary to reapply the kind of traffic conditioning that could result in remarking, there should be a DS domain boundary at that point, though such an "interior" boundary can have "lighter weight" rules in its TCA. Thus, when measuring attributes between locations as indicated in figure 3, the DSCP at the egress side can be assumed to have held throughout the domain.
適用されているトラフィックのコンディショニングが存在しないようなDSCPは、DSドメインの内部には変更しないでください。それはリマークにつながる可能性がトラフィック調整の種類を再適用する必要がある場合は、そのような「インテリア」の境界はそのTCAで「軽量化」のルールを持つことができますが、その時点でDSドメイン境界があるはずです。図3に示すように位置の間の属性を測定する場合したがって、出口側のDSCPは、ドメイン全体保持されていると仮定することができます。
-------------
| |
-----X |
| |
| DS |
| domain X----
| |
-----X |
| |
-------------
Figure 3: Range of applicability of attributes of a traffic aggregate associated with a PDB (is between the points marked "X")
図3：PDBに関連するトラフィック集約の属性の適用範囲（「X」マーク点の間にあります）
Though a DS domain may be as small as a single node, more complex topologies are expected to be the norm, thus the PDB definition must hold as its traffic aggregate is split and merged on the interior links of a DS domain. Packet flow in a network is not part of the PDB definition; the application of traffic conditioning as packets enter the DS domain and the consistent PHB through the DS domain must suffice. A PDB's definition does not have to hold for arbitrary topologies of networks, but the limits on the range of applicability for a specific PDB must be clearly specified.
DSドメインは単一のノードと小さくてもよいが、より複雑なトポロジは、このようにPDBの定義は、そのトラフィックの集約を分割し、DSドメインの内部リンクにマージされるよう保持しなければならない、規範であると予想されます。ネットワーク内のパケットフローはPDB定義の一部ではありません。パケットがDSドメインを介してDSドメインと一貫性のPHBを入力すると、トラフィックのコンディショニングの適用が十分でなければなりません。 PDBの定義は、ネットワークの任意のトポロジのために保持する必要はありませんが、特定のPDBのための適用範囲には限界が明確に指定する必要があります。
In general, a PDB operates between N ingress points and M egress points at the DS domain boundary. Even in the degenerate case where N=M=1, PDB attributes are more complex than the definition of PHB attributes since the concatenation of the behavior of intermediate nodes affects the former. A complex case with N and M both greater than one involves splits and merges in the traffic path and is non-trivial to analyze. Analytic, simulation, and experimental work will all be necessary to understand even the simplest PDBs.
一般に、PDBはDSドメイン境界におけるNの入口点と出口点Mの間で動作します。 N = M = 1縮退場合、PDB属性は、中間ノードの挙動の連結は、前者に影響を与えるので、PHBの定義の属性よりも複雑です。 NとMとの複合体の場合は、両方の1より大きいがスプリットを含み、トラフィック経路に合流し、分析する非自明です。分析、シミュレーション、および実験的な作品は、すべての最も単純なのPDBを理解することが必要になります。
A DS domain is configured to meet the network operator's traffic engineering goals for the domain independently of the performance goals for a particular flow of a traffic aggregate. Once the interior routers are configured for the number of distinct traffic aggregates that the network will handle, each PDB's allocation at the edge comes from meeting the desired performance goals for the PDB's traffic aggregate subject to that configuration of packet schedulers and bandwidth capacity. The configuration of traffic conditioners at the edge may be altered by provisioning or admission control but the decision about which PDB to use and how to apply classification and traffic conditioning comes from matching performance to goals.
DSドメインは独立して、トラフィック集合体の特定のフローのパフォーマンス目標のドメインのためのネットワークオペレータのトラフィックエンジニアリングの目標を達成するために設定されています。内部ルータは明確なトラフィックの数のために設定されると、ネットワークが処理することに集約し、エッジにおける各PDBの割り当ては、パケットスケジューラおよび帯域幅容量の構成にPDBの交通集計対象のための所望の性能目標を達成するから来ています。エッジにおけるトラフィックコンディショナの構成は、制御をプロビジョニングまたは入場によって変更することができるが、PDBを使用し、分類し、トラフィックコンディショニングを適用する方法かについて決定が目標に性能を一致から来ます。
For example, consider the DS domain of figure 3. A PDB with an explicit bound on loss must apply traffic conditioning at the boundary to ensure that on the average no more packets are admitted than can emerge. Though, queueing internal to the network may result in a difference between input and output traffic over some timescales, the averaging timescale should not exceed what might be expected for reasonably sized buffering inside the network. Thus if bursts are allowed to arrive into the interior of the network, there must be enough capacity to ensure that losses don't exceed the bound. Note that explicit bounds on the loss level can be particularly difficult as the exact way in which packets merge inside the network affects the burstiness of the PDB's traffic aggregate and hence, loss.
例えば、これ以上のパケットが出てくることができるよりも入院している平均的にそれを確実にするため境界でトラフィックコンディショニングを適用する必要があります損失に明示的なバウンド図3. A PDBのDSドメインを考えます。しかし、ネットワークの内部キューイングするいくつかの時間スケール上の入力と出力トラフィックとの間の差をもたらす可能性が、平均化タイムスケールは、ネットワーク内の適度なサイズのバッファリングのために期待されるものを超えてはなりません。バーストがネットワークの内部に到着する許可されている場合はこのように、損失がバウンドを超えないことを保証するのに十分な能力がなければなりません。パケットがネットワーク内で合流する正確な方法は、PDBの交通集合したがって、損失のバースト性に影響を与えるように損失レベルに明示的な境界が特に困難であることができることに留意されたいです。
PHBs give explicit expressions of the treatment a traffic aggregate can expect at each hop. For a PDB, this behavior must apply to merging and diverging traffic aggregates, thus characterizing a PDB requires understanding what happens to a PHB under aggregation. That is, PHBs recursively applied must result in a known behavior. As an example, since maximum burst sizes grow with the number of microflows or traffic aggregate streams merged, a PDB specification must address this. A clear advantage of constructing behaviors that aggregate is the ease of concatenating PDBs so that the associated traffic aggregate has known attributes that span interior DS domains and, eventually, farther. For example, in figure 1 assume that we have configured the foo PDB on the interior DS domains of AS2. Then traffic aggregates associated with the foo PDB in each interior DS domain of AS2 can be merged at the shaded interior boundary routers. If the same (or fewer) traffic conditioners as applied at the entrance to AS2 are applied at these interior boundaries, the attributes of the foo PDB should continue to be used to quantify the expected behavior. Explicit expressions of what happens to the behavior under aggregation, possibly parameterized by node in-degrees or network diameters, are necessary to determine what to do at the internal aggregation points. One approach might be to completely reapply the traffic conditioning at these points; another might employ some limited rate-based remarking only.
PHBはトラフィックの集計が各ホップで期待することができ、治療の明示的な表現を与えます。 PDBのために、この動作は、このようにPDBを特徴付けることは集約下PHBに何が起こるか理解する必要があり、トラフィックの集約をマージして発散に適用する必要があります。これは再帰的に適用されるのPHBが知られている動作が発生しなければならない、です。最大バーストサイズは、マイクロフローまたはトラフィック集約ストリームの数をマージして成長するため、一例として、PDB仕様は、この問題に対処しなければなりません。集計行動を構築する明確な利点は、関連するトラフィックの集約が遠く、最終的には、内部DSドメインにまたがると属性を知っていたように、のPDBを連結の容易さです。例えば、図1に我々はAS2の内部DSドメイン上のfoo PDBが設定されていることを前提としています。そして、AS2の各内部DSドメイン内のfoo PDBに関連するトラフィック集合体は影内部境界ルータでマージすることができます。 AS2の入り口に適用されるものと同じ（または少ない）トラフィックコンディショナーは、これらの内部境界で適用されている場合は、FOOのPDBの属性が期待される行動を定量化するために使用され続けなければなりません。度で、またはネットワーク直径は、内部集約点で何をすべきかを決定するのに必要な凝集挙動下に何が起こるかの明示的な表現は、おそらくはノードによってパラメータ。一つのアプローチは、完全にこれらのポイントでトラフィックコンディショニングを再適用するかもしれません。他には、いくつかの制限されたレートベースのみのリマークを採用するかもしれません。
Multiple PDBs may use the same PHB. The specification of a PDB can contain a list of PHBs and their required configuration, all of which would result in the same PDB. In operation, it is expected that a single domain will use a single PHB to implement a particular PDB, though different domains may select different PHBs. Recall that in the diffserv definition [RFC2474], a single PHB might be selected within a domain by a list of DSCPs. Multiple PDBs might use the same PHB in which case the transit performance of traffic aggregates of these PDBs will, of necessity, be the same. Yet, the particular characteristics that the PDB designer wishes to claim as attributes may vary, so two PDBs that use the same PHB might not be specified with the same list of attributes.
複数のPDBは、同じPHBを使用することができます。 PDBの仕様はPHBのと同じPDBにつながるすべては自分の必要な設定のリストを含めることができます。動作では、単一のドメインが異なるドメインが、異なるのPHBを選択することができるが、特定のPDBを実装するために単一のPHBを使用することが期待されます。 DiffServの定義[RFC2474]で、単一PHBは、DSCPを一覧でドメイン内で選択されるかもしれないことを思い出してください。複数のPDBは、これらのPDBの交通集合体の通過性能は、必然的に、同じになります。その場合には同じPHBを使用する場合があります。 PDB設計者は属性が変化することができるように記載することを望むので、同じPHBを使用する2つのPDB属性の同じリストを指定することはないかもしれないことはまだ、特定の特性。
The specification of the transit expectations of PDBs across domains both assists in the deployment of QoS within a DS domain and helps enable the composition of end-to-end, cross-domain services to proceed by making it possible to hide details of a domain's internals while exposing characteristics necessary for QoS.
DSドメイン内のQoSの展開におけるドメイン間のPDBのトランジット期待の両方を支援の仕様およびドメインの内部の詳細を非表示にすることが可能となることで続行するエンドツーエンド、クロスドメインサービスの構成を可能にするのに役立ちますQoSの必要な特性を露出させつつ。
The use of PHB groups to construct PDBs can be done in several ways. A single PHB member of a PHB group might be used to construct a single PDB. For example, a PDB could be defined using just one of the Class Selector Compliant PHBs [RFC2474]. The traffic conditioning for that PDB and the required configuration of the particular PHB would be defined in such a way that there was no dependence or relationship with the manner in which other PHBs of the group are used or, indeed, whether they are used in that DS domain. In this case, the reasonable approach would be to specify this PDB alone in a document which expressly called out the conditions and configuration of the Class Selector PHB required.
PDBを構築するPHBグループの使用は、いくつかの方法で行うことができます。 PHBグループの単一PHB部材は、単一のPDBを構築するために使用されるかもしれません。例えば、PDBは単にクラスセレクタ準拠のPHB [RFC2474]のいずれかを使用して定義することができます。そのPDB及び特定のPHBの必要な構成に関するトラフィックコンディショニングは、グループの他のPHBは、それらがその中で使用されているかどうかを、実際に使用されるか、またはされる方法とは依存関係または存在しないように定義されますDSドメイン。この場合には、合理的なアプローチが明確に必要な条件とクラスセレクタPHBの設定を行うと呼ばれる文書にはこれだけでPDBを指定することです。
A single PDB can be constructed using more than one PHB from the same PHB group. For example, the traffic conditioner described in RFC 2698 might be used to mark a particular entering traffic aggregate for one of the three AF1x PHBs [RFC2597] while the transit performance of the resultant PDB is specified, statistically, across all the packets marked with one of those PHBs.
単一のPDBは、同じPHBグループから複数のPHBを用いて構築することができます。得られたPDBの走行性能は、1つの付いたすべてのパケットを横切って、統計的に、指定されている間、例えば、RFC 2698に記載されたトラフィックコンディショナは、[RFC2597]で3つのAF1xのPHBのいずれかの特定の進入トラフィック集合をマークするために使用されるかもしれませんこれらのPHBの。
A set of related PDBs might be defined using a PHB group. In this case, the related PDBs should be defined in the same document. This is appropriate when the traffic conditioners that create the traffic aggregates associated with each PDB have some relationships and interdependencies such that the traffic aggregates for these PDBs should be described and characterized together. The transit attributes will depend on the PHB associated with the PDB and will not be the same for all PHBs in the group, though there may be some parameterized interrelationship between the attributes of each of these PDBs. In this case, each PDB should have a clearly separate description of its transit attributes (delineated in a separate subsection) within the document. For example, the traffic conditioner described in RFC 2698 might be used to mark arriving packets for three different AF1x PHBs, each of which is to be treated as a separate traffic aggregate in terms of transit properties. Then a single document could be used to define and quantify the relationship between the arriving packets and the emerging traffic aggregates as they relate to one another. The transit characteristics of packets of each separate AF1x traffic aggregate should be described separately within the document.
関連のPDBのセットはPHBグループを使用して定義されるかもしれません。この場合、関連のPDBは、同じ文書内で定義する必要があります。各PDBに関連するトラフィック凝集体を作成トラフィックコンディショナは、これらのPDBのトラフィック凝集体が記載され、一緒に特徴付けされるべきであるように、いくつかの関係および相互依存性がある場合に適切です。トランジット属性は、PDBに関連付けられたPHBに依存し、これらのPDBのそれぞれの属性との間のいくつかのパラメータ化された相互関係があるかもしれないが、グループ内のすべてのPHBのために同じではありません。この場合において、各PDBは、文書内（別個のサブセクションで描写）が通過属性の明確に分離説明を持つべきです。例えば、RFC 2698に記載されたトラフィックコンディショナは、輸送特性に関して別個トラフィック集合として扱われるそれぞれが三つの異なるAF1xのPHBのため到着するパケットをマークするために使用されるかもしれません。その後、単一の文書を定義し、それらが相互に関連して到着したパケットと新興の交通集合体との間の関係を定量化するために使用することができます。各別個AF1xトラフィック集合のパケットの通過特性は、文書内の別々に説明されるべきです。
Another way in which a PHB group might be used to create one PDB per PHB might have decoupled traffic conditioners, but some relationship between the PHBs of the group. For example, a set of PDBs might be defined using Class Selector Compliant PHBs [RFC2474] in such a way that the traffic conditioners that create the traffic aggregates are not related, but the transit performance of each traffic aggregate has some parametric relationship to the other. If it makes sense to specify them in the same document, then the author(s) should do so.
PHBグループが切り離さトラフィックコンディショナーを持っているかもしれませんPHBにつき1つのPDBを作成するために使用されるかもしれないもう一つの方法が、グループのPHBの間に何らかの関係。例えば、のPDBのセットは、トラフィック凝集体を作成トラフィックコンディショナーは関連していないようにクラスセレクタ準拠のPHB [RFC2474]を使用して定義されたが、各トラフィック集合体の通過性能は、他のいくつかのパラメトリック関係を有するかもしれません。それは同じ文書でそれらを指定することは理にかなっている場合、著者（複数可）そうする必要があります。
A PDB's associated PHB, classifiers, and traffic conditioners are all in the packet forwarding path and operate at line rates. PHBs, classifiers, and traffic conditioners are configured in response to control plane activity which takes place across a range of time scales, but, even at the shortest time scale, control plane actions are not expected to happen per-packet. Classifiers and traffic conditioners at the DS domain boundary are used to enforce who gets to use the PDB and how the PDB should behave temporally. Reconfiguration of PHBs might occur monthly, quarterly, or only when the network is upgraded. Classifiers and traffic conditioners might be reconfigured at a few regular intervals during the day or might happen in response to signalling decisions thousands of times a day. Much of the control plane work is still evolving and is outside the charter of the Diffserv WG. We note that this is quite appropriate since the manner in which the configuration is done and the time scale at which it is done should not affect the PDB attributes.
PDBの関連するPHB、分類、および交通コンディショナーパケット転送パス内のすべてであり、ラインレートで動作します。 PHB、分類、および交通コンディショナーは、時間スケールの範囲を越え行われますが、でも最短時間スケールで、コントロールプレーンのアクションがパケットごとに発生すると予想されていないプレーン活性を制御するために応じて設定されています。 DSドメイン境界でクラシファイアと交通コンディショナーは、PDBとどのようにPDBが時間的に振る舞うべきを使用するように誰強制するために使用されています。 PHBの再構成は、四半期ごと、毎月発生する可能性がある、またはネットワークがアップグレードされている場合のみ。クラシファイアと交通コンディショナーは、日中にいくつか定期的に再構成されることがありますか、意思決定に何千回日をシグナルに反応して発生する可能性があります。コントロールプレーンの作業の多くは、まだ発展途上とのDiffserv WGのチャーター外です。私たちは、コンフィギュレーションが行われている方法とそれが行われた時刻スケールはPDBの属性に影響を与えるべきではないので、これは非常に適切であることに注意してください。
5 Format for Specification of Diffserv Per-Domain Behaviors
Diffservのドメイン単位の行動の仕様のための5フォーマット
PDBs arise from a particular relationship between edge and interior (which may be parameterized). The quantifiable characteristics of a PDB must be independent of whether the network edge is configured statically or dynamically. The particular configuration of traffic conditioners at the DS domain edge is critical to how a PDB performs, but the act(s) of configuring the edge is a control plane action which can be separated from the specification of the PDB.
PDBは、（パラメータ化されてもよい）は、エッジと内部との間の特定の関係から生じます。 PDBの定量化可能な特性は、ネットワークエッジが静的または動的に構成されているかどうかとは無関係でなければなりません。 DSドメインのエッジでトラフィックコンディショナの特定の構成は、PDBが実行する方法に重要であるが、エッジを構成する行為（単数または複数）はPDBの仕様から分離することができる制御プレーン・アクションです。
The following sections must be present in any specification of a Differentiated Services PDB. Of necessity, their length and content will vary greatly.
次のセクションでは、差別化サービスPDBのいずれかの仕様に存在しなければなりません。必然的にその長さと内容が大きく異なります。
All PDB specs must have an applicability statement that outlines the intended use of this PDB and the limits to its use.
すべてのPDB仕様は、このPDBの使用目的、その使用に制限を概説適用文を持っている必要があります。
This section specifies the rules or guidelines to create this PDB, each distinguished with "may", "must" and "should." The technical specification must list the classification and traffic conditioning required (if any) and the PHB (or PHBs) to be used with any additional requirements on their configuration beyond that contained in RFCs. Classification can reflect the results of an admission control process. Traffic conditioning may include marking, traffic shaping, and policing. A Service Provisioning Policy might be used to describe the technical specification of a particular PDB.
このセクションでは、と「すべきである。」「しなければならない」「あり」とそれぞれ区別し、このPDBを作成するためのルールやガイドラインを指定します技術仕様は、必要な分類とトラフィックコンディショニング（もしあれば）およびRFCに含まれる以上、その構成上の任意の追加要件で使用されるPHB（またはのPHB）をリストする必要があります。分類は、アドミッション制御プロセスの結果を反映させることができます。トラフィック調整は、マーキングトラフィックシェーピング、およびポリシングを含むことができます。サービスプロビジョニングポリシーは、特定のPDBの技術仕様を記述するために使用される可能性があります。
A PDB's attributes tell how it behaves under ideal conditions if configured in a specified manner (where the specification may be parameterized). These might include drop rate, throughput, delay bounds measured over some time period. They may be bounds, statistical bounds, or percentiles (e.g., "90% of all packets measured over intervals of at least 5 minutes will cross the DS domain in less than 5 milliseconds"). A wide variety of characteristics may be used but they must be explicit, quantifiable, and defensible. Where particular statistics are used, the document must be precise about how they are to be measured and about how the characteristics were derived.
PDBの属性は、（仕様をパラメータ化することができる）指定された方法で設定されている場合、それは理想的な条件の下でどのように動作するか教えてください。これらは、いくつかの時間にわたって測定ドロップ率、スループット、遅延限度が含まれる場合があります。彼らは境界、統計的境界、またはパーセンタイル（例えば、「少なくとも5分の間隔にわたって測定されたすべてのパケットの90％が5ミリ秒未満内にDSドメインを横断する」）であってもよいです。特性を広く使用することができるが、これらは、明示的な定量化、および正当でなければなりません。特定の統計が使用されている場合は、文書は、彼らが測定される方法についてのと特性が得られたかについての正確でなければなりません。
Advice to a network operator would be to use these as guidelines in creating a service specification rather than use them directly. For example, a "loss-free" PDB would probably not be sold as such, but rather as a service with a very small packet loss probability.
ネットワークオペレータへのアドバイスは、サービス仕様を作成する際にガイドラインとしてこれらを使用するのではなく、直接それらを使用することです。たとえば、「損失のない」PDBは、おそらくではなく、非常に小さなパケット損失確率でサービスとして、などとして販売されることはありません。
The definition and characteristics of a PDB may be parameterized by network-specific features; for example, maximum number of hops, minimum bandwidth, total number of entry/exit points of the PDB to/from the diffserv network, maximum transit delay of network elements, minimum buffer size available for the PDB at a network node, etc.
PDBの定義及び特徴は、ネットワーク特有の機能によってパラメータ化されてもよいです。例えば、ホップの最大数、最小帯域幅、DiffServのネットワーク、ネットワーク要素の最大伝送遅延、ネットワークノードでPDBのために利用可能な最小のバッファサイズから/へPDBの入口/出口ポイントの合計数、等
In most cases, PDBs will be specified assuming lossless links, no link failures, and relatively stable routing. This is reasonable since otherwise it would be very difficult to quantify behavior and this is the operating conditions for which most operators strive. However, these assumptions must be clearly stated. Since PDBs with specific bandwidth parameters require that bandwidth to be available, the assumptions to be stated may include standby capacity. Some PDBs may be specifically targeted for cases where these assumptions do not hold, e.g., for high loss rate links, and such targeting must also be made explicit. If additional restrictions, especially specific traffic engineering measures, are required, these must be stated.
ほとんどの場合、のPDBは、ロスレスリンク、リンク障害のない、と比較的安定したルーティングを想定して指定されます。それ以外の場合は行動を定量化することは非常に困難であろうと、これはほとんどの事業者が努力しているため、動作条件であるので、これは合理的です。しかし、これらの仮定を明確に記載しなければなりません。特定の帯域幅パラメータとのPDBを利用できるようにその帯域幅を必要とするので、記載される仮定はスタンバイ容量を含んでいてもよいです。これらの仮定は、高い損失率のリンク、および、そのような標的化のために、例えば、保持していない場合も明示されなければならないため、一部のPDBを特異的に標的することができます。追加の制限、特に特定のトラフィックエンジニアリング対策が、必要な場合は、これらを記載しなければなりません。
Further, if any assumptions are made about the allocation of resources within a diffserv network in the creation of the PDB, these must be made explicit.
いずれかの仮定はPDBの作成中のDiffServネットワーク内のリソースの割り当てについて行われた場合また、これらは明示的に行う必要があります。
A PDB specification must give example uses to motivate the understanding of ways in which a diffserv network could make use of the PDB although these are not expected to be detailed. For example, "A bulk handling PDB may be used for all packets which should not take any resources from the network unless they would otherwise go unused. This might be useful for Netnews traffic or for traffic rejected from some other PDB by traffic policers."
PDB仕様は一例を与える必要があり、これらは詳細に説明されることが予想されていないが、DiffServのネットワークは、PDBを利用することができる方法の理解をやる気にさせる使用しています。たとえば、「PDBを扱うバルクは、彼らがそうでない場合は、未使用の行くだろうしない限り、ネットワークからのすべてのリソースを取るべきではないすべてのパケットのために使用することができる。これは、ネットニュースのトラフィックまたはトラフィックポリサーによっていくつかの他のPDBから拒否されたトラフィックのために役に立つかもしれません。」
Note that it is not necessary for a provider to expose which PDB (if a commonly defined one) is being used nor is it necessary for a provider to specify a service by the PDB's attributes. For example, a service provider might use a PDB with a "no queueing loss" characteristic in order to specify a "very low loss" service.
それは（一般的に1を定義した場合）プロバイダがどのPDBを公開するために使用されている必要はありませんまたそれが必要なプロバイダがPDBの属性によるサービスを指定するためのものであることに注意してください。例えば、サービスプロバイダは、「非常に低損失」サービスを指定するために、特徴的な「ノーイング損失」でPDBを使用する場合があります。
This section is to inject realism into the characteristics described above. Detail the assumptions made there and what constraints that puts on topology or type of physical media or allocation.
このセクションでは、上記特性にリアリズムを注入することです。詳細がなさ仮定およびトポロジまたは物理メディアまたは割り当ての種類になりますどのような制約。
This section should include any security considerations that are specific to the PDB. Is it subject to any unusual theft-of-service or denial-of-service attacks? Are any unusual security precautions needed?
このセクションでは、PDBに固有のセキュリティ上の考慮事項を含める必要があります。それは異常なサービスの窃盗やサービス拒否攻撃を受けますか？異常なセキュリティ対策が必要とされていますか？
It is not necessary to repeat the general security discussions in [RFC2474] and [RFC2475], but a reference should be included. Also refer to any special security considerations for the PHB or PHBs used.
[RFC2474]と[RFC2475]での一般的なセキュリティの議論を繰り返す必要はありませんが、参照が含まれなければなりません。また、使用PHBまたはPHBのための特別なセキュリティ上の考慮事項を参照してください。
6 On PDB Attributes
PDB属性に6
As discussed in section 4, measurable, quantifiable attributes associated with each PDB can be used to describe what will happen to packets using that PDB as they cross the domain. In its role as a building block for the construction of interdomain quality-of-service, a PDB specification should provide the answer to the question: Under what conditions can we join the output of this domain to another under the same traffic conditioning and expectations? Although there are many ways in which traffic might be distributed, creating quantifiable, realizable PDBs that can be concatenated into multi-domain services limits the realistic scenarios. A PDB's attributes with a clear statement of the conditions under which the attributes hold is critical to the composition of multi-domain services.
セクション4で説明したように、各PDBに関連付けられた測定、定量化可能な属性は、それらがドメインを横切るように、そのPDBを使用してパケットに何が起こるかを説明するために使用することができます。どのような条件の下で、我々は同じトラフィック調整と期待の下に別のものに、このドメインの出力を結合することができます。ドメイン間質-のサービスを構築するためのビルディングブロックとしての役割では、PDB仕様は、質問に対する答えを提供しなければなりませんか？トラフィックが定量化の作成、配布されるかもしれない多くの方法がありますが、マルチドメインサービスに連結することができます実現のPDBは、現実的なシナリオを制限します。属性が保持する条件の明確な声明を持つPDBの属性は、マルチドメインサービスの構成に重要です。
There is a clear correlation between the strictness of the traffic conditioning and the quality of the PDB's attributes. As indicated earlier, numerical bounds are likely to be statistical or expressed as a percentile. Parameters expressed as strict bounds will require very precise mathematical analysis, while those expressed statistically can to some extent rely on experiment. Section 7 gives the example of a PDB without strict traffic conditioning and concurrent work on a PDB with strict traffic conditioning and attributes is also in front of the WG [VW]. This section gives some general considerations for characterizing PDB attributes.
トラフィック調整の厳しさとPDBの属性の品質との間に明確な相関関係があります。先に示したように、数値範囲は、統計またはパーセンタイルのように表される可能性があります。統計的に発現されるものがある程度の実験に頼ることができるが、厳密な境界として表現のパラメータは、非常に正確な数学的解析が必要となります。セクション7は、厳密なトラフィック調整と厳密トラフィックコンディショナーのPDBに並行作業をせずにPDBの例を与え、属性WG [VW]の前にもあります。このセクションでは、PDBの属性を特徴づけるためのいくつかの一般的な考慮事項を示します。
There are two ways to characterize PDBs with respect to time. First are properties over "long" time periods, or average behaviors. A PDB specification should report these as the rates or throughput seen over some specified time period. In addition, there are properties of "short" time behavior, usually expressed as the allowable burstiness in a traffic aggregate. The short time behavior is important in understanding buffering requirements (and associated loss characteristics) and for metering and conditioning considerations at DS boundaries. For short-time behavior, we are interested primarily in two things: 1) how many back-to-back packets of the PDB's traffic aggregate will we see at any point (this would be metered as a burst) and 2) how large a burst of packets of this PDB's traffic aggregate can appear in a queue at once (gives queue overflow and loss). If other PDBs are using the same PHB within the domain, that must be taken into account.
時間に対してのPDBを特徴づけるには二つの方法があります。まず、「長い」期間、または平均行動を超えるプロパティがあります。 PDB仕様は、いくつかの指定された期間にわたって見率やスループットとしてこれらを報告する必要があります。また、通常、トラフィックの集約における許容バースト性として表現「短い」時間の行動の性質があります。短時間の動作では、バッファリング要件（および関連する損失特性）を理解する上で重要とDSの境界での計量とコンディショニングの配慮のためです。短時間の動作については、我々は、主に二つのことに興味がある：1）どのように多くのPDBの交通集合体のバックツーバックパケットを、我々は任意のポイント（これはバーストとして計量されるだろう）とで表示されます2）どのように大規模なAこのPDBの交通集合体のパケットのバーストは、一度にキューに表示することができます（キューのオーバーフローや損失を与えます）。他のPDBは、ドメイン内の同じPHBを使用している場合、それは考慮に入れなければなりません。
To characterize the average or long-term behavior for the foo PDB we must explore a number of questions, for instance: Can the DS domain handle the average foo traffic flow? Is that answer topology dependent or are there some specific assumptions on routing which must hold for the foo PDB to preserve its "adequately provisioned" capability? In other words, if the topology of D changes suddenly, will the foo PDB's attributes change? Will its loss rate dramatically increase?
foo PDBの平均や長期の挙動を特徴づけるために、我々は、例えば、質問の数を調査しなければならない：DSドメインは平均fooのトラフィックフローを処理することはできますか？その答えトポロジは依存しているか、その「適切にプロビジョニング」機能を維持するためのfoo PDBのために保持する必要がありますルーティングのいくつかの特定の仮定があるのですか？言い換えれば、突然Dのトポロジが変化する場合、fooのPDBの属性が変更されますか？その損失率は劇的に増加するだろうか？
Let domain D in figure 4 be an ISP ringing the U.S. with links of bandwidth B and with N tails to various metropolitan areas. Inside D, if the link between the node connected to A and the node connected to Z goes down, all the foo traffic aggregate between the two nodes must transit the entire ring: Would the bounded behavior of the foo PDB change? If this outage results in some node of the ring now having a larger arrival rate to one of its links than the capacity of the link for foo's traffic aggregate, clearly the loss rate would change dramatically. In this case, topological assumptions were made about the path of the traffic from A to Z that affected the characteristics of the foo PDB. If these topological assumptions no longer hold, the loss rate of packets of the foo traffic aggregate transiting the domain could change; for example, a characteristic such as "loss rate no greater than 1% over any interval larger than 10 minutes." A PDB specification should spell out the assumptions made on preserving the attributes.
図4の領域Dが帯域幅Bのリンクとし、様々な大都市圏にNテールと米国リンギングISPとします。 D内部では、Zに接続されたAに接続されたノードとノードの間のリンクがダウンした場合、2つのノード間のすべてのfooトラフィック集約トランジットリング全体を行う必要がありますでしょうFOOのPDB変化の有界行動？リングのいくつかのノードで、この障害の結果が今、fooのトラフィック集約のためのリンクの容量よりも、そのリンクのいずれかに大きな到着率を持つ場合は、明らかに損失率が劇的に変化するであろう。この場合、トポロジー仮定はFOOのPDBの特性に影響を与えZにAからのトラフィックの経路について行われました。これらのトポロジカル仮定はもはや保持しない場合は、ドメインを通過するのfoo交通集合体のパケットの損失率が変更される可能性があり、例えば「10分よりも大きい任意の間隔で1％を超えない損失率」としては、例えば、特性PDB仕様は属性を保存上の仮定を綴る必要があります。
____X________X_________X___________ /
/ \ L |
A<---->X X<----->| E
| | |
| D | \
Z<---->X |
| |
\___________________________________/
X X
Figure 4: ISP and DS domain D connected in a ring and connected to DS domain E
図4：ISPとDSドメインDリングに接続され、DSドメインEに接続されています
Next, consider the short-time behavior of the traffic aggregate associated with a PDB, specifically whether permitting the maximum bursts to add in the same manner as the average rates will lead to properties that aggregate or under what conditions this will lead to properties that aggregate. In our example, if domain D allows each of the uplinks to burst p packets into the foo traffic aggregate, the bursts could accumulate as they transit the ring. Packets headed for link L can come from both directions of the ring and back-to-back packets from foo's traffic aggregate can arrive at the same time. If the bandwidth of link L is the same as the links of the ring, this probably does not present a buffering problem. If there are two input links that can send packets to queue for L, at worst, two packets can arrive simultaneously for L. If the bandwidth of link L equals or exceeds twice B, the packets won't accumulate. Further, if p is limited to one, and the bandwidth of L exceeds the rate of arrival (over the longer term) of foo packets (required for bounding the loss) then the queue of foo packets for link L will empty before new packets arrive. If the bandwidth of L is equal to B, one foo packet must queue while the other is transmitted. This would result in N x p back-to- back packets of this traffic aggregate arriving over L during the same time scale as the bursts of p were permitted on the uplinks. Thus, configuring the PDB so that link L can handle the sum of the rates that ingress to the foo PDB doesn't guarantee that L can handle the sum of the N bursts into the foo PDB.
次に、具体的には平均レートが凝集特性をもたらすと同様に追加する最大バーストを可能にするかどうか、これが凝集特性につながるどのような条件の下で、PDBに関連するトラフィック集合体の短時間の動作を考えます。領域Dは、アップリンクのそれぞれがfooトラフィック集合にp個のパケットをバーストすることを可能にする場合の例では、バーストは、それらトランジットとして環を蓄積することができました。リンクLに向かったパケットは、リングの両方向から来て、バックツーバック、fooのトラフィックの集約からのパケットが同時に到着することができますすることができます。リンクLの帯域幅は、リングのリンクと同じである場合、これはおそらくバッファリングの問題が発生することはありません。 Lのためにキューにパケットを送信することができる2つの入力リンクがある場合は、最悪の場合、2つのパケットがL.のために同時に到着することができ、リンクLの帯域幅が等しいまたはBは二回超えた場合、パケットが蓄積しないでしょう。 （損失境界に必要）、pは1に制限され、Lの帯域幅がfooパケットの（長期的に）到着率を超えた場合、新たなパケットが到着する前に、さらに、その後、リンクLのためのfooパケットのキューが空になります。 Lの帯域幅がBに等しい場合、他が送信されている間、1つのFOOパケットがキューイングしなければいけません。これは、Pのバーストがアップリンク上で許可されたのと同じ時間スケール中L上に到着このトラフィック集合体のN個のX pをバックツーバックパケットをもたらすであろう。したがって、そのリンクLので、PDBを設定すると、Nの合計がfooのPDBにバースト処理できるLを保証するものではありませんFOO PDBへの進入速度の合計を扱うことができます。
If the bandwidth of L is less than B, then the link must buffer Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less than the full bandwidth L, this number is larger. For probabilistic bounds, a smaller buffer might do if the probability of exceeding it can be bounded.
Lの帯域幅がB未満である場合、リンクは損失を回避するためにNxpx（B-L）/ B fooのパケットをバッファリングしなければなりません。 PDBは、全帯域幅L未満を取得している場合は、この数は大きいです。それを超える確率が有界できるのであれば、確率限界のために、より小さなバッファが行う可能性があります。
More generally, for router indegree of d, bursts of foo packets might arrive on each input. Then, in the absence of any additional traffic conditioning, it is possible that dxpx(# of uplinks) back-to-back foo packets can be sent across link L to domain E. Thus the DS domain E must permit these much larger bursts into the foo PDB than domain D permits on the N uplinks or else the foo traffic aggregate must be made to conform to the TCA for entering E (e.g., by shaping).
より一般的には、Dのルータ入次数ため、FOOパケットのバーストは、各入力に到着する可能性があります。その後、追加のトラフィック調整が存在しない場合には、このようにDSドメインのEがにこれらの非常に大きなバーストを許可する必要がありdxpx（アップリンクの＃）バックツーバックのfooパケットがドメインE.へのリンクLを介して送信され得ることが可能ですNアップリンクまたは他のfoo交通集合体は（成形して、例えば）Eを入力するためのTCAに準拠するようになされなければならないのドメインDが許すよりのfoo PDB。
What conditions should be imposed on a PDB and on the associated PHB in order to ensure PDBs can be concatenated, as across the interior DS domains of figure 1? Traffic conditioning for constructing a PDB that has certain attributes across a DS domain should apply independently of the origin of the packets. With reference to the example we've been exploring, the TCA for the PDB's traffic aggregate entering link L into domain E should not depend on the number of uplinks into domain D.
どのような条件は、図1の内部DSドメイン間として、連結することができPDB上とのPDBを確保するために関連したPHBに課されるべき？ DSドメイン間で特定の属性を持つPDBを構築するためのトラフィック調整は独立して、パケットの発信元の適用すべきです。私たちが模索されてきた例を参照すると、PDBの交通集合体は、ドメインEにリンクLを入力するためのTCAは、ドメインD.へのアップリンクの数に依存してはなりません
This section has been provided as motivational food for thought for PDB specifiers. It is by no means an exhaustive catalog of possible PDB attributes or what kind of analysis must be done. We expect this to be an interesting and evolutionary part of the work of understanding and deploying differentiated services in the Internet. There is a potential for much interesting research work. However, in submitting a PDB specification to the Diffserv WG, a PDB must also meet the test of being useful and relevant by a deployment experience, described in section 8.
このセクションでは、PDB指定子のための思考のための動機付けの食品として提供されています。それは、決して完全な可能PDB属性のカタログまたはどのような分析の行われなければならないです。これは理解してインターネットに差別化されたサービスを展開する作品の面白いと進化の一部であることを期待しています。多くの興味深い研究活動の可能性があります。しかし、DiffservのWGへPDB書を提出に、PDBはまた、セクション8に記載の展開経験により有用と関連するという試験を満たさなければなりません。
7 A Reference Per-Domain Behavior
7参考ドメイン単位の挙動
The intent of this section is to define as a reference a Best Effort PDB, a PDB that has little in the way of rules or expectations.
このセクションの目的は、基準としてベストエフォートPDB、ルールまたは期待のように少しを持つPDBを定義することです。
A Best Effort (BE) PDB is for sending "normal internet traffic" across a diffserv network. That is, the definition and use of this PDB is to preserve, to a reasonable extent, the pre-diffserv delivery expectation for packets in a diffserv network that do not require any special differentiation. Although the PDB itself does not include bounds on availability, latency, and packet loss, this does not preclude Service Providers from engineering their networks so as to result in commercially viable bounds on services that utilize the BE PDB. This would be analogous to the Service Level Guarantees that are provided in today's single-service Internet.
ベストエフォートは、（BE）PDBのDiffServネットワークを介して「通常のインターネットトラフィックを」送信するためです。すなわち、このPDBの定義および使用は、合理的な程度に、特別な分化を必要としないのDiffServネットワークにおけるパケットの前のDiffServ配信期待を維持するためです。 PDB自体は可用性、遅延、パケット損失の範囲が含まれていませんがBE PDBを活用したサービスで、商業的に実行可能な範囲になるように、これは自社のネットワークのエンジニアリングからサービスプロバイダを排除するものではありません。これは、今日のシングルサービスインターネットで提供しているサービスレベル保証に類似しただろう。
In the present single-service commercial Internet, Service Level Guarantees for availability, latency, and packet delivery can be found on the web sites of ISPs [WCG, PSI, UU]. For example, a typical North American round-trip latency bound is 85 milliseconds, with each service provider's site information specifying the method of measurement of the bounds and the terms associated with these bounds contractually.
現在、単一のサービスの商用インターネットでは、可用性、遅延、パケット配信のためのサービスレベル保証はISPの[WCG、PSI、UU]のウェブサイト上で見つけることができます。例えば、拘束典型的な北米の往復待ち時間は、各サービスプロバイダのサイトの境界の測定方法を指定する情報と契約これらの境界に関連した用語で、85ミリ秒です。
There are no restrictions governing rate and bursts of packets beyond the limits imposed by the ingress link. The network edge ensures that packets using the PDB are marked for the Default PHB (as defined in [RFC2474]), but no other traffic conditioning is required. Interior network nodes apply the Default PHB on these packets.
入口リンクによる制限を超えたパケットのレートとバーストを支配する制限はありません。ネットワークエッジは、（[RFC2474]で定義されるように）PDBを使用してパケットがデフォルトPHBのためにマークされることを保証するが、他の交通調節が必要とされません。インテリアのネットワーク・ノードは、これらのパケットにデフォルトのPHBを適用します。
"As much as possible as soon as possible".
「なるべくお早めに」。
Packets of this PDB will not be completely starved and when resources are available (i.e., not required by packets from any other traffic aggregate), network elements should be configured to permit packets of this PDB to consume them.
このPDBのパケットが完全に飢えされず、リソースは（すなわち、他のトラフィック集合からのパケットが必要としない）利用可能である場合、ネットワーク要素は、それらを消費するこのPDBのパケットを許可するように構成されるべきです。
Network operators may bound the delay and loss rate for services constructed from this PDB given knowledge about their network, but such attributes are not part of the definition.
ネットワークオペレータは、ネットワークについてのこのPDB与えられた知識から構築されたサービスのための遅延と損失率をバインドかもしれないが、そのような属性は、定義の一部ではありません。
None.
無し。
A properly functioning network, i.e., packets may be delivered from any ingress to any egress.
正常に機能してネットワーク、すなわち、パケットが任意の出力への入口から送達することができます。
There are no environmental concerns specific to this PDB.
このPDBに固有の環境問題はありません。
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
このPDBのための特定のセキュリティ・エクスポージャーはありません。 [RFC2474]と[RFC2475]での一般的なセキュリティの考慮事項を参照してください。
8 Guidelines for writing PDB specifications
PDBの仕様を記述するための8つのガイドライン
G1. Following the format given in this document, write a draft and submit it as an Internet Draft. The document should have "diffserv" as some part of the name. Either as an appendix to the draft, or in a separate document, provide details of deployment experience with measured results on a network of non-trivial size carrying realistic traffic and/or convincing simulation results (simulation of a range of modern traffic patterns and network topologies as applicable). The document should be brought to the attention of the diffserv WG mailing list, if active.
G1。この文書で与えられたフォーマットに続き、草案を書き、インターネットドラフトとして提出します。文書は、名前の一部として、「DiffServの」を持っている必要があります。どちらの案に付録として、または別の文書では、現実的なトラフィックおよび/または説得力のシミュレーション結果（近代的なトラフィックパターンやネットワークの範囲のシミュレーションを運んで非自明なサイズのネットワーク上の測定結果と展開の経験の詳細を提供適用可能なトポロジ）。アクティブな場合、ドキュメントは、差別化サービスWGメーリングリストの注意を喚起しなければなりません。
G2. Initial discussion should focus primarily on the merits of the PDB, though comments and questions on the claimed attributes are reasonable. This is in line with the Differentiated Services goal to put relevance before academic interest in the specification of PDBs. Academically interesting PDBs are encouraged, but would be more appropriate for technical publications and conferences, not for submission to the IETF. (An "academically interesting" PDB might become a PDB of interest for deployment over time.)
G2。特許請求の属性に関するコメントや質問が合理的であるものの、初期の議論は、PDBのメリットに主に焦点を当てるべきです。これはのPDBの仕様の学術関心の前に妥当性を置くための差別化サービスの目標に沿ったものです。学問的に興味深いのPDBが奨励されていますが、IETFに提出する、技術的な出版物や会議のためのより適切ではないだろう。 （「学問的に興味深い」PDBは、時間をかけて展開するための関心のPDBになるかもしれません。）
The implementation of the following guidelines varies, depending on whether there is an active diffserv working group or not.
次のガイドラインの実装がアクティブのDiffServワーキンググループであるか否かに応じて、変化します。
Active Diffserv Working Group path:
アクティブのDiffservワーキンググループのパス：
G3. Once consensus has been reached on a version of a draft that it is a useful PDB and that the characteristics "appear" to be correct (i.e., not egregiously wrong) that version of the draft goes to a review panel the WG co-chairs set up to audit and report on the characteristics. The review panel will be given a deadline for the review. The exact timing of the deadline will be set on a case-by-case basis by the co-chairs to reflect the complexity of the task and other constraints (IETF meetings, major holidays) but is expected to be in the 4-8 week range. During that time, the panel may correspond with the authors directly (cc'ing the WG co-chairs) to get clarifications. This process should result in a revised draft and/or a report to the WG from the panel that either endorses or disputes the claimed characteristics.
G3。コンセンサスはそれが便利PDBであることをドラフトのバージョンおよび特性（すなわち、甚だしく間違っていない）正しいように「見える」のドラフトのバージョンは、WGの共同議長は、レビューセットパネルに行くことに達したら監査および特性に報告するまで。レビューパネルは、レビューの期限が与えられます。期限の正確なタイミングは、タスクおよびその他の制約（IETF会議、主要な祝日）の複雑さを反映するために、共同議長によりケースバイケースで設定されますが、4-8週間であることが予想されます範囲。その間、パネルが直接執筆者の明確化を得るために（WGの共同議長をcc'ing）に対応してもよいです。このプロセスは、改訂案および/または受諾または請求特性に異議を唱えいずれかのパネルからWGの報告書になるはずです。
G4. If/when endorsed by the panel, that draft goes to WG last call. If not endorsed, the author(s) can give an itemized response to the panel's report and ask for a WG Last Call.
G4。 /パネルによって承認されたとき場合は、その案はWG最後の呼び出しに行きます。承認されていない場合、著者（複数可）パネルの報告書に項目別の応答を与え、WGラストコールを頼むことができます。
G5. If/when passes Last Call, goes to ADs for publication as a WG Informational RFC in our "PDB series".
G5。 /ときは、ラストコールに合格した場合、当社の「PDBシリーズ」にWGの情報RFCとして公表するための広告に行きます。
If no active Diffserv Working Group exists:
アクティブなDiffservのワーキンググループが存在しない場合：
G3. Following discussion on relevant mailing lists, the authors should revise the Internet Draft and contact the IESG for "Expert Review" as defined in section 2 of RFC 2434 [RFC2434].
G3。関連のメーリングリストでの議論に続いて、著者は、インターネットドラフトを改訂し、RFC 2434 [RFC2434]のセクション2で定義された「エキスパートレビュー」のためにIESGにお問い合わせください。
G4. Subsequent to the review, the IESG may recommend publication of the Draft as an RFC, request revisions, or decline to publish as an Informational RFC in the "PDB series".
G4。審査に続き、IESGは、RFCとしてドラフトの公開をお勧め改訂を要求する、または減少は、「PDBシリーズ」に情報RFCとして公開することがあります。
9 Security Considerations
9セキュリティに関する考慮事項
The general security considerations of [RFC2474] and [RFC2475] apply to all PDBs. Individual PDB definitions may require additional security considerations.
[RFC2474]と[RFC2475]の一般的なセキュリティ上の考慮事項は、すべてのPDBに適用されます。個々のPDBの定義は、追加のセキュリティ上の配慮が必要な場合があります。
10 Acknowledgements
10の謝辞
The ideas in this document have been heavily influenced by the Diffserv WG and, in particular, by discussions with Van Jacobson, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Aaron Falk, and a host of other people who should be acknowledged for their useful input but not be held accountable for our mangling of it. Grenville Armitage coined "per domain behavior (PDB)" though some have suggested similar terms prior to that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document and commented so as to improve its form.
この文書のアイデアが重くバン・ジェイコブソン、デイブ・クラーク、Lixiaチャン、ジェフ・ヒューストン、スコット・ブラッドナー、ランディブッシュ、フランクKastenholzと、アーロンフォーク、および他のホストとの話し合いにより、特に、DiffservのWGの影響を受けてきましたその便利な入力のために認められるべきであるが、それを私たちのマングリングのための責任を負うことがない人。グレンヴィルアーミテージは、「ドメインの振る舞い（PDB）ごとに」造語一部は、前と同様の条件を示唆しているのに。ダン・グロスマン、ボブエンガー、ジョン・ボン・スーク、ジョンDullaertは、文書を検討し、そのフォームを改善するようにコメントしています。
References
リファレンス
[RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.ベーカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[RFC2598]ジェーコブソン、V.、ニコルズ、K.とK. Poduri、 "緊急転送PHB"、RFC 2598、1999年6月。
[RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color Marker", RFC 2698, June 1999.
[RFC2698] Heinanen、J.とR. Geurin、 "二つのレート3カラーマーカー"、RFC 2698、1999年6月。
[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for Diffserv Routers", Work in Progress.
[MODEL] Bernet、Y.、ブレイク、S.、グロスマン、D.とA.スミス、 "Diffservのルータのための非公式の管理モデル"、進行中の作業。
[MIB] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", Work in Progress.
[MIB]ベイカー、F.、チャン、K.とA.スミス、「差別化サービスアーキテクチャのための管理情報ベース」が進行中で働いています。
[VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress.
[VW]ジェーコブソン、V.、ニコルズ、K.とK. Poduri、「ドメイン単位の行動 『仮想ワイヤ』」が進行中で働いています。
[WCG] Worldcom, "Internet Service Level Guarantee", http://www.worldcom.com/terms/service_level_guarantee/ t_sla_terms.phtml
[WCG]ワールドコム、 "インターネットサービスレベル保証"、http://www.worldcom.com/terms/service_level_guarantee/ t_sla_terms.phtml
[PSI] PSINet, "Service Level Agreements", http://www.psinet.com/sla/
[PSI] PSINet、 "サービス・レベル・アグリーメント"、http://www.psinet.com/sla/
[UU] UUNET USA Web site, "Service Level Agreements", http://www.us.uu.net/support/sla/
[UU] UUNET USAのWebサイト、 "サービス・レベル・アグリーメント"、http://www.us.uu.net/support/sla/
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA Considerations", BCP 26, RFC 2434, October 1998.
[RFC2434] Alvestrand、H.、およびT. Narten氏、 "IANAの考慮事項に関するガイドライン"、BCP 26、RFC 2434、1998年10月。
Authors' Addresses
著者のアドレス
Kathleen Nichols Packet Design, LLC 2465 Latham Street, Third Floor Mountain View, CA 94040 USA
キャスリーン・ニコルズパケットデザイン、LLC 2465レーサム・ストリート、3階マウンテンビュー、CA 94040 USA
EMail: nichols@packetdesign.com
メールアドレス：nichols@packetdesign.com
Brian Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
ブライアン・カーペンターIBM C / iCAIRスイート150 1890メープルアベニューエバンストン、IL 60201 USA O
EMail: brian@icair.org
メールアドレス：brian@icair.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。