RFC3086 日本語訳
3086 Definition of Differentiated Services Per Domain Behaviors andRules for their Specification. K. Nichols, B. Carpenter. April 2001. (Format: TXT=63122 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Nichols
Request for Comments: 3086 Packet Design
Category: Informational B. Carpenter
IBM
April 2001
コメントを求めるワーキンググループK.ニコルズ要求をネットワークでつないでください: 3086年のパケットデザインカテゴリ: 情報のB.大工IBM2001年4月
Definition of Differentiated Services Per Domain Behaviors
and Rules for their Specification
彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義
Status of this Memo
この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.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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ヘッダーにおけるcodepointの使用で交通集合を作成するために縁で規則を適用して、そのドメインで特定の推進経路処理にそれぞれのこれらを結びつけることによって、ネットワークドメインの中のサービスの質の食糧を供給することを可能にします。 diffserv WGは微分されたサービスのために一般的な構造を定義して、「1ホップあたりの推進の振舞い」(または、PHBs)として知られているルータで必要である推進経路の振舞いに焦点を合わせました。 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
次のステップは微分されたサービスドメインを通過するときパケットが特定の推進の特性を経験する交通集合を構成するのに、どう、推進経路コンポーネント(PHBs、クラシファイア、および交通コンディショナー)を使用できるかに関する例を定式化することです。 WGは1ドメインあたりの用語の振舞い、またはPDBを使用して、DSドメインに交差しているので特定のセットのパケットによって経験された振舞いについて説明すると決めました。 PDBはDSドメインに交差するとき特定のDSCP(または、DSCPsのセット)がある1セットのパケットが受ける処理を定量化する特定の測定基準によって特徴付けられます。 そしてそして、PDBが交通集合に関する推進経路処理を指定する、役割による縁のその特定の選択。
Nichols & Carpenter Informational [Page 1] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[1ページ]のRFC3086Diffserv
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の測定できるパラメタはネットワーク縁のService Level Specificationsにおける使用に適しているべきです。
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製品として進むために適用されるPDBsの上のDiffserv WGと手順への貢献のために詳細にPer-ドメインBehaviorsを定義して、議論して、形式と必要な内容を広げます。 この形式は、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. 序論… 2 2. 定義… 4 3. 斜めに進ませる縁の振舞いを定義する値… 5 4. PDBsを理解しています… 7 5. 1ドメインあたりのDiffservの振舞いの仕様のための形式…13 6. PDB属性に関して…16 7. 1ドメインあたり1つの参照の振舞い…19 8. PDB仕様を進めるためのガイドライン…21 9. セキュリティ問題…22 10. 承認…22の参照箇所…22人の作者のアドレス…23 完全な著作権宣言文…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.
微分されたServicesは1ノードあたりの最小量の複雑さ[RFC2475]を導入している間の配備可能であって、スケーラブルな状態で増加してモジュールであるServiceのIP Qualityへのアプローチを許します。 エンドユーザの観点から、QoSが支持されたいずれも間の終わりから終わりへのホストの組離れたところにあるべきです。 しかしながら、この目標はすぐに、達成できません。 それはinterdomain QoSサポートを必要とするでしょう、そして、多くのuntakenステップが路上にこれを達成する残っています。 不可欠の1ステップ(interdomain QoSのためのビジネスモデルの発展)は必ずIETFの外で展開するでしょう。 diffserv WGの目標はこれらのビジネスモデルが展開する堅い技術的な基礎を提供することです。 最初の主要なステップは斜めに進ませる縁かただ一つのネットワーク(すなわち、RFC2474の用語のDS Domain)のイングレスと出口の間のintradomain QoSを支持することでしょう。 意志は縁から縁へのこのQoSが構成可能であるはずであるということです、純粋に技術的な意味で、複数のDSドメインで構成されたDS Regionの向こう側の定量化可能なQoSに。
Nichols & Carpenter Informational [Page 2] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[2ページ]のRFC3086Diffserv
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はすべてのネットワーク・ノード(振舞いかPHBsを進めるホップ)の推進経路で必要である振舞いを標準化する第1段階を終えました。 RFCs2474、2597年、および2598年に定義されたPHBsは個々の箱で特異なパケット取り扱いのための豊かな道具箱を与えます。 diffservの一般的な建築モデルはRFC2475に記録されました。 非公式のルータモデル[MODEL]は交通調節と他の推進の振舞いのモデルについて説明します。 しかしながら、専門的な問題は「箱」をintradomain 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分野でのマークだけによって区別された1セットのパケットの1ドメインあたり1個のベースで経路属性を進める指定のステップは、Diffserv QoSの発展で批判的であり、ビジネスモデルの構造で支援される技術的な入力を提供するべきです。 このドキュメントは、DSドメインの向こう側にQoS属性について説明するために用語の「1ドメインあたりの振舞い」か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
Diffserv分類と交通調節は結果の交通集合の構成に制限を課すためにDSドメインの境界に到着するパケットに適用されます、DSCPマークで区別されるように、ドメインの中で。 クラシファイアと交通コンディショナーは、そのドメインの方針と交通目標を反映するように用意ができて、TCA(交通Conditioning Agreement)で指定されるかもしれません。 パケットがいったんDS境界を越えると、diffserv原則への固守で、唯一それらが各ホップで受ける振舞いに従ってパケットを分類するのは可能になります(DSCPによって選択されるように)。 このアプローチは推進経路と制御飛行機に周知のスケーリング利点を持っています。 1ホップあたりの振舞い定義が集合の下で特定のタイプの不変性をもたらす場合にだけ結果として生じる、これらが特性をスケーリングする以下があります井戸が、認めた。 そのドメインのあらゆるノードに、1ホップあたりの振舞いが同等であるに違いないので、そのPHBのためにマークされたパケットのセットがあらゆるノードで異なるかもしれない間、PHBsが定義されるべきであるので、彼らの特性はパケットによって取られたDSドメインを通してルータのイングレスリンクの上と、そして、特定の経路の上の関連BAの交通量によりません。 明確に、ネットワークを横断するのに従って、同じ交通集合に属す交通の異なった流れが、合併して、分かれます。 ドメインを横断するのに応じて著しい交通集合の時の特性がどう変化するかにかかわらず特定のPHBを使用するPDBの特性が持ちこたえるなら、そのPDBは比例します。 (これは、明確に、特定のPDBに割り当てられた帯域幅などの数字のパラメタが異なったポイントでネットワークにおいて異なるかもしれないと仮定して、交通量が異なるのに応じて、ダイナミックに調整されるかもしれません。) そこです。
Nichols & Carpenter Informational [Page 3] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[3ページ]のRFC3086Diffserv
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.
特性の保持でありそれがDSのサイズかトポロジーで限界に翻訳されるところへの限界はそのPDBを使用できるドメインですか? 役に立つ単一のリンクDSドメインは存在するかもしれませんが、ネットワークの規模で不変であるか、ネットワークの規模と共に簡単な関係を持って、または規則を再び使うことによって特性を回収できるPDBs(すなわち、交通集合のために規則を再実施するために別の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ドメインとのPer-ドメインBehaviorの定義とサービス・レベル・アグリーメントで指定されるかもしれないサービスの間には、明らかな区別があります。 PDB定義はさまざまな方法で特徴付けられるかもしれない結果として起こるセットの特定の観察可能な属性でクラシファイア、交通コンディショナー、特定のPHBs、および特定の構成のカップリングを可能にする技術的なブロックです。 これらの定義はDSドメインを構成することにおける有益な手段であることを意図しますが、プロバイダーによって使用されるPDB(または、PDBs)がプロバイダーのネットワークで使われた特定のPHBsであるだろうというほど顧客にとって目に見えないと予想されます。 ネットワーク内の提供者が契約で顧客目に見えた状態でするそれら自身の測定を選択すると予想されて、これらはPDB定義で指定された技術的な属性と全く異なって述べられているかもしれません、Service Level Specification(SLS)からPDBの構成を取るかもしれませんが。 同様に、構成するISPのためのツールがサービス提供を微分したので、特定のPDBsは意図します。 それぞれが、特定の外部的に観察可能な測定基準を達成するために異なったセットのツールを選ぶか、またはそれら自身のを開発さえするかもしれません。 それにもかかわらず、直接か間接的な対応するSLAのService Level Specificationの部品で引用されたパラメタの中にPDBの測定できるパラメタがあると予想されます。
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にDifferentiated Services Per-ドメインBehaviorsを定義して、特定のPDBsの差出に使用しなければならない形式を指定します。
2 Definitions
2つの定義
The following definitions are stated in RFCs 2474 and 2475 and are repeated here for easy reference:
以下の定義は、RFCs2474と2475年に述べられて、ここで容易に参照できるように繰り返されます:
" Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction.
「振舞い集合:」 同じcodepointが特定の方向にリンクを越えているパケットの収集。
" 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
「微分されたサービスドメイン:」 一貫したセットの微分されたサービス方針が連携ファッションで管理されるインターネットの隣接の部分。 微分されたサービスドメインが表すことができる、相違
Nichols & Carpenter Informational [Page 4] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[4ページ]のRFC3086Diffserv
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.
「交通集合:」 通常DSドメインのPHBかDSドメインの何らかの部分集合を同じくらいに写像するcodepointとのパケットの収集。 foo PHBのためにマークされた交通集合は「foo交通集合」か「foo集合」と互換性を持って呼ばれます。 これはネットワークへのリンクからBehavior Aggregateの概念を広めます。
" 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.
「1ドメインあたりの振舞い:」 パケットの身元保証可能であるか目標グループが「斜めに進ませる縁」から受けるDSドメインの予想された処理。 (PDBも。) 特定のPHB(適切でありPHBsのリスト)と交通調節要件は各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.
「Service Level Specification(SLS)がaである、設定されて、パラメタとそれらの値について、どれが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
セクション2で定義されるように、PDBはDSドメインの「雲」の向こう側に縁から縁への振舞いについて説明します。 DSドメインの向こう側に特定のdiffservの振舞いのための目標に合っているパケットへのトランジット期待の仕様は、単一領域QoSの展開を助けて、終わらせる終わりの構成を可能にするのを助けるでしょう、交差しているドメインサービス。 PDBの特性に関係なしで特定のPHBsに建てるのによるサービスが使用した終わりから終わりを作成するためにDSドメインのネットワークを接続できます。 これほど平らです。
Nichols & Carpenter Informational [Page 5] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[5ページ]のRFC3086Diffserv
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.
抽象化で、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時までに表された複数の独自に管理されたドメインかAutonomous Systems(ASs)で構成されます。 インターネットで終わりから終わりへの遍在しているサービスの質を配備するために、IETFのための範囲にない請求と報告の問題を含んでいるビジネスモデルは発展しなければなりません。 差し当たり、ASの中にサービスの質の多くの可能な用途があります、そして、IETFはDifferentiated Services枠組みの中でintradomain 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ドメインとインタコネクトする際に起こるのと同じ専門的な問題はインターネットの自律システム(ASs)とインタコネクトする際に起こるでしょう。
----------------------------------------
| AS2 |
| |
------- | ------------ ------------ |
| AS1 |------|-----X | | | |
------- | | | Y | | -------
| | | /| X----|--------| AS3 |
| | | / | | | -------
| | | / ------------ |
| | Y | |
| | | \ ------------ |
------- | | | \ | | |
| AS4 |------|-----X | \| | |
------- | | | Y X----|------
| | | | | |
| ------------ ------------ |
| |
| |
----------------------------------------
---------------------------------------- | 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
独身のAS(例えば、1図のAS2)はサブネットワークで構成されるかもしれません、そして、定義が許容するように、これらは別々のDSドメインであるかもしれません。 ASには、複数のDSドメインが様々な意味であるかもしれません、位相的な、そして/または、技術的な境界に従う最も注目に値する存在
Nichols & Carpenter Informational [Page 6] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[6ページ]のRFC3086Diffserv
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.
そして、リソースの配分を切り離すために。 自分達をこれらの「内部」のDSドメインの間のDS境界に制限するなら、私たちは、サービスをセットアップするという非技術系の問題を避けて、characterizable PDBsを作成する問題を記述できます。
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を実施している状態でそれらの交通がTraffic Conditioning Agreements(TCAs)に従うのを確実にする上流のドメインに基づいています、その結果、分別よくPDBsに関連している測定基準は計算できます。 1図の手紙「X」と「Y」は順応(例えば、整形器とpolicers)を確実にして、実施する交通コンディショナーを含むDS境界ルータを表します。 policersと整形器はDS境界でASs(「X」箱)に予想されますが、どこでも、またはどこにも現れないかもしれません、内部 明確に、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のこの定義はRFC2474で説明された推進経路と制御飛行機の分離を続けています。 パケットの経路のあらゆるホップの振舞いが複数のホップを通した交通集合の合併と分岐でどのように影響を受けるかを考えることによって、推進経路特性は記述されます。 ネットワークインフラにおける変化を表して、ノードにおける1ホップあたりの振舞いはまれに構成されます。 より頻繁なサービスの質変化はDS境界の構成でコントロール飛行機機能を使うのから来ます。 PDBがコントロールがドメインの向こう側にサービスの品質目標で交通集合を形成するのに運動させられるDSドメインレベルとパケットが取るホップとリンクあたりの処理との品質を満たすのに結果として生じるリンクを提供する、-、サービス目標について。
4 Understanding PDBs
4 PDBsを理解していること。
4.1 Defining PDBs
4.1 PDBsを定義すること。
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:
RFCs2474と2475は、「同じDS codepointが特定の方向にリンクを越えているパケットの収集」とDifferentiated Services Behavior Aggregateを定義して、同じDSCPがあるパケットが同じ1ホップあたりの推進処理(または、PHB)をただ一つのDSドメインの中のいたる所に到着させるとさらに述べます。 複数のDSCPsがPHBを同じくらいに写像しても、これが各DSCPのために個別に成立しなければならないことに注意してください。 このドキュメントのセクション2では、私たちは、容易にDSドメインの中のいたる所で同じPHBに写像されるパケットについて言及できるようにdiffserv意味との交通集合の、より一般的な定義を導入しました。 また、セクション2は私たちがこのセクションに広がるPDBsの短い定義を提示しました:
Nichols & Carpenter Informational [Page 7] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[7ページ]のRFC3086Diffserv
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.
1ドメインあたりの振舞い: パケットの身元保証可能であるか目標グループが「斜めに進ませる縁」から受けるDSドメインの予想された処理。 特定のPHB(適切でありPHBsのリスト)と交通調節要件は各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属性は、絶対である、または統計的であるかもしれません、そして、それらはネットワーク所有地によってparameterizedされるかもしれません。 例えば、「Tより大きいどんな期間にわたっても測定されると、0.1%未満のパケットは落とされること」に従って、損失属性が言い表されるかもしれなくて、「渡されたパケットの50%は、遅れほどdミリセカンドでは、30%が、遅れが3d原稿以下の遅れを2d msよりそれほど、そして、20%見るのを見るのがわからないこと」のA広範囲の測定基準が可能であるときに、遅れ属性は言い表されるかもしれません。 一般に、それらは領域か絶対値としてというよりむしろ百分順位として言い表されるでしょう。
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ドメインの縁に到着するターゲット・グループのパケットに適用されます。 ターゲット・グループはすべて到着しているパケットとパケットクラシファイア[RFC2475](クラシファイアが「ヌルであるかもしれない」ところ)の使用で区別されます。 ターゲット・グループへのPDBの機能には、2つの部品があります。 最初の部分は交通集合を作成する交通調節の使用です。 交通調節の間、conformantパケットはPDBに関連しているPHBのためにDSCPと共にマークされます(2が計算するのを確実にしてください)。 第二部はパケットによって間にDSドメインの内陸部を通過する同じ交通集合から経験された処理であり、DSの内部はドメイン境界です。 以下の小区分はさらにDSドメイン境界に到着するターゲット・グループへのこれらの2つの効果について検討します。
----------- ------------ -------------------- foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets | | |of packets | |& marking (for foo) | aggregate
----------- ------------ --------------------
----------- ------------ -------------------- foo到着_|クラシファイア|_|ターゲット・グループ|_|交通調節|_ 交通パケット| | |パケットについて| |マーク(fooのための)| 集合----------- ------------ --------------------
Figure 2: Relationship of the traffic aggregate associated
with a PDB to arriving packets
図2: 到着パケットへのPDBに関連している交通集合の関係
Nichols & Carpenter Informational [Page 8] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[8ページ]のRFC3086Diffserv
4.1.1 Crossing the DS edge: the effects of traffic conditioning on the
target group
4.1.1 DSに交差して、斜めに進んでください: 交通調節のターゲット・グループへの効果
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.
この効果は現れている交通集合の関係によって入るターゲット・グループに定量化されます。 その関係は交通コンディショナーの構成と同様に到着トラフィック・パターンに依存できます。 例えば、foo PDBを特徴付ける最初の部分はEF PHB[RFC2598]とレートRの厳しいpolicerが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属性へのこの調節の効果は同様にイングレスの特性に扱われるでしょう。(作者は将来、これに関する、より多くのテキストを開発するかもしれませんが、それは物質的に本書では提示された考えに影響しません。)
4.1.2 Crossing the DS domain: transit effects
4.1.2 DSドメインに交差します: トランジット効果
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性能の2番目の成分は3が中で計算するのが示されたDSドメイン境界のどんな2つの縁の間のPDBの交通集合のパケットのトランジットを特徴付ける測定基準です。 パケットが出力のために列に並ばせられて、予定される前に、交通集合が境界ルータで一般に形成されるのでDSドメイン境界がDS境界ルータを貫くことに注意してください。 (多くの場合、この区別が重要であると予想されます。)
Nichols & Carpenter Informational [Page 9] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[9ページ]のRFC3086Diffserv
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.
適用されていて、条件とする交通が全くないとき、DSCPsはDSドメインの内陸部で変化するはずがありません。 異状をもたらすことができた交通調節の種類を再び使うのが必要であるなら、その時、DSドメイン境界があるべきです、そのような「内部」の境界はTCAに「より軽い重さ」規則を持つことができますが。 図にみられるように位置の間の属性を測定して、3、出口の側のDSCPが思うことができるとき、したがって、ドメイン中で成立したと思われてください。
-------------
| |
-----X |
| |
| DS |
| domain X----
| |
-----X |
| |
-------------
------------- | | -----X| | | | DS| | ドメイン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ドメインはただ一つのノードと同じくらい小さいかもしれませんが、より複雑なtopologiesは標準であると予想されて、その結果、交通集合がDSドメインの内部のリンクの上に分けられて、合併されているとき、PDB定義は成立しなければなりません。 ネットワークでのパケット流動はPDB定義の一部ではありません。 パケットがDSドメインを通してDSドメインと一貫したPHBに入るとき、交通調節の応用は十分でなければなりません。 PDBの定義はネットワークの任意のtopologiesのために成立する必要はありませんが、明確に特定の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属性の定義が前者に影響するより複雑です。 両方1つ以上がかかわるNとMがある複雑なケースは、分かれて、交通経路で合併して、分析するために非些細です。 分析的で、シミュレーションであって、実験的な仕事は、最も簡単なPDBsさえ理解するためにすべて必要になるでしょう。
4.2 Constructing PDBs
4.2 PDBsを組み立てること。
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
DSドメインは、交通集合の特定の流れの性能目標の如何にかかわらずネットワーク・オペレータのドメインの交通工学目標を達成するために構成されます。 一度
Nichols & Carpenter Informational [Page 10] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[10ページ]のRFC3086Diffserv
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.
内部のルータはネットワークが扱う異なった交通集合の数のために構成されます、縁での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のDSドメインを考えてください。 損失の明白なバウンドがあるPDBは、平均して、それ以上のパケットが全く現れることができるより認められないのを保証するために境界で交通調節を適用しなければなりません。 もっとも、ネットワークへの内部の待ち行列はいくつかのスケールの上で入力と出力交通の違いをもたらすかもしれなくて、平均したスケールはネットワークにおける合理的に大きさで分けられたバッファリングのために予想されるかもしれないことを超えるべきではありません。 したがって、炸裂がネットワークの内部に到着できるなら、損失がバウンドを超えていないのを保証する能力が十分あるに違いありません。 パケットがネットワークの中で合併する正確な方法がPDBの交通集合としたがって、損失のburstinessに影響するとき、損失レベルの明白な領域が特に難しい場合があることに注意してください。
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.
PHBsは交通集合が各ホップで予想できる処理の明白な表現をします。 PDBに関しては、この振舞いは合併に申し込まれなければなりません、そして、交通集合をそらして、その結果、PDBを特徴付けるのは何が集合の下でPHBに起こるかを理解しているのを必要とします。 すなわち、再帰的に適用されたPHBsは知られている振舞いをもたらさなければなりません。 例として、microflowsの数か交通の集合流れに応じて最大の放出量が合併されているのに成長するので、PDB仕様はこれを記述しなければなりません。 集められる振舞いを構成する明らかに有利な立場がPDBsを連結する容易さであるので、関連交通集合はその長さに内陸のDSドメインで結局より遠い状態で属性を知っていました。 例えば、1図では、私たちがAS2の内陸のDSドメインのfoo PDBを構成したと仮定してください。 そして、陰影をつけられた内部の境界ルータでAS2のそれぞれの内陸のDSドメインのfoo PDBに関連している交通集合を合併できます。 AS2への入り口の適用されるとしての同じ、そして、(より少ない)の交通コンディショナーがこれらの内部の境界で適用されるなら、foo PDBの属性は、予想された振舞いを定量化するのに使用され続けるべきです。 振舞いがことによるとノードによる度であることでparameterizedされた集合かネットワーク直径の下でどうなるかに関する明白な表現が、内部の集合ポイントで何をしたらよいかを決定するのに必要です。 1つのアプローチはこれらのポイントで交通が調節であると完全に再び使うことであるかもしれません。 別のものはいくつかの限られたレートベースの異状だけを使うかもしれません。
Nichols & Carpenter Informational [Page 11] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[11ページ]のRFC3086Diffserv
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.
複数のPDBsが同じPHBを使用するかもしれません。 PDBの仕様はPHBsのリストと彼らの必要な構成を含むことができます。そのすべてが同じPDBをもたらすでしょう。 稼働中であり、単一領域が特定のPDBを実行するのに独身のPHBを使用すると予想されます、異なったドメインは異なったPHBsを選択するかもしれませんが。 diffserv定義[RFC2474]では、独身のPHBがドメインの中でDSCPsのリストによって選択されるかもしれないと思い出してください。 複数のPDBsがこれらのPDBsの交通集合のトランジット性能がそうするどの場合に同じPHBを使用するかもしれないか、必要であり、同じであってください。 しかし、PDBデザイナーが属性として要求したがっている特定の特性が異なるかもしれないので、同じPHBを使用する2PDBsは属性の同じリストで指定されないかもしれません。
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.
ドメイン中のPDBsへのトランジット期待の仕様は、DSドメインの中でQoSの展開を助けて、終わらせる終わりの構成を可能にするのを助けます、QoSに必要な特性を露出している間、ドメインのインターナルの詳細を隠すのを可能にすることによって続かせる交差しているドメインサービス。
4.3 PDBs using PHB Groups
PHBを使用する4.3PDBsが分類します。
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.
いくつかの方法でPDBsを組み立てるPHBグループを使用できます。 PHBグループの独身のPHBメンバーは、独身のPDBを組み立てるのに使用されるかもしれません。 例えば、ちょうどClass Selector Compliant PHBs[RFC2474]の1つを使用することでPDBを定義できるでしょう。 それのためにPDBと特定のPHBの必要な構成を条件とさせる交通はグループの他のPHBsが使用されている方法とのどんな依存も関係もなかったような方法で定義されるだろうか、彼らがそのDSドメインで使用されるか否かに関係なく、本当に。 この場合、合理的なアプローチはClass Selector 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.
同じPHBグループから1PHBを使用することで独身のPDBを組み立てることができます。 例えば、RFC2698で説明された交通コンディショナーは、結果のPDBのトランジット性能がそれらのPHBsの1つと共にマークされたすべてのパケットの向こう側に統計的に指定されている間、3AF1x PHBs[RFC2597]の1つにおいて、特定の入る交通が集合であるとマークするのに使用されるかもしれません。
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
関連するPDBsの1セットは、PHBグループを使用することで定義されるかもしれません。 この場合、関連するPDBsは同じドキュメントで定義されるべきです。 各PDBに関連づけられた交通集合を作成する交通コンディショナーがいくつかの関係と相互依存性を持っているとき、これが適切であるので、これらのPDBsのための交通集合は、一緒に説明されて、特徴付けられるべきです。 トランジット属性は、PDBに関連しているPHBによって、グループにおけるすべてのPHBsに同じにならないでしょう、何かがあるかもしれませんが
Nichols & Carpenter Informational [Page 12] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[12ページ]のRFC3086Diffserv
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.
それぞれのこれらのPDBsの属性の間の相互関係をparameterizedしました。 この場合、各PDBはドキュメントの中にトランジット属性(別々の小区分では、図で表わされる)の明確に別々の記述を持っているはずです。 例えば、RFC2698で説明された交通コンディショナーは、3異なったAF1x PHBsのために到着パケットをマークするのに使用されるかもしれません。それはトランジットの特性でそれぞれ別々の交通集合として扱われることになっています。 そして、お互いに関連するとき、到着しているパケットと現れている交通集合との関係を定義して、定量化するのにただ一つのドキュメントを使用できました。 それぞれの別々の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グループが1PHBあたり1PDBを作成するのに使用されるかもしれない別の方法は交通コンディショナー、しかし、グループのPHBsの間の何らかの関係の衝撃を吸収したかもしれません。 例えば、PDBsの1セットは、交通集合を作成する交通コンディショナーが関係づけられませんが、それぞれの交通集合のトランジット性能にはもう片方との何らかのパラメトリック関係があるような方法で、Class Selector Compliant PHBs[RFC2474]を使用することで定義されるかもしれません。 同じドキュメントでそれらを指定する意味になるなら、作者はそうするべきです。
4.4 Forwarding path vs. control plane
4.4 制御飛行機に対して経路を送ること。
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、クラシファイア、および交通コンディショナーは、すべてパケット推進経路にあって、ライン料率で作動します。 PHBs、クラシファイア、および交通コンディショナーはさまざまなタイムスケールの向こう側に行われるコントロール飛行機活動に対応して構成されますが、最も短いタイムスケールでさえ、コントロール飛行機動作がパケット単位で起こらないと予想されます。 DSドメイン境界のクラシファイアと交通コンディショナーは、だれが、PDBを使用し始めるか、そして、PDBがどう時間的に振る舞うはずであるかを実施するのに使用されます。 PHBsの再構成が毎月起こるかもしれない、季刊誌かネットワークはいつだけアップグレードするか。 クラシファイアと交通コンディショナーは、1日の間、いくつかの一定の間隔で、再構成されるか、または何千回も決定に合図することに対応して1日間、起こるかもしれません。 コントロール飛行機仕事の多くは、まだ発展していて、Diffserv WGの特許の外であります。 私たちは、構成が行われる方法とそれが行われるタイムスケールがPDB属性に影響するべきでないのでこれがかなり適切であることに注意します。
5 Format for Specification of Diffserv Per-Domain Behaviors
5 1ドメインあたりのDiffservの振舞いの仕様のための形式
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
PDBsは縁と内部(parameterizedされるかもしれない)との特定の関係から起こります。 ネットワーク縁が静的かダイナミックに構成されるかどうかからPDBの定量化可能な特性は独立しているに違いありません。 交通の特定の構成
Nichols & Carpenter Informational [Page 13] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[13ページ]のRFC3086Diffserv
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.
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.
以下のセクションはDifferentiated Services PDBのどんな仕様にも存在していなければなりません。 必要であることで、それらの長さと内容は大いに異なるでしょう。
5.1 Applicability Statement
5.1 適用性証明
All PDB specs must have an applicability statement that outlines the intended use of this PDB and the limits to its use.
すべてのPDB仕様には、このPDBの意図している使用と使用への限界について概説する適用性証明がなければなりません。
5.2 Technical specification
5.2 技術仕様書
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、“may"、“must"によって区別されたそれぞれを作成するために規則かガイドラインを指定する、「」であるべきです 技術仕様書は、RFCsに含まれたそれを超えたそれらの構成に関するどんな追加要件と共にも使用されるために、分類、調節が必要とした交通(もしあれば)、およびPHB(または、PHBs)を記載しなければなりません。 分類は入場コントロールの過程の結果を反映できます。 交通調節は、交通が形成されて、マークして、取り締まるのを含むかもしれません。 Service Provisioning Policyは、特定のPDBに関する技術仕様書を説明するのに使用されるかもしれません。
5.3 Attributes
5.3 属性
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の属性は、指定された方法(仕様がparameterizedされるかもしれないところ)で構成されるならそれが理想的な条件のもとでどのように反応するかを言います。 これらは低下率、スループット、いつかの期間にわたって測定された遅れ領域を含むかもしれません。 それらは、領域、統計的な領域、または百分順位であるかもしれません(例えば、「少なくとも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はたぶん非常にわずかなパケット紛失率と共にそういうもの、しかし、むしろサービスとして販売されないでしょう。
Nichols & Carpenter Informational [Page 14] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[14ページ]のRFC3086Diffserv
5.4 Parameters
5.4 パラメタ
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の定義と特性はネットワーク特有の特徴によってparameterizedされるかもしれません。 例えば、最大数のホップ(最小の帯域幅)はPDBの項目数/エキジットポイントをdiffservネットワークからの/に合計します、ネットワーク要素の最大のトランジット遅れ、ネットワーク・ノードなどでPDBに有効な最小のバッファサイズ
5.5 Assumptions
5.5 仮定
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.
多くの場合、losslessがリンクと、リンクの故障がなくて、比較的安定したルーティングであると仮定しながら、PDBsは指定されるでしょう。 さもなければ、振舞いを定量化するのは非常に難しいでしょう、したがって、これが妥当です、そして、ほとんどのオペレータが努力する運転条件です。 しかしながら、明確にこれらの仮定を述べなければなりません。 特定の帯域幅パラメタがあるPDBsが、その帯域幅が利用可能であることを必要とするので、述べられるべき仮定は予備能力を含むかもしれません。 いくつかのPDBsがこれらの仮定が例えば、高い損失レートリンクに成立しないケースのために明確に狙うかもしれません、そして、また、そのような狙いを明白にしなければなりません。 追加制限(特に特定の交通工学測定)が必要であるなら、これらを述べなければなりません。
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.
さらに、diffservネットワークの中でリソースの配分に関してPDBの創造で何か仮定をするなら、これらを明白にしなければなりません。
5.6 Example Uses
5.6 例の用途
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を扱う嵩はそうでなければ、未使用にならないならネットワークからどんなリソースも取るはずがないすべてのパケットに使用されるかもしれません」。 「これはNetnews交通か交通policersによってある他のPDBから拒絶された交通の役に立つかもしれません。」
5.7 Environmental Concerns (media, topology, etc.)
5.7 環境問題(メディア、トポロジーなど)
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.
プロバイダーがどの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.
このセクションは上で説明された特性にリアリズムを注ぐことになっています。 そこでされた仮定とそれが物理的なメディアのトポロジーかタイプにどんな規制を置くか、そして、配分を詳しく述べてください。
Nichols & Carpenter Informational [Page 15] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[15ページ]のRFC3086Diffserv
5.8 Security Considerations for each PDB
5.8 各PDBのためのセキュリティConsiderations
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かPHBsのための問題が使用したあらゆる特別担保を参照してください。
6 On PDB Attributes
6 PDB属性に関して
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に関連している定量化可能な属性を使用できます。 interdomain品質の工事のためのブロックとしての役割、-サービスでは、PDB仕様は質問の答を提供するべきです: どんな条件のもとでは、私たちはこのドメインの出力に同じ交通調節と期待で別のものに参加できますか? 交通が広げられるかもしれない多くの方法がありますが、マルチドメインサービスに連結できる作成の定量化可能で、実現可能なPDBsは現実的なシナリオを制限します。 属性が成立する状態の明確な声明がある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
時間に関してPDBsを特徴付ける2つの方法があります。 まず最初に、「長い」期間、または平均した振舞いの上に特性があります。 PDB仕様はいつかの指定された期間の調べられたレートかスループットとしてこれらを報告するべきです。 さらに、交通における許容できるburstinessが集められるので通常、示された「短い」時間の振舞いの特性があります。 DS境界で問題を要件(そして、関連損失の特性)をバッファリングするのを理解して、計量して、条件とさせるのに、短い時間の振舞いは重要です。 短い間の振舞いのために、私たちはそうです。
Nichols & Carpenter Informational [Page 16] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[16ページ]のRFC3086Diffserv
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.
主として2つのものに関心がある: 私たちは任意な点(これは炸裂として計量される)で1) 集合がそうするPDBの交通のいくつの背中合わせのパケットを見ますか、そして、2) このPDBの交通集合のパケットのどれくらい大きい炸裂はすぐに(待ち行列オーバーフローと損失を与える)、待ち行列に現れることができますか? 他のPDBsがドメインの中で同じPHBを使用しているなら、それを考慮に入れなければなりません。
6.1 Considerations in specifying long-term or average PDB attributes
6.1 長期的であるか平均したPDB属性を指定することにおける問題
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の中では、Aに接続されたノードとZに接続されたノードとのリンクが落ちるなら、2つのノードの間のすべてのfoo交通集合が全体のリングを通過しなければなりません: foo PDBの境界がある動きは変化するでしょうか? この供給停止がfooの交通集合のためのリンクの容量より現在さらに大きい到着率をリンクの1つまで持っているリングの何らかのノードをもたらすなら、明確に、損失率は劇的に変化するでしょう。 この場合、位相的な仮定はAからfoo PDBの特性に影響したZまでの交通の経路の周りでされました。 これらの位相的な仮定がもう成立しないなら、ドメインを通過するfoo交通集合のパケットの損失率は変化するかもしれません。 例えば、「10分より大きいどんな間隔にわたる1%以下の損失率」などの特性。 PDB仕様は属性を保存するときされた仮定について詳しく説明するべきです。
____X________X_________X___________ /
/ \ L |
A<---->X X<----->| E
| | |
| D | \
Z<---->X |
| |
\___________________________________/
X X
____X________X_________X___________ //\L| <。---->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ドメインEにつなげられたDSドメインD
Nichols & Carpenter Informational [Page 17] RFC 3086 Diffserv per Domain Behaviors April 2001
ドメイン振舞い2001年4月あたりのニコルズと大工の情報[17ページ]のRFC3086Diffserv
6.2 Considerations in specifying short-term or bursty PDB attributes
6.2 短期的であるかbursty PDB属性を指定することにおける問題
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.
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.
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.
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.
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).
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).
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
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
Nichols & Carpenter Informational [Page 18] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 18] RFC 3086 Diffserv per Domain Behaviors April 2001
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.
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.
6.3 Remarks
6.3 Remarks
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.
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.
7 A Reference Per-Domain Behavior
7 A Reference Per-Domain Behavior
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.
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.
7.1 Best Effort PDB
7.1 Best Effort PDB
7.1.1 Applicability
7.1.1 Applicability
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.
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.
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.
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.
Nichols & Carpenter Informational [Page 19] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 19] RFC 3086 Diffserv per Domain Behaviors April 2001
7.1.2 TCS and PHB configurations
7.1.2 TCS and PHB configurations
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.
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.
7.1.3 Attributes of this PDB
7.1.3 Attributes of this PDB
"As much as possible as soon as possible".
"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.
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.
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.
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.
7.1.4 Parameters
7.1.4 Parameters
None.
None.
7.1.5 Assumptions
7.1.5 Assumptions
A properly functioning network, i.e., packets may be delivered from any ingress to any egress.
A properly functioning network, i.e., packets may be delivered from any ingress to any egress.
7.1.6 Example uses
7.1.6 Example uses
1. For the normal Internet traffic connection of an organization.
1. For the normal Internet traffic connection of an organization.
2. For the "non-critical" Internet traffic of an organization.
2. For the "non-critical" Internet traffic of an organization.
3. For standard domestic consumer connections
3. For standard domestic consumer connections
7.1.7 Environmental Concerns
7.1.7 Environmental Concerns
There are no environmental concerns specific to this PDB.
There are no environmental concerns specific to this PDB.
7.1.8 Security Considerations for BE PDB
7.1.8 Security Considerations for BE PDB
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
Nichols & Carpenter Informational [Page 20] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 20] RFC 3086 Diffserv per Domain Behaviors April 2001
8 Guidelines for writing PDB specifications
8 Guidelines for writing PDB specifications
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. 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.
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. 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.)
The implementation of the following guidelines varies, depending on whether there is an active diffserv working group or not.
The implementation of the following guidelines varies, depending on whether there is an active diffserv working group or not.
Active Diffserv Working Group path:
Active Diffserv Working Group path:
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. 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.
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. 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.
Nichols & Carpenter Informational [Page 21] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 21] RFC 3086 Diffserv per Domain Behaviors April 2001
G5. If/when passes Last Call, goes to ADs for publication as a WG Informational RFC in our "PDB series".
G5. If/when passes Last Call, goes to ADs for publication as a WG Informational RFC in our "PDB series".
If no active Diffserv Working Group exists:
If no active Diffserv Working Group exists:
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. 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].
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. 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".
9 Security Considerations
9 Security Considerations
The general security considerations of [RFC2474] and [RFC2475] apply to all PDBs. Individual PDB definitions may require additional security considerations.
The general security considerations of [RFC2474] and [RFC2475] apply to all PDBs. Individual PDB definitions may require additional security considerations.
10 Acknowledgements
10 Acknowledgements
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.
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.
References
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] 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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Services",
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
Nichols & Carpenter Informational [Page 22] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 22] RFC 3086 Diffserv per Domain Behaviors April 2001
[RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color
Marker", RFC 2698, June 1999.
[RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color Marker", RFC 2698, June 1999.
[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for Diffserv Routers", Work in
Progress.
[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for Diffserv Routers", Work in Progress.
[MIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", Work in
Progress.
[MIB] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", Work in Progress.
[VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual
Wire' Per-Domain Behavior", Work in Progress.
[VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress.
[WCG] Worldcom, "Internet Service Level Guarantee",
http://www.worldcom.com/terms/service_level_guarantee/
t_sla_terms.phtml
[WCG] Worldcom, "Internet Service Level Guarantee", http://www.worldcom.com/terms/service_level_guarantee/ t_sla_terms.phtml
[PSI] PSINet, "Service Level Agreements",
http://www.psinet.com/sla/
[PSI] PSINet, "Service Level Agreements", http://www.psinet.com/sla/
[UU] UUNET USA Web site, "Service Level Agreements",
http://www.us.uu.net/support/sla/
[UU] UUNET USA Web site, "Service Level Agreements", 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. and T. Narten, "Guidelines for IANA Considerations", BCP 26, RFC 2434, October 1998.
Authors' Addresses
Authors' Addresses
Kathleen Nichols Packet Design, LLC 2465 Latham Street, Third Floor Mountain View, CA 94040 USA
Kathleen Nichols Packet Design, LLC 2465 Latham Street, Third Floor Mountain View, CA 94040 USA
EMail: nichols@packetdesign.com
EMail: nichols@packetdesign.com
Brian Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
Brian Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
EMail: brian@icair.org
EMail: brian@icair.org
Nichols & Carpenter Informational [Page 23] RFC 3086 Diffserv per Domain Behaviors April 2001
Nichols & Carpenter Informational [Page 23] RFC 3086 Diffserv per Domain Behaviors April 2001
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
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.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Nichols & Carpenter Informational [Page 24]
Nichols & Carpenter Informational [Page 24]
一覧
スポンサーリンク
