RFC2475 日本語訳
2475 An Architecture for Differentiated Service. S. Blake, D. Black,M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: TXT=94786 bytes) (Updated by RFC3260) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Blake
Request for Comments: 2475 Torrent Networking Technologies
Category: Informational D. Black
EMC Corporation
M. Carlson
Sun Microsystems
E. Davies
Nortel UK
Z. Wang
Bell Labs Lucent Technologies
W. Weiss
Lucent Technologies
December 1998
コメントを求めるワーキンググループS.ブレークの要求をネットワークでつないでください: 2475年の急流ネットワーク・テクノロジーカテゴリ: 情報の黒いD.のベル研究所ルーセントテクノロジーズW.ワイスルーセントテクノロジーズEMC社のM.カールソンサン・マイクロシステムズE.デイヴィースノーテルイギリスのZ.ワング1998年12月
An Architecture for Differentiated Services
差別化されたサービスのためのアーキテクチャ
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.
このドキュメントは、インターネットでスケーラブルなサービスが分化であると実装するためにアーキテクチャを定義します。 このアーキテクチャは、IP-層のパケットマークによってDS分野[DSFIELD]を使用することで運ばれるトラフィック分類状態に集めることによって、スケーラビリティを実現します。 パケットは、それらの経路に沿ったノードで1ホップあたり1つの特定の推進の振舞いを受けるために分類されて、マークされます。 洗練された分類、マーク、取り締まり、および成形操作はネットワーク限界かホストで実装されるだけでよいです。 トラフィックがどのように差別化されたサービスできるネットワークへのエントリーをマークされて、条件とするか、そして、そのトラフィックがそのネットワークの中でどのように送られるかを治める方針に食糧を供給するサービスでトラフィックストリームにネットワーク資源を割り当てます。 これらのブロックの上でさまざまなサービスを実装することができます。
Blake, et. al. Informational [Page 1] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[1ページ]のRFC2475アーキテクチャ
Table of Contents
目次
1. Introduction ................................................. 2
1.1 Overview ................................................. 2
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 12
2.1 Differentiated Services Domain ............................ 12
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 13
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 14
2.3.1 Classifiers ........................................... 14
2.3.2 Traffic Profiles ...................................... 15
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 16
2.3.3.2 Markers ........................................... 16
2.3.3.3 Shapers ........................................... 17
2.3.3.4 Droppers .......................................... 17
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17
2.3.4.1 Within the Source Domain .......................... 17
2.3.4.2 At the Boundary of a DS Domain .................... 18
2.3.4.3 In non-DS-Capable Domains ......................... 18
2.3.4.4 In Interior DS Nodes .............................. 19
2.4 Per-Hop Behaviors ......................................... 19
2.5 Network Resource Allocation ............................... 20
3. Per-Hop Behavior Specification Guidelines .................... 21
4. Interoperability with Non-Differentiated Services-Compliant
Nodes ........................................................ 25
5. Multicast Considerations ..................................... 26
6. Security and Tunneling Considerations ........................ 27
6.1 Theft and Denial of Service ............................... 28
6.2 IPsec and Tunneling Interactions .......................... 30
6.3 Auditing .................................................. 32
7. Acknowledgements ............................................. 32
8. References ................................................... 33
Authors' Addresses ............................................... 34
Full Copyright Statement ......................................... 36
1. 序論… 2 1.1概要… 2 1.2用語… 4 1.3の要件… 8 他のアプローチとの1.4の比較… 9 2. 差別化、建築モデルにサービスを提供します… 12 2.1はサービスドメインを差別化しました… 12 2.1 .1のDS境界ノードと内部のノード… 12 2.1 .2のDSイングレスノードと出口ノード… 13 2.2はサービス領域を差別化しました… 13 2.3 トラフィック分類と調節… 14 2.3 .1のクラシファイア… 14 2.3 .2 トラフィックプロフィール… 15 2.3 .3 トラフィックコンディショナー… 15 2.3 .3 .1メーター… 16 2.3 .3 .2人のマーカー… 16 2.3 .3 .3の整形器… 17 2.3 .3 .4個の点滴器… 17 2.3 .4 トラフィックコンディショナーとmfクラシファイアの位置… 17 2.3 .4 .1 ソースドメインの中で… 17 2.3 .4 .2 DSドメインの境界で… 18 2.3 .4 .3 できる非DSドメインで… 18 2.3 .4 .4 内部のDSノードで… 19 2.4 1ホップあたりの振舞い… 19 2.5 ネットワーク資源配分… 20 3. 1ホップあたりの振舞い仕様ガイドライン… 21 4. 相互運用性の非差別化されるのによるサービス対応することのノード… 25 5. マルチキャスト問題… 26 6. セキュリティとトンネリング問題… 27 6.1の窃盗とサービス妨害… 28 6.2 IPsecとトンネリング相互作用… 30 6.3 監査します。 32 7. 承認… 32 8. 参照… 33人の作者のアドレス… 34 完全な著作権宣言文… 36
1. Introduction
1. 序論
1.1 Overview
1.1 概要
This document defines an architecture for implementing scalable service differentiation in the Internet. A "Service" defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These
このドキュメントは、インターネットでスケーラブルなサービスが分化であると実装するためにアーキテクチャを定義します。 「サービス」はネットワークの中の1つ以上の経路のセットの向こう側に一方向へのパケット伝送のいくつかの重要な特性を定義します。 これら
Blake, et. al. Informational [Page 2] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[2ページ]のRFC2475アーキテクチャ
characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service.
特性は、スループット、遅れ、ジター、そして/または、損失の量的であるか統計的な諸条件で指定されるか、または別の方法でネットワーク資源へのアクセスの何らかの相対的な優先権で指定されるかもしれません。 サービス分化が異種のアプリケーション要件とユーザ期待を収容することが望まれていて、可能にするのはインターネットのサービスの価格設定を差別化しました。
This architecture is composed of a number of functional elements implemented in network nodes, including a small set of per-hop forwarding behaviors, packet classification functions, and traffic conditioning functions including metering, marking, shaping, and policing. This architecture achieves scalability by implementing complex classification and conditioning functions only at network boundary nodes, and by applying per-hop behaviors to aggregates of traffic which have been appropriately marked using the DS field in the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to permit a reasonably granular means of allocating buffer and bandwidth resources at each node among competing traffic streams. Per- application flow or per-customer forwarding state need not be maintained within the core of the network. A distinction is maintained between:
このアーキテクチャはネットワーク・ノードで実装された多くの機能要素で構成されます、計量して、マークして、形成して、取り締まるのを含む1ホップあたり1つの小さい推進の振舞い、パケット分類機能、およびトラフィック調節機能を含んでいて。 このアーキテクチャは、複雑な分類と調節が単にネットワーク境界ノードで機能であると実装して、IPv4のDS分野を使用するか、IPv6ヘッダーであると適切にマークされたトラフィック[DSFIELD]の集合への1ホップあたりの振舞いを申し込むことによって、スケーラビリティを実現します。 1ホップあたりの振舞いが競争する中の各ノードにバッファと帯域幅リソースを割り当てる合理的に粒状の手段にトラフィックストリームを可能にするために定義される、-、アプリケーション流動か1顧客あたりの推進状態がネットワークのコアの中で維持される必要はありません。 区別は以下の間で維持されます。
o the service provided to a traffic aggregate,
o サービスはトラフィック集合に提供されました。
o the conditioning functions and per-hop behaviors used to realize
services,
o 調節機能と1ホップあたりの振舞いは以前はよくサービスがわかっていました。
o the DS field value (DS codepoint) used to mark packets to select a
per-hop behavior, and
o そしてDS分野価値(DS codepoint)が1ホップあたり1つの振舞いを選択するために以前はよくパケットをマークしていた。
o the particular node implementation mechanisms which realize a
per-hop behavior.
o 1ホップあたり1つの振舞いがわかる特定のノード実装メカニズム。
Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion.
サービスの食糧を供給するのとトラフィック調節方針はさまざまな使用挙動の実装を可能にするほどネットワーク内部の中の推進の振舞いから衝撃を吸収されます、今後の拡張の余地で。
This architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric. Development of a complementary symmetric architecture is a topic of current research but is outside the scope of this document; see for example [EXPLICIT].
このアーキテクチャだけが、サービス分化を交通の流れの一方向に提供して、したがって、非対称です。 補足的な左右対称のアーキテクチャの開発は、現在の研究の話題ですが、このドキュメントの範囲の外にあります。 例えば、[EXPLICIT]を見てください。
Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3 lists requirements addressed by this architecture, and Sec. 1.4 provides a brief comparison to other approaches for service differentiation. Sec. 2 discusses the components of the architecture
セクト。 1.2はこのドキュメントの中に使用された用語の用語集です。 秒 このアーキテクチャ、およびSecによって扱われた1.3のリスト要件。 1.4 サービス分化のための他のアプローチに簡潔な比較を提供します。 秒 2はアーキテクチャの成分について議論します。
Blake, et. al. Informational [Page 3] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[3ページ]のRFC2475アーキテクチャ
in detail. Sec. 3 proposes guidelines for per-hop behavior specifications. Sec. 4 discusses interoperability issues with nodes and networks which do not implement differentiated services as defined in this document and in [DSFIELD]. Sec. 5 discusses issues with multicast service delivery. Sec. 6 addresses security and tunnel considerations.
詳細に。 秒 3 1ホップあたりの振舞い仕様のためのガイドラインを提案します。 秒 4 本書では定義されるように差別化されたサービスを実装しないノードとネットワークと[DSFIELD]の相互運用性問題について議論します。 秒 5 マルチキャストサービス配送の問題について議論します。 秒 6 セキュリティとトンネル問題を扱います。
1.2 Terminology
1.2 用語
This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of this document.
このセクションは本書では使用される用語の一般的な概念的な概要を与えます。 これらの用語のいくつかがこのドキュメントの後のセクションで、より正確に定義されます。
Behavior Aggregate (BA) a DS behavior aggregate.
DSの振舞いが集める振舞いAggregate(BA)。
BA classifier a classifier that selects packets based
only on the contents of the DS field.
DS分野のコンテンツだけに基づくパケットを選択するBAクラシファイアaクラシファイア。
Boundary link a link connecting the edge nodes of two
domains.
境界は、2つのドメインの縁のノードを接続しながら、リンクをリンクします。
Classifier an entity which selects packets based on
the content of packet headers according to
defined rules.
クラシファイア、定義された規則に従ってパケットのヘッダーの内容に基づくパケットを選択する実体。
DS behavior aggregate a collection of packets with the same DS
codepoint crossing a link in a particular
direction.
DSの振舞いは同じDS codepointが特定の方向にリンクを越えているパケットの収集に集められます。
DS boundary node a DS node that connects one DS domain to a
node either in another DS domain or in a
domain that is not DS-capable.
別のDSドメインかドメインのDSできないノードに、あるDSドメインをつなげるDS境界ノードa DSノード。
DS-capable capable of implementing differentiated
services as described in this architecture;
usually used in reference to a domain
consisting of DS-compliant nodes.
DSできる、このアーキテクチャで説明されるように差別化されたサービスを実装することができます。 通常、DS対応することのノードから成るドメインに関して使用されています。
DS codepoint a specific value of the DSCP portion of the
DS field, used to select a PHB.
PHBを選択するのに使用されるDS分野のDSCP部分のDS codepointのa特定の価値。
DS-compliant enabled to support differentiated services
functions and behaviors as defined in
[DSFIELD], this document, and other
differentiated services documents; usually
used in reference to a node or device.
差別化されたサービスが[DSFIELD]、このドキュメントで定義される機能と振舞いであるとサポートするために可能にされるのともう一方のDS対応することの差別化されたサービスドキュメント。 通常、ノードかデバイスに関して使用されています。
Blake, et. al. Informational [Page 4] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[4ページ]のRFC2475アーキテクチャ
DS domain a DS-capable domain; a contiguous set of
nodes which operate with a common set of
service provisioning policies and PHB
definitions.
DSのドメインのa DSできるドメイン。 一般的なサービスが方針とPHB定義に食糧を供給していて作動する隣接のセットのノード。
DS egress node a DS boundary node in its role in handling
traffic as it leaves a DS domain.
それとしての取り扱いトラフィックにおける役割におけるDS境界ノードがDSドメインを出るDS出口ノード。
DS ingress node a DS boundary node in its role in handling
traffic as it enters a DS domain.
それとしての取り扱いトラフィックにおける役割におけるDSイングレスノードa DS境界ノードはDSドメインに入ります。
DS interior node a DS node that is not a DS boundary node.
DS境界ノードでないDSの内部のノードa DSノード。
DS field the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in
conformance with the definition given in
[DSFIELD]. The bits of the DSCP field
encode the DS codepoint, while the
remaining bits are currently unused.
順応で[DSFIELD]で定義を与えていて解釈されると、DSはIPv4ヘッダーTOS八重奏かIPv6 Traffic Class八重奏をさばきます。 DSCP分野のビットはDS codepointをコード化しますが、残っているビットは現在、未使用です。
DS node a DS-compliant node.
DSのノードのa DS対応することのノード。
DS region a set of contiguous DS domains which can
offer differentiated services over paths
across those DS domains.
缶の申し出が差別化した隣接のDSドメインのDS領域aセットはそれらのDSの向こう側に経路の上でドメインを修理します。
Downstream DS domain the DS domain downstream of traffic flow on
a boundary link.
境界における交通の流れのDSドメイン川下がリンクする川下のDSドメイン。
Dropper a device that performs dropping.
低下を実行する点滴器aデバイス。
Dropping the process of discarding packets based on
specified rules; policing.
捨てるパケットのプロセスを下げると、指定された規則は基づきました。 取り締まります。
Legacy node a node which implements IPv4 Precedence as
defined in [RFC791,RFC1812] but which is
otherwise not DS-compliant.
[RFC791、RFC1812]で定義されるように実装していますが、そうでなければIPv4 PrecedenceのDS対応でないレガシーノードaノード。
Marker a device that performs marking.
マークを実行するマーカーaデバイス。
Marking the process of setting the DS codepoint in
a packet based on defined rules; pre-
marking, re-marking.
ベースのパケットにDS codepointをはめ込むプロセスがオンであるとマークするのが規則を定義しました。 プレマークして、述べます。
Mechanism a specific algorithm or operation (e.g.,
queueing discipline) that is implemented in
a node to realize a set of one or more per-
hop behaviors.
1セットの1つ以上がわかるためにノードで実装されるメカニズムのa特定のアルゴリズムか操作(例えば、待ち行列規律)、-、振舞いを飛び越してください。
Blake, et. al. Informational [Page 5] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[5ページ]のRFC2475アーキテクチャ
Meter a device that performs metering.
計量を実行するデバイスを計量してください。
Metering the process of measuring the temporal
properties (e.g., rate) of a traffic stream
selected by a classifier. The
instantaneous state of this process may be
used to affect the operation of a marker,
shaper, or dropper, and/or may be used for
accounting and measurement purposes.
クラシファイアによって選択されたトラフィックストリームの時の特性(例えば、評価する)を測定するプロセスを計量します。 このプロセスの瞬時に起こっている状態は、マーカー、整形器、または点滴器の操作に影響するのに使用されるかもしれない、そして/または、会計と測定目的に使用されるかもしれません。
Microflow a single instance of an application-to-
application flow of packets which is
identified by source address, source port,
destination address, destination port and
protocol id.
アプリケーションからアプリケーションへのパケットのソースアドレス、ソースポート、送付先アドレス、仕向港、およびプロトコルイドによって特定される流動のMicroflowのaただ一つのインスタンス。
MF Classifier a multi-field (MF) classifier which selects
packets based on the content of some
arbitrary number of header fields;
typically some combination of source
address, destination address, DS field,
protocol ID, source port and destination
port.
ヘッダーフィールドの何らかの特殊活字の数字の内容に基づくパケットを選択するMF Classifier aマルチ分野(MF)クラシファイア。 通常ソースアドレスの何らかの組み合わせる、送付先アドレス、DS分野はID、ソースポート、および仕向港について議定書の中で述べます。
Per-Hop-Behavior (PHB) the externally observable forwarding
behavior applied at a DS-compliant node to
a DS behavior aggregate.
ホップの振舞いに従って、(PHB)外部的に観察可能な推進の振舞いはDS対応することのノードでDS振舞い集合に適用されました。
PHB group a set of one or more PHBs that can only be
meaningfully specified and implemented
simultaneously, due to a common constraint
applying to all PHBs in the set such as a
queue servicing or queue management policy.
A PHB group provides a service building
block that allows a set of related
forwarding behaviors to be specified
together (e.g., four dropping priorities).
A single PHB is a special case of a PHB
group.
PHBは同時に意味深長に指定して、実装することができない1PHBsのしか1セットを分類します、セットにおける、待ち行列整備点検か待ち行列経営政策などのすべてのPHBsに適用される一般的な規制のため。 PHBグループは1セットの関連する推進の振舞いが一緒に指定されるのを許容するサービスブロック(例えば、4つの低下プライオリティ)を提供します。 独身のPHBはPHBグループの特別なケースです。
Policing the process of discarding packets (by a
dropper) within a traffic stream in
accordance with the state of a
corresponding meter enforcing a traffic
profile.
対応するメーターがトラフィックプロフィールを実施する状態に従って、トラフィックストリームの中で捨てるパケットのプロセス(点滴器による)を取り締まります。
Pre-mark to set the DS codepoint of a packet prior
to entry into a downstream DS domain.
川下のDSドメインへのエントリーの前にパケットのDS codepointをセットにあらかじめマークしてください。
Blake, et. al. Informational [Page 6] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[6ページ]のRFC2475アーキテクチャ
Provider DS domain the DS-capable provider of services to a
source domain.
DSできるaに対するサービスのプロバイダーが出典を明示するプロバイダーDSドメイン、ドメイン。
Re-mark to change the DS codepoint of a packet,
usually performed by a marker in accordance
with a TCA.
TCAによると、通常、マーカーによって実行されたパケットのDS codepointを変化に述べさせてください。
Service the overall treatment of a defined subset
of a customer's traffic within a DS domain
or end-to-end.
終わりからDSドメインか終わり以内に顧客のトラフィックの定義された部分集合の総合的な処理を修理してください。
Service Level Agreement a service contract between a customer and a
(SLA) service provider that specifies the
forwarding service a customer should
receive. A customer may be a user
organization (source domain) or another DS
domain (upstream domain). A SLA may
include traffic conditioning rules which
constitute a TCA in whole or in part.
顧客と顧客が受けるべきである推進サービスを指定する(SLA)サービスプロバイダーの間でサービスが契約するLevel Agreementを調整してください。 顧客は組織(ソースドメイン)か別のDSドメイン(上流のドメイン)にユーザであるかもしれません。 SLAは全体か一部TCAを構成するトラフィック調節規則を含めるかもしれません。
Service Provisioning a policy which defines how traffic
Policy conditioners are configured on DS boundary
nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range
of services.
トラフィックPolicyコンディショナーがDS境界ノードの上でどのように構成されるか、そして、トラフィックストリームがどのようにDSの振舞いに写像されるかを定義するサービスProvisioning a方針は、さまざまなサービスを達成するために集められます。
Shaper a device that performs shaping.
形成を実行する整形器aデバイス。
Shaping the process of delaying packets within a
traffic stream to cause it to conform to
some defined traffic profile.
いくつかに従うことを引き起こすトラフィックストリームの中で延着パケットのプロセスを形成すると、トラフィックプロフィールは定義されました。
Source domain a domain which contains the node(s)
originating the traffic receiving a
particular service.
特定のサービスを受けるトラフィックを溯源しながらノードを含むドメインaドメインの出典を明示してください。
Traffic conditioner an entity which performs traffic
conditioning functions and which may
contain meters, markers, droppers, and
shapers. Traffic conditioners are typically
deployed in DS boundary nodes only. A
traffic conditioner may re-mark a traffic
stream or may discard or shape packets to
alter the temporal characteristics of the
stream and bring it into compliance with a
traffic profile.
コンディショナーを取引してください。機能を条件とさせながらトラフィックを実行して、メーター、マーカー、点滴器、および整形器を含むかもしれない実体。 トラフィックコンディショナーはDS境界ノードだけで通常配布されます。 トラフィックコンディショナーは、ストリームの時の特性を変更して、トラフィックプロフィールへの承諾にそれを運び込むようにパケットをトラフィックストリームを述べさせるか、捨てるか、または形成するかもしれません。
Blake, et. al. Informational [Page 7] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[7ページ]のRFC2475アーキテクチャ
Traffic conditioning control functions performed to enforce
rules specified in a TCA, including
metering, marking, shaping, and policing.
トラフィック調節コントロール機能は、計量して、マークして、形成して、取り締まるのを含むTCAで指定された規則を実施するために働きました。
Traffic Conditioning an agreement specifying classifier rules
Agreement (TCA) and any corresponding traffic profiles and
metering, marking, discarding and/or
shaping rules which are to apply to the
traffic streams selected by the classifier.
A TCA encompasses all of the traffic
conditioning rules explicitly specified
within a SLA along with all of the rules
implicit from the relevant service
requirements and/or from a DS domain's
service provisioning policy.
トラフィックストリームに適用することである規則をAgreement(TCA)とどんな対応するトラフィックも輪郭を描くクラシファイア規則を指定する協定と、計量して、マークして、捨てる、そして/または、形成するとクラシファイアによって選択されたトラフィックConditioning。 TCAは方針に食糧を供給しながら関連サービス要件DSドメインのサービスによる暗黙の規則のすべてに伴うSLAの中で明らかに指定されたトラフィック調節規則のすべてを取り囲みます。
Traffic profile a description of the temporal properties
of a traffic stream such as rate and burst
size.
トラフィックはレートや放出量などのトラフィックストリームの時の特性の記述の輪郭を描きます。
Traffic stream an administratively significant set of one
or more microflows which traverse a path
segment. A traffic stream may consist of
the set of active microflows which are
selected by a particular classifier.
トラフィックは経路セグメントを横断する1microflowsの行政上重要なセットを流します。 トラフィックストリームは特定のクラシファイアによって選択されるアクティブなmicroflowsのセットから成るかもしれません。
Upstream DS domain the DS domain upstream of traffic flow on a
boundary link.
境界における交通の流れのDSドメイン上流がリンクする上流のDSドメイン。
1.3 Requirements
1.3 要件
The history of the Internet has been one of continuous growth in the number of hosts, the number and variety of applications, and the capacity of the network infrastructure, and this growth is expected to continue for the foreseeable future. A scalable architecture for service differentiation must be able to accommodate this continued growth.
インターネットの歴史はアプリケーションのホストの数、数、およびバラエティーにおける絶え間ない成長、およびネットワークインフラの容量の1つです、そして、この成長は予見できる未来に続くと予測されます。 サービス分化のための拡大縮小が可能な構造はこの継続成長を収容できなければなりません。
The following requirements were identified and are addressed in this architecture:
以下の要件は、特定されて、このアーキテクチャで扱われます:
o should accommodate a wide variety of services and provisioning
policies, extending end-to-end or within a particular (set of)
network(s),
o 終わりから終わりか特定(セットされる)のネットワークの中で広がっていて、さまざまなサービスと食糧を供給する方針に対応するべきです。
o should allow decoupling of the service from the particular
application in use,
o 使用中の特定用途から衝撃を吸収するのをサービスを許すべきです。
Blake, et. al. Informational [Page 8] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[8ページ]のRFC2475アーキテクチャ
o should work with existing applications without the need for
application programming interface changes or host software
modifications (assuming suitable deployment of classifiers,
markers, and other traffic conditioning functions),
o アプリケーションの必要性のない既存のアプリケーションがプログラムを作っている仕事は変化かホストソフトウェア変更(機能を条件とさせるクラシファイア、マーカー、および他のトラフィックの適当な展開を仮定する)を連結するべきです。
o should decouple traffic conditioning and service provisioning
functions from forwarding behaviors implemented within the core
network nodes,
o コアネットワーク・ノードの中で実装された推進の振舞いから機能に食糧を供給するトラフィック調節とサービスの衝撃を吸収するべきです。
o should not depend on hop-by-hop application signaling,
o ホップごとのアプリケーションシグナリングによるべきではありません。
o should require only a small set of forwarding behaviors whose
implementation complexity does not dominate the cost of a network
device, and which will not introduce bottlenecks for future high-
speed system implementations,
o 実装の複雑さがネットワークデバイスの費用を支配しないで、また今後の高い速度システムの実現のためにボトルネックを導入しない推進の振舞いを小さいセットだけに要求するべきです。
o should avoid per-microflow or per-customer state within core
network nodes,
o コアネットワーク・ノードの中でmicroflowか顧客あたりの状態を避けるべきです。
o should utilize only aggregated classification state within the
network core,
o ネットワークコアの中で集められた分類状態だけを利用するべきです。
o should permit simple packet classification implementations in core
network nodes (BA classifier),
o コアネットワーク・ノード(BAクラシファイア)の簡単なパケット分類実装を可能にするべきです。
o should permit reasonable interoperability with non-DS-compliant
network nodes,
o 妥当な相互運用性を可能にするべきである、非DS対応する、ノードをネットワークでつないでください。
o should accommodate incremental deployment.
o 増加の展開を収容するべきです。
1.4 Comparisons with Other Approaches
1.4 他のアプローチとの比較
The differentiated services architecture specified in this document can be contrasted with other existing models of service differentiation. We classify these alternative models into the following categories: relative priority marking, service marking, label switching, Integrated Services/RSVP, and static per-hop classification.
本書では指定された差別化されたサービスアーキテクチャはサービス分化の他の既存のモデルに対して対照できます。 私たちはこれらの代替のモデルを以下のカテゴリに分類します: 相対的な優先権マーク、標記は切り換え、Integrated Services/RSVP、および1ホップあたりの静的な分類をラベルします。
Examples of the relative priority marking model include IPv4 Precedence marking as defined in [RFC791], 802.5 Token Ring priority [TR], and the default interpretation of 802.1p traffic classes [802.1p]. In this model the application, host, or proxy node selects a relative priority or "precedence" for a packet (e.g., delay or discard priority), and the network nodes along the transit path apply the appropriate priority forwarding behavior corresponding to the priority value within the packet's header. Our architecture can be considered as a refinement to this model, since we more clearly
モデルをマークする相対的な優先権に関する例は802.1pトラフィックのクラス[802.1p]の[RFC791]、802.5Token Ring優先権[TR]、およびデフォルト解釈で定義されるようにIPv4 Precedenceマークを含んでいます。 このモデルでは、アプリケーション、ホスト、またはプロキシノードがパケットのための相対的な優先権か「先行」を選択します、そして、(例えば、優先権を遅らせるか、または捨ててください)トランジット経路に沿ったネットワーク・ノードはパケットのヘッダーの中に優先順位の値に対応する振舞いを進めながら、適切な優先権を当てはまります。 以来にこのモデルへの気品であると私たちのアーキテクチャをみなすことができる、私たち、 より明確に。
Blake, et. al. Informational [Page 9] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[9ページ]のRFC2475アーキテクチャ
specify the role and importance of boundary nodes and traffic conditioners, and since our per-hop behavior model permits more general forwarding behaviors than relative delay or discard priority.
境界ノードとトラフィックコンディショナーの役割と重要性を指定してください、私たちの1ホップあたりの振舞いモデルが親類より一般的な推進の振舞いを可能にするので、優先権を遅らせるか、または捨ててください。
An example of a service marking model is IPv4 TOS as defined in [RFC1349]. In this example each packet is marked with a request for a "type of service", which may include "minimize delay", "maximize throughput", "maximize reliability", or "minimize cost". Network nodes may select routing paths or forwarding behaviors which are suitably engineered to satisfy the service request. This model is subtly different from our architecture. Note that we do not describe the use of the DS field as an input to route selection. The TOS markings defined in [RFC1349] are very generic and do not span the range of possible service semantics. Furthermore, the service request is associated with each individual packet, whereas some service semantics may depend on the aggregate forwarding behavior of a sequence of packets. The service marking model does not easily accommodate growth in the number and range of future services (since the codepoint space is small) and involves configuration of the "TOS->forwarding behavior" association in each core network node. Standardizing service markings implies standardizing service offerings, which is outside the scope of the IETF. Note that provisions are made in the allocation of the DS codepoint space to allow for locally significant codepoints which may be used by a provider to support service marking semantics [DSFIELD].
標記モデルに関する例は[RFC1349]で定義されるようにIPv4 TOSです。 この例では、各パケットは「サービスのタイプ」を求める要求でマークされます。(それは、「遅れを最小にしてください」を含んでいるか、「スループットを最大にする」か、「信頼性を最大にする」か、または「費用を最小にするかもしれません」)。 ネットワーク・ノードはサービスのリクエストを満たすために適当に設計されるルーティング経路か推進の振舞いを選択するかもしれません。 このモデルは私たちのアーキテクチャとかすかに異なっています。 私たちが選択を発送するためにDS分野の使用を入力として記述しないことに注意してください。 [RFC1349]で定義されたTOS印は、まさしくそのジェネリックであり、可能なサービス意味論の範囲にわたりません。 その上、サービスのリクエストはそれぞれの個々のパケットに関連していますが、何らかのサービス意味論がパケットの系列の集合推進の振舞いによるかもしれません。 標記モデルが将来、サービス(codepointスペースが小さいので)の数と範囲で容易に成長に対応しないで、構成にかかわる、「TOS->が進められる、」 それぞれの協会が芯を取る振舞いはノードをネットワークでつなぎます。 標記を標準化するのは、標準化して、提供を調整するように含意します(IETFの範囲の外にあります)。 条項は、DS codepointスペースの配分でプロバイダーによって使用されるかもしれない重要なcodepointsが、標記が意味論[DSFIELD]であるとサポートするのが局所的に許容させられることに注意してください。
Examples of the label switching (or virtual circuit) model include Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path at an ingress node, and packets/cells within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop. This model permits finer granularity resource allocation to traffic streams, since label values are not globally significant but are only significant on a single link; therefore resources can be reserved for the aggregate of packets/ cells received on a link with a particular label, and the label switching semantics govern the next-hop selection, allowing a traffic stream to follow a specially engineered path through the network. This improved granularity comes at the cost of additional management and configuration requirements to establish and maintain the label switched paths. In addition, the amount of forwarding state maintained at each node scales in proportion to the number of edge nodes of the network in the best case (assuming multipoint-to-point
Examples of the label switching (or virtual circuit) model include Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path at an ingress node, and packets/cells within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop. This model permits finer granularity resource allocation to traffic streams, since label values are not globally significant but are only significant on a single link; therefore resources can be reserved for the aggregate of packets/ cells received on a link with a particular label, and the label switching semantics govern the next-hop selection, allowing a traffic stream to follow a specially engineered path through the network. This improved granularity comes at the cost of additional management and configuration requirements to establish and maintain the label switched paths. In addition, the amount of forwarding state maintained at each node scales in proportion to the number of edge nodes of the network in the best case (assuming multipoint-to-point
Blake, et. al. Informational [Page 10] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 10] RFC 2475 Architecture for Differentiated Services December 1998
label switched paths), and it scales in proportion with the square of the number of edge nodes in the worst case, when edge-edge label switched paths with provisioned resources are employed.
label switched paths), and it scales in proportion with the square of the number of edge nodes in the worst case, when edge-edge label switched paths with provisioned resources are employed.
The Integrated Services/RSVP model relies upon traditional datagram forwarding in the default case, but allows sources and receivers to exchange signaling messages which establish additional packet classification and forwarding state on each node along the path between them [RFC1633, RSVP]. In the absence of state aggregation, the amount of state on each node scales in proportion to the number of concurrent reservations, which can be potentially large on high- speed links. This model also requires application support for the RSVP signaling protocol. Differentiated services mechanisms can be utilized to aggregate Integrated Services/RSVP state in the core of the network [Bernet].
The Integrated Services/RSVP model relies upon traditional datagram forwarding in the default case, but allows sources and receivers to exchange signaling messages which establish additional packet classification and forwarding state on each node along the path between them [RFC1633, RSVP]. In the absence of state aggregation, the amount of state on each node scales in proportion to the number of concurrent reservations, which can be potentially large on high- speed links. This model also requires application support for the RSVP signaling protocol. Differentiated services mechanisms can be utilized to aggregate Integrated Services/RSVP state in the core of the network [Bernet].
A variant of the Integrated Services/RSVP model eliminates the requirement for hop-by-hop signaling by utilizing only "static" classification and forwarding policies which are implemented in each node along a network path. These policies are updated on administrative timescales and not in response to the instantaneous mix of microflows active in the network. The state requirements for this variant are potentially worse than those encountered when RSVP is used, especially in backbone nodes, since the number of static policies that might be applicable at a node over time may be larger than the number of active sender-receiver sessions that might have installed reservation state on a node. Although the support of large numbers of classifier rules and forwarding policies may be computationally feasible, the management burden associated with installing and maintaining these rules on each node within a backbone network which might be traversed by a traffic stream is substantial.
A variant of the Integrated Services/RSVP model eliminates the requirement for hop-by-hop signaling by utilizing only "static" classification and forwarding policies which are implemented in each node along a network path. These policies are updated on administrative timescales and not in response to the instantaneous mix of microflows active in the network. The state requirements for this variant are potentially worse than those encountered when RSVP is used, especially in backbone nodes, since the number of static policies that might be applicable at a node over time may be larger than the number of active sender-receiver sessions that might have installed reservation state on a node. Although the support of large numbers of classifier rules and forwarding policies may be computationally feasible, the management burden associated with installing and maintaining these rules on each node within a backbone network which might be traversed by a traffic stream is substantial.
Although we contrast our architecture with these alternative models of service differentiation, it should be noted that links and nodes employing these techniques may be utilized to extend differentiated services behaviors and semantics across a layer-2 switched infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones) interconnecting DS nodes, and in the case of MPLS may be used as an alternative intra-domain implementation technology. The constraints imposed by the use of a specific link-layer technology in particular regions of a DS domain (or in a network providing access to DS domains) may imply the differentiation of traffic on a coarser grain basis. Depending on the mapping of PHBs to different link-layer services and the way in which packets are scheduled over a restricted set of priority classes (or virtual circuits of different category and capacity), all or a subset of the PHBs in use may be supportable (or may be indistinguishable).
Although we contrast our architecture with these alternative models of service differentiation, it should be noted that links and nodes employing these techniques may be utilized to extend differentiated services behaviors and semantics across a layer-2 switched infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones) interconnecting DS nodes, and in the case of MPLS may be used as an alternative intra-domain implementation technology. The constraints imposed by the use of a specific link-layer technology in particular regions of a DS domain (or in a network providing access to DS domains) may imply the differentiation of traffic on a coarser grain basis. Depending on the mapping of PHBs to different link-layer services and the way in which packets are scheduled over a restricted set of priority classes (or virtual circuits of different category and capacity), all or a subset of the PHBs in use may be supportable (or may be indistinguishable).
Blake, et. al. Informational [Page 11] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 11] RFC 2475 Architecture for Differentiated Services December 1998
2. Differentiated Services Architectural Model
2. Differentiated Services Architectural Model
The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DS codepoint. Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DS codepoint. In this section, we discuss the key components within a differentiated services region, traffic classification and conditioning functions, and how differentiated services are achieved through the combination of traffic conditioning and PHB-based forwarding.
The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DS codepoint. Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DS codepoint. In this section, we discuss the key components within a differentiated services region, traffic classification and conditioning functions, and how differentiated services are achieved through the combination of traffic conditioning and PHB-based forwarding.
2.1 Differentiated Services Domain
2.1 Differentiated Services Domain
A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB groups implemented on each node. A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain. Nodes within the DS domain select the forwarding behavior for packets based on their DS codepoint, mapping that value to one of the supported PHBs using either the recommended codepoint->PHB mapping or a locally customized mapping [DSFIELD]. Inclusion of non-DS-compliant nodes within a DS domain may result in unpredictable performance and may impede the ability to satisfy service level agreements (SLAs).
A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB groups implemented on each node. A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain. Nodes within the DS domain select the forwarding behavior for packets based on their DS codepoint, mapping that value to one of the supported PHBs using either the recommended codepoint->PHB mapping or a locally customized mapping [DSFIELD]. Inclusion of non-DS-compliant nodes within a DS domain may result in unpredictable performance and may impede the ability to satisfy service level agreements (SLAs).
A DS domain normally consists of one or more networks under the same administration; for example, an organization's intranet or an ISP. The administration of the domain is responsible for ensuring that adequate resources are provisioned and/or reserved to support the SLAs offered by the domain.
A DS domain normally consists of one or more networks under the same administration; for example, an organization's intranet or an ISP. The administration of the domain is responsible for ensuring that adequate resources are provisioned and/or reserved to support the SLAs offered by the domain.
2.1.1 DS Boundary Nodes and Interior Nodes
2.1.1 DS Boundary Nodes and Interior Nodes
A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS- capable domains, whilst DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain.
A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS- capable domains, whilst DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain.
Both DS boundary nodes and interior nodes must be able to apply the appropriate PHB to packets based on the DS codepoint; otherwise unpredictable behavior may result. In addition, DS boundary nodes may be required to perform traffic conditioning functions as defined by a traffic conditioning agreement (TCA) between their DS domain and
Both DS boundary nodes and interior nodes must be able to apply the appropriate PHB to packets based on the DS codepoint; otherwise unpredictable behavior may result. In addition, DS boundary nodes may be required to perform traffic conditioning functions as defined by a traffic conditioning agreement (TCA) between their DS domain and
Blake, et. al. Informational [Page 12] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 12] RFC 2475 Architecture for Differentiated Services December 1998
the peering domain which they connect to (see Sec. 2.3.3).
the peering domain which they connect to (see Sec. 2.3.3).
Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint re-marking. Interior nodes which implement more complex classification and traffic conditioning functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint re-marking. Interior nodes which implement more complex classification and traffic conditioning functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
A host in a network containing a DS domain may act as a DS boundary node for traffic from applications running on that host; we therefore say that the host is within the DS domain. If a host does not act as a boundary node, then the DS node topologically closest to that host acts as the DS boundary node for that host's traffic.
A host in a network containing a DS domain may act as a DS boundary node for traffic from applications running on that host; we therefore say that the host is within the DS domain. If a host does not act as a boundary node, then the DS node topologically closest to that host acts as the DS boundary node for that host's traffic.
2.1.2 DS Ingress Node and Egress Node
2.1.2 DS Ingress Node and Egress Node
DS boundary nodes act both as a DS ingress node and as a DS egress node for different directions of traffic. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains. Note that a DS boundary node may act as a DS interior node for some set of interfaces.
DS boundary nodes act both as a DS ingress node and as a DS egress node for different directions of traffic. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains. Note that a DS boundary node may act as a DS interior node for some set of interfaces.
2.2 Differentiated Services Region
2.2 Differentiated Services Region
A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths which span the domains within the region.
A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths which span the domains within the region.
The DS domains in a DS region may support different PHB groups internally and different codepoint->PHB mappings. However, to permit services which span across the domains, the peering DS domains must each establish a peering SLA which defines (either explicitly or implicitly) a TCA which specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains.
The DS domains in a DS region may support different PHB groups internally and different codepoint->PHB mappings. However, to permit services which span across the domains, the peering DS domains must each establish a peering SLA which defines (either explicitly or implicitly) a TCA which specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains.
It is possible that several DS domains within a DS region may adopt a common service provisioning policy and may support a common set of PHB groups and codepoint mappings, thus eliminating the need for traffic conditioning between those DS domains.
It is possible that several DS domains within a DS region may adopt a common service provisioning policy and may support a common set of PHB groups and codepoint mappings, thus eliminating the need for traffic conditioning between those DS domains.
Blake, et. al. Informational [Page 13] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 13] RFC 2475 Architecture for Differentiated Services December 1998
2.3 Traffic Classification and Conditioning
2.3 Traffic Classification and Conditioning
Differentiated services are extended across a DS domain boundary by establishing a SLA between an upstream network and a downstream DS domain. The SLA may specify packet classification and re-marking rules and may also specify traffic profiles and actions to traffic streams which are in- or out-of-profile (see Sec. 2.3.2). The TCA between the domains is derived (explicitly or implicitly) from this SLA.
Differentiated services are extended across a DS domain boundary by establishing a SLA between an upstream network and a downstream DS domain. The SLA may specify packet classification and re-marking rules and may also specify traffic profiles and actions to traffic streams which are in- or out-of-profile (see Sec. 2.3.2). The TCA between the domains is derived (explicitly or implicitly) from this SLA.
The packet classification policy identifies the subset of traffic which may receive a differentiated service by being conditioned and/ or mapped to one or more behavior aggregates (by DS codepoint re- marking) within the DS domain.
The packet classification policy identifies the subset of traffic which may receive a differentiated service by being conditioned and/ or mapped to one or more behavior aggregates (by DS codepoint re- marking) within the DS domain.
Traffic conditioning performs metering, shaping, policing and/or re- marking to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy. The extent of traffic conditioning required is dependent on the specifics of the service offering, and may range from simple codepoint re-marking to complex policing and shaping operations. The details of traffic conditioning policies which are negotiated between networks is outside the scope of this document.
Traffic conditioning performs metering, shaping, policing and/or re- marking to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy. The extent of traffic conditioning required is dependent on the specifics of the service offering, and may range from simple codepoint re-marking to complex policing and shaping operations. The details of traffic conditioning policies which are negotiated between networks is outside the scope of this document.
2.3.1 Classifiers
2.3.1 Classifiers
Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header. We define two types of classifiers. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface.
Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header. We define two types of classifiers. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface.
Classifiers are used to "steer" packets matching some specified rule to an element of a traffic conditioner for further processing. Classifiers must be configured by some management procedure in accordance with the appropriate TCA.
Classifiers are used to "steer" packets matching some specified rule to an element of a traffic conditioner for further processing. Classifiers must be configured by some management procedure in accordance with the appropriate TCA.
The classifier should authenticate the information which it uses to classify the packet (see Sec. 6).
The classifier should authenticate the information which it uses to classify the packet (see Sec. 6).
Note that in the event of upstream packet fragmentation, MF classifiers which examine the contents of transport-layer header fields may incorrectly classify packet fragments subsequent to the first. A possible solution to this problem is to maintain
Note that in the event of upstream packet fragmentation, MF classifiers which examine the contents of transport-layer header fields may incorrectly classify packet fragments subsequent to the first. A possible solution to this problem is to maintain
Blake, et. al. Informational [Page 14] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 14] RFC 2475 Architecture for Differentiated Services December 1998
fragmentation state; however, this is not a general solution due to the possibility of upstream fragment re-ordering or divergent routing paths. The policy to apply to packet fragments is outside the scope of this document.
fragmentation state; however, this is not a general solution due to the possibility of upstream fragment re-ordering or divergent routing paths. The policy to apply to packet fragments is outside the scope of this document.
2.3.2 Traffic Profiles
2.3.2 Traffic Profiles
A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile. For example, a profile based on a token bucket may look like:
A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile. For example, a profile based on a token bucket may look like:
codepoint=X, use token-bucket r, b
codepoint=X, use token-bucket r, b
The above profile indicates that all packets marked with DS codepoint X should be measured against a token bucket meter with rate r and burst size b. In this example out-of-profile packets are those packets in the traffic stream which arrive when insufficient tokens are available in the bucket. The concept of in- and out-of-profile can be extended to more than two levels, e.g., multiple levels of conformance with a profile may be defined and enforced.
The above profile indicates that all packets marked with DS codepoint X should be measured against a token bucket meter with rate r and burst size b. In this example out-of-profile packets are those packets in the traffic stream which arrive when insufficient tokens are available in the bucket. The concept of in- and out-of-profile can be extended to more than two levels, e.g., multiple levels of conformance with a profile may be defined and enforced.
Different conditioning actions may be applied to the in-profile packets and out-of-profile packets, or different accounting actions may be triggered. In-profile packets may be allowed to enter the DS domain without further conditioning; or, alternatively, their DS codepoint may be changed. The latter happens when the DS codepoint is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group or codepoint->PHB mapping policy for this traffic stream. Out-of- profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure. Out-of-profile packets may be mapped to one or more behavior aggregates that are "inferior" in some dimension of forwarding performance to the BA into which in-profile packets are mapped.
Different conditioning actions may be applied to the in-profile packets and out-of-profile packets, or different accounting actions may be triggered. In-profile packets may be allowed to enter the DS domain without further conditioning; or, alternatively, their DS codepoint may be changed. The latter happens when the DS codepoint is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group or codepoint->PHB mapping policy for this traffic stream. Out-of- profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure. Out-of-profile packets may be mapped to one or more behavior aggregates that are "inferior" in some dimension of forwarding performance to the BA into which in-profile packets are mapped.
Note that a traffic profile is an optional component of a TCA and its use is dependent on the specifics of the service offering and the domain's service provisioning policy.
Note that a traffic profile is an optional component of a TCA and its use is dependent on the specifics of the service offering and the domain's service provisioning policy.
2.3.3 Traffic Conditioners
2.3.3 Traffic Conditioners
A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter
A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter
Blake, et. al. Informational [Page 15] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 15] RFC 2475 Architecture for Differentiated Services December 1998
with respect to a particular packet (e.g., whether it is in- or out- of-profile) may be used to affect a marking, dropping, or shaping action.
with respect to a particular packet (e.g., whether it is in- or out- of-profile) may be used to affect a marking, dropping, or shaping action.
When packets exit the traffic conditioner of a DS boundary node the DS codepoint of each packet must be set to an appropriate value.
When packets exit the traffic conditioner of a DS boundary node the DS codepoint of each packet must be set to an appropriate value.
Fig. 1 shows the block diagram of a classifier and traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, in the case where no traffic profile is in effect, packets may only pass through a classifier and a marker.
Fig. 1 shows the block diagram of a classifier and traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, in the case where no traffic profile is in effect, packets may only pass through a classifier and a marker.
+-------+
| |-------------------+
+----->| Meter | |
| | |--+ |
| +-------+ | |
| V V
+------------+ +--------+ +---------+
| | | | | Shaper/ |
packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
| | | | | |
+------------+ +--------+ +---------+
+-------+ | |-------------------+ +----->| Meter | | | | |--+ | | +-------+ | | | V V +------------+ +--------+ +---------+ | | | | | Shaper/ | packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====> | | | | | | +------------+ +--------+ +---------+
Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner
Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner
2.3.3.1 Meters
2.3.3.1 Meters
Traffic meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile specified in a TCA. A meter passes state information to other conditioning functions to trigger a particular action for each packet which is either in- or out-of-profile (to some extent).
Traffic meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile specified in a TCA. A meter passes state information to other conditioning functions to trigger a particular action for each packet which is either in- or out-of-profile (to some extent).
2.3.3.2 Markers
2.3.3.2 Markers
Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet.
Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet.
Blake, et. al. Informational [Page 16] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 16] RFC 2475 Architecture for Differentiated Services December 1998
2.3.3.3 Shapers
2.3.3.3 Shapers
Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets.
Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets.
2.3.3.4 Droppers
2.3.3.4 Droppers
Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is know as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets.
Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is know as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets.
2.3.4 Location of Traffic Conditioners and MF Classifiers
2.3.4 Location of Traffic Conditioners and MF Classifiers
Traffic conditioners are usually located within DS ingress and egress boundary nodes, but may also be located in nodes within the interior of a DS domain, or within a non-DS-capable domain.
Traffic conditioners are usually located within DS ingress and egress boundary nodes, but may also be located in nodes within the interior of a DS domain, or within a non-DS-capable domain.
2.3.4.1 Within the Source Domain
2.3.4.1 Within the Source Domain
We define the source domain as the domain containing the node(s) which originate the traffic receiving a particular service. Traffic sources and intermediate nodes within a source domain may perform traffic classification and conditioning functions. The traffic originating from the source domain across a boundary may be marked by the traffic sources directly or by intermediate nodes before leaving the source domain. This is referred to as initial marking or "pre- marking".
We define the source domain as the domain containing the node(s) which originate the traffic receiving a particular service. Traffic sources and intermediate nodes within a source domain may perform traffic classification and conditioning functions. The traffic originating from the source domain across a boundary may be marked by the traffic sources directly or by intermediate nodes before leaving the source domain. This is referred to as initial marking or "pre- marking".
Consider the example of a company that has the policy that its CEO's packets should have higher priority. The CEO's host may mark the DS field of all outgoing packets with a DS codepoint that indicates "higher priority". Alternatively, the first-hop router directly connected to the CEO's host may classify the traffic and mark the CEO's packets with the correct DS codepoint. Such high priority traffic may also be conditioned near the source so that there is a limit on the amount of high priority traffic forwarded from a particular source.
Consider the example of a company that has the policy that its CEO's packets should have higher priority. The CEO's host may mark the DS field of all outgoing packets with a DS codepoint that indicates "higher priority". Alternatively, the first-hop router directly connected to the CEO's host may classify the traffic and mark the CEO's packets with the correct DS codepoint. Such high priority traffic may also be conditioned near the source so that there is a limit on the amount of high priority traffic forwarded from a particular source.
There are some advantages to marking packets close to the traffic source. First, a traffic source can more easily take an application's preferences into account when deciding which packets should receive better forwarding treatment. Also, classification of
There are some advantages to marking packets close to the traffic source. First, a traffic source can more easily take an application's preferences into account when deciding which packets should receive better forwarding treatment. Also, classification of
Blake, et. al. Informational [Page 17] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 17] RFC 2475 Architecture for Differentiated Services December 1998
packets is much simpler before the traffic has been aggregated with packets from other sources, since the number of classification rules which need to be applied within a single node is reduced.
packets is much simpler before the traffic has been aggregated with packets from other sources, since the number of classification rules which need to be applied within a single node is reduced.
Since packet marking may be distributed across multiple nodes, the source DS domain is responsible for ensuring that the aggregated traffic towards its provider DS domain conforms to the appropriate TCA. Additional allocation mechanisms such as bandwidth brokers or RSVP may be used to dynamically allocate resources for a particular DS behavior aggregate within the provider's network [2BIT, Bernet]. The boundary node of the source domain should also monitor conformance to the TCA, and may police, shape, or re-mark packets as necessary.
Since packet marking may be distributed across multiple nodes, the source DS domain is responsible for ensuring that the aggregated traffic towards its provider DS domain conforms to the appropriate TCA. Additional allocation mechanisms such as bandwidth brokers or RSVP may be used to dynamically allocate resources for a particular DS behavior aggregate within the provider's network [2BIT, Bernet]. The boundary node of the source domain should also monitor conformance to the TCA, and may police, shape, or re-mark packets as necessary.
2.3.4.2 At the Boundary of a DS Domain
2.3.4.2 At the Boundary of a DS Domain
Traffic streams may be classified, marked, and otherwise conditioned on either end of a boundary link (the DS egress node of the upstream domain or the DS ingress node of the downstream domain). The SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA. However, a DS ingress node must assume that the incoming traffic may not conform to the TCA and must be prepared to enforce the TCA in accordance with local policy.
Traffic streams may be classified, marked, and otherwise conditioned on either end of a boundary link (the DS egress node of the upstream domain or the DS ingress node of the downstream domain). The SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA. However, a DS ingress node must assume that the incoming traffic may not conform to the TCA and must be prepared to enforce the TCA in accordance with local policy.
When packets are pre-marked and conditioned in the upstream domain, potentially fewer classification and traffic conditioning rules need to be supported in the downstream DS domain. In this circumstance the downstream DS domain may only need to re-mark or police the incoming behavior aggregates to enforce the TCA. However, more sophisticated services which are path- or source-dependent may require MF classification in the downstream DS domain's ingress nodes.
When packets are pre-marked and conditioned in the upstream domain, potentially fewer classification and traffic conditioning rules need to be supported in the downstream DS domain. In this circumstance the downstream DS domain may only need to re-mark or police the incoming behavior aggregates to enforce the TCA. However, more sophisticated services which are path- or source-dependent may require MF classification in the downstream DS domain's ingress nodes.
If a DS ingress node is connected to an upstream non-DS-capable domain, the DS ingress node must be able to perform all necessary traffic conditioning functions on the incoming traffic.
If a DS ingress node is connected to an upstream non-DS-capable domain, the DS ingress node must be able to perform all necessary traffic conditioning functions on the incoming traffic.
2.3.4.3 In non-DS-Capable Domains
2.3.4.3 In non-DS-Capable Domains
Traffic sources or intermediate nodes in a non-DS-capable domain may employ traffic conditioners to pre-mark traffic before it reaches the ingress of a downstream DS domain. In this way the local policies for classification and marking may be concealed.
Traffic sources or intermediate nodes in a non-DS-capable domain may employ traffic conditioners to pre-mark traffic before it reaches the ingress of a downstream DS domain. In this way the local policies for classification and marking may be concealed.
Blake, et. al. Informational [Page 18] RFC 2475 Architecture for Differentiated Services December 1998
Blake, et. al. Informational [Page 18] RFC 2475 Architecture for Differentiated Services December 1998
2.3.4.4 In Interior DS Nodes
2.3.4.4 In Interior DS Nodes
Although the basic architecture assumes that complex classification and traffic conditioning functions are located only in a network's ingress and egress boundary nodes, deployment of these functions in the interior of the network is not precluded. For example, more restrictive access policies may be enforced on a transoceanic link, requiring MF classification and traffic conditioning functionality in the upstream node on the link. This approach may have scaling limits, due to the potentially large number of classification and conditioning rules that might need to be maintained.
Although the basic architecture assumes that complex classification and traffic conditioning functions are located only in a network's ingress and egress boundary nodes, deployment of these functions in the interior of the network is not precluded. For example, more restrictive access policies may be enforced on a transoceanic link, requiring MF classification and traffic conditioning functionality in the upstream node on the link. This approach may have scaling limits, due to the potentially large number of classification and conditioning rules that might need to be maintained.
2.4 Per-Hop Behaviors
2.4 Per-Hop Behaviors
A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a general concept in this context. For example, in the event that only one behavior aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will often depend only on the relative loading of the link (i.e., in the event that the behavior assumes a work- conserving scheduling discipline). Useful behavioral distinctions are mainly observed when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed.
A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a general concept in this context. For example, in the event that only one behavior aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will often depend only on the relative loading of the link (i.e., in the event that the behavior assumes a work- conserving scheduling discipline). Useful behavioral distinctions are mainly observed when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed.
The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured under a variety of competing traffic conditions. A slightly more complex PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity. In general, the observable behavior of a PHB may depend on certain constraints on the traffic characteristics of the associated behavior aggregate, or the characteristics of other behavior aggregates.
The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured under a variety of competing traffic conditions. A slightly more complex PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity. In general, the observable behavior of a PHB may depend on certain constraints on the traffic characteristics of the associated behavior aggregate, or the characteristics of other behavior aggregates.
PHBs may be specified in terms of their resource (e.g., buffer, bandwidth) priority relative to other PHBs, or in terms of their relative observable traffic characteristics (e.g., delay, loss). These PHBs may be used as building blocks to allocate resources and should be specified as a group (PHB group) for consistency. PHB groups will usually share a common constraint applying to each PHB within the group, such as a packet scheduling or buffer management policy. The relationship between PHBs in a group may be in terms of absolute or relative priority (e.g., discard priority by means of
PHBsは他のPHBsに比例した彼らの相対的な観察可能な交通の特性(例えば、遅れ、損失)に関して彼らのリソース(例えば、バッファ、帯域幅)優先権で指定されるかもしれません。 これらのPHBsはリソースを割り当てるのにブロックとして使用されるかもしれなくて、グループとして一貫性に指定されるべきです(PHBは分類します)。 通常、PHBグループはグループの中の各PHBに適用される一般的な規制を共有するでしょう、パケットスケジューリングやバッファ経営政策のように。 による絶対の、または、相対的な優先権に関してグループにおけるPHBsの間の関係があるかもしれない、(例えば、優先権を捨ててください。
Blake, et. al. Informational [Page 19] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[19ページ]のRFC2475構造
deterministic or stochastic thresholds), but this is not required (e.g., N equal link shares). A single PHB defined in isolation is a special case of a PHB group.
決定論的であるか推計的な敷居)、これだけは必要ではありません(例えば、N等しいリンクシェア)。 分離して定義された独身のPHBはPHBグループの特別なケースです。
PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms. PHBs are defined in terms of behavior characteristics relevant to service provisioning policies, and not in terms of particular implementation mechanisms. In general, a variety of implementation mechanisms may be suitable for implementing a particular PHB group. Furthermore, it is likely that more than one PHB group may be implemented on a node and utilized within a domain. PHB groups should be defined such that the proper resource allocation between groups can be inferred, and integrated mechanisms can be implemented which can simultaneously support two or more groups. A PHB group definition should indicate possible conflicts with previously documented PHB groups which might prevent simultaneous operation.
PHBsは何らかのバッファ管理によってノードで実行されます、そして、パケットスケジューリングメカニズムPHBsは特定の実現メカニズムで定義されるのではなく、方針に食糧を供給するサービスに関連している振舞いの特性で定義されます。一般に、さまざまな実現メカニズムが特定のPHBグループを実行するのに適当であるかもしれません。 その上、1つ以上のPHBグループが、ノードの上で実行されて、ドメインの中で利用されそうです。 グループの間の適切な資源配分を推論できるようにPHBグループを定義するべきです、そして、同時に2つ以上のグループを支持できる統合メカニズムは実行できます。 PHBグループ定義は同時処理操作を防ぐかもしれない以前に記録されたPHBグループとの可能な闘争を示すべきです。
As described in [DSFIELD], a PHB is selected at a node by a mapping of the DS codepoint in a received packet. Standardized PHBs have a recommended codepoint. However, the total space of codepoints is larger than the space available for recommended codepoints for standardized PHBs, and [DSFIELD] leaves provisions for locally configurable mappings. A codepoint->PHB mapping table may contain both 1->1 and N->1 mappings. All codepoints must be mapped to some PHB; in the absence of some local policy, codepoints which are not mapped to a standardized PHB in accordance with that PHB's specification should be mapped to the Default PHB.
[DSFIELD]で説明されるように、PHBは容認されたパケットでノードでDS codepointに関するマッピングによって選択されます。 標準化されたPHBsには、お勧めのcodepointがあります。 しかしながら、codepointsの総スペースは標準化されたPHBsに、お勧めのcodepointsに利用可能なスペースより大きいです、そして、[DSFIELD]は局所的に構成可能なマッピングのための条項を残します。 PHBマッピングがテーブルの上に置くcodepoint->は両方の1>の1とN>の1マッピングを含むかもしれません。 すべてのcodepointsをいくらかのPHBに写像しなければなりません。 何らかのローカルの方針がないとき、そのPHBの仕様通りに標準化されたPHBに写像されないcodepointsはDefault PHBに写像されるべきです。
2.5 Network Resource Allocation
2.5 ネットワーク資源配分
The implementation, configuration, operation and administration of the supported PHB groups in the nodes of a DS Domain should effectively partition the resources of those nodes and the inter-node links between behavior aggregates, in accordance with the domain's service provisioning policy. Traffic conditioners can further control the usage of these resources through enforcement of TCAs and possibly through operational feedback from the nodes and traffic conditioners in the domain. Although a range of services can be deployed in the absence of complex traffic conditioning functions (e.g., using only static marking policies), functions such as policing, shaping, and dynamic re-marking enable the deployment of services providing quantitative performance metrics.
事実上、DS Domainのノードの支持されたPHBグループの実現、構成、操作、および管理はそれらのノードに関するリソースと振舞い集合の間の節間リンクを仕切るべきです、ドメインのサービス食糧を供給する方針によると。 交通コンディショナーはそのドメインでノードと交通コンディショナーからTCAsの実施を通してことによると操作上のフィードバックを通してこれらのリソースの用法をさらに制御できます。 複雑な交通調節機能(例えば、方針をマークする静電気だけを使用する)がないときさまざまなサービスを配備できますが、取り締まりや、形成や、ダイナミックな異状などの機能は量的な性能測定基準を提供するサービスの展開を可能にします。
The configuration of and interaction between traffic conditioners and interior nodes should be managed by the administrative control of the domain and may require operational control through protocols and a control entity. There is a wide range of possible control models.
そして、構成、交通コンディショナーと内部のノードとの相互作用は、ドメインの運営管理コントロールで管理されるべきであり、プロトコルとコントロール実体を通して運用統制を必要とするかもしれません。 さまざまな可能な規制モデルがあります。
Blake, et. al. Informational [Page 20] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[20ページ]のRFC2475構造
The precise nature and implementation of the interaction between these components is outside the scope of this architecture. However, scalability requires that the control of the domain does not require micro-management of the network resources. The most scalable control model would operate nodes in open-loop in the operational timeframe, and would only require administrative-timescale management as SLAs are varied. This simple model may be unsuitable in some circumstances, and some automated but slowly varying operational control (minutes rather than seconds) may be desirable to balance the utilization of the network against the recent load profile.
この構造の範囲の外にこれらのコンポーネントの間の相互作用の正確な自然と実現があります。 しかしながら、スケーラビリティは、ドメインのコントロールがネットワーク資源のマイクロマネージメントを必要としないのを必要とします。 最もスケーラブルな規制モデルは、操作上の時間枠の転々流通でノードを操作して、SLAが様々であるときに、管理スケール管理を必要とするだけでしょう。 この単純モデルはいくつかの事情で不適当であるかもしれません、そして、何らかの自動化されましたが、ゆっくり異なった運用統制(秒よりむしろ数分)が最近の負荷プロフィールに対してネットワークの利用のバランスをとるのにおいて望ましいかもしれません。
3. Per-Hop Behavior Specification Guidelines
3. 1ホップあたりの振舞い仕様ガイドライン
Basic requirements for per-hop behavior standardization are given in [DSFIELD]. This section elaborates on that text by describing additional guidelines for PHB (group) specifications. This is intended to help foster implementation consistency. Before a PHB group is proposed for standardization it should satisfy these guidelines, as appropriate, to preserve the integrity of this architecture.
[DSFIELD]で1ホップあたりの振舞い標準化のための基本的な要件を与えます。 このセクションは、PHB(グループ)仕様のために別途ガイドラインについて説明することによって、そのテキストについて詳しく説明します。 これが、実現の一貫性を伸ばすのを助けることを意図します。 PHBグループが標準化のために提案される前に、それは、この構造の保全を保持するためにこれらの適切なガイドラインを満たすべきです。
G.1: A PHB standard must specify a recommended DS codepoint selected from the codepoint space reserved for standard mappings [DSFIELD]. Recommended codepoints will be assigned by the IANA. A PHB proposal may recommend a temporary codepoint from the EXP/LU space to facilitate inter-domain experimentation. Determination of a packet's PHB must not require inspection of additional packet header fields beyond the DS field.
G.1: PHB規格は標準のマッピング[DSFIELD]のために予約されたcodepointスペースから選択されたお勧めのDS codepointを指定しなければなりません。 お勧めのcodepointsはIANAによって割り当てられるでしょう。 PHB提案は、EXP/LUスペースからの一時的なcodepointが相互ドメイン実験を容易にすることを勧めるかもしれません。 パケットのPHBの決断はDS分野を超えて追加パケットヘッダーフィールドの点検を必要としてはいけません。
G.2: The specification of each newly proposed PHB group should include an overview of the behavior and the purpose of the behavior being proposed. The overview should include a problem or problems statement for which the PHB group is targeted. The overview should include the basic concepts behind the PHB group. These concepts should include, but are not restricted to, queueing behavior, discard behavior, and output link selection behavior. Lastly, the overview should specify the method by which the PHB group solves the problem or problems specified in the problem statement.
G.2: それぞれの新たに提案されたPHBグループの仕様は振舞いの概観と提案される振舞いの目的を含むべきです。 概観はPHBグループが狙う問題か問題声明を含むべきです。 概観はPHBグループの後ろに基本概念を含むべきです。 含むべきですが、これらの概念が制限されない、待ち行列の振舞い、振舞い、および出力リンク選択の振舞いを捨ててください。 最後に、概観はPHBグループが問題声明で指定された問題か問題を解決する方法を指定するべきです。
G.3: A PHB group specification should indicate the number of individual PHBs specified. In the event that multiple PHBs are specified, the interactions between these PHBs and constraints that must be respected globally by all the PHBs within the group should be clearly specified. As an example, the specification must indicate whether the probability of packet reordering within a microflow is increased if different packets in that microflow are marked for different PHBs within the group.
G.3: PHBグループ仕様は、個々のPHBsの数が指定したのを示すべきです。 複数のPHBsが指定される場合、グループの中のすべてのPHBsがグローバルに尊敬しなければならないこれらのPHBsと規制との相互作用は明確に指定されるべきです。 例として、仕様は、そのmicroflowの異なったパケットが異なったPHBsのためにグループの中でマークされるならパケットがmicroflowの中で再命令されるという確率が増加されているかどうかを示さなければなりません。
Blake, et. al. Informational [Page 21] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[21ページ]のRFC2475構造
G.4: When proper functioning of a PHB group is dependent on constraints such as a provisioning restriction, then the PHB definition should describe the behavior when these constraints are violated. Further, if actions such as packet discard or re-marking are required when these constraints are violated, then these actions should be specifically stipulated.
G.4: これらの規制が違反されるとき、PHBグループの適切な機能が食糧を供給する制限などの規制に依存していると、PHB定義は振舞いについて説明するべきです。 さらに、これらの規制が違反されるとき、パケット破棄か異状などの動作が必要であるなら、これらの動作は明確に規定されるべきです。
G.5: A PHB group may be specified for local use within a domain in order to provide some domain-specific functionality or domain- specific services. In this event, the PHB specification is useful for providing vendors with a consistent definition of the PHB group. However, any PHB group which is defined for local use should not be considered for standardization, but may be published as an Informational RFC. In contrast, a PHB group which is intended for general use will follow a stricter standardization process. Therefore all PHB proposals should specifically state whether they are to be considered for general or local use.
G.5: PHBグループは、いくつかのドメイン特有の機能性かドメインの特定のサービスを提供するためにドメインの中の地方の使用に指定されるかもしれません。 この出来事では、PHB仕様はPHBグループの一貫した定義を業者に提供することの役に立ちます。 しかしながら、地方の使用のために定義されるどんなPHBグループも、標準化のために考えるべきではありませんが、Informational RFCとして発行するかもしれません。 対照的に、一般的使用のために意図するPHBグループは、より厳しい標準化過程に従うでしょう。 したがって、すべてのPHB提案が、それらが一般的であるか地方の使用のために考えられることになっているかどうかと明確に述べるべきです。
It is recognized that PHB groups can be designed with the intent of providing host-to-host, WAN edge-to-WAN edge, and/or domain edge-to- domain edge services. Use of the term "end-to-end" in a PHB definition should be interpreted to mean "host-to-host" for consistency.
PHBグループがホストからホスト、WAN縁からWANへの縁、そして/または、ドメイン縁からドメインに対する縁のサービスを提供する意図をもって設計される場合があると認められます。 PHB定義における「終わらせる終わり」という用語の使用は、一貫性のために「ホストからホスト」を意味するために解釈されるべきです。
Other PHB groups may be defined and deployed locally within domains, for experimental or operational purposes. There is no requirement that these PHB groups must be publicly documented, but they should utilize DS codepoints from one of the EXP/LU pools as defined in [DSFIELD].
他のPHBグループは、実験的であるか操作上の目的のためにドメインの中で局所的に定義されて、配備されるかもしれません。 公的にこれらのPHBグループを記録しなければなりませんが、[DSFIELD]で定義されるようにEXP/LUプールの1つからDS codepointsを利用するべきであるという要件が全くありません。
G.6: It may be possible or appropriate for a packet marked for a PHB within a PHB group to be re-marked to select another PHB within the group; either within a domain or across a domain boundary. Typically there are three reasons for such PHB modification:
G.6: PHBグループの中のPHBが述べるためにマークされたパケットに、グループの中で別のPHBを選択するのは、可能であるか、または適切であるかもしれません。 ドメインかドメイン境界の向こう側に。 そのようなPHB変更の3つの理由が通常あります:
a. The codepoints associated with the PHB group are collectively
intended to carry state about the network,
b. Conditions exist which require PHB promotion or demotion of a
packet (this assumes that PHBs within the group can be ranked in
some order),
c. The boundary between two domains is not covered by a SLA. In this
case the codepoint/PHB to select when crossing the boundary link
will be determined by the local policy of the upstream domain.
a。 PHBグループに関連しているcodepointsがネットワーク、bに関して状態を運ぶことをまとめて意図します。 パケットのPHB販売促進か格下げを必要とする状態が存在しています(これは、何らかのオーダーでグループの中のPHBsを格付けできると仮定します)、c。 2つのドメインの間の境界はSLAでカバーされていません。 境界リンクを越えるのがいつ上流のドメインのローカルの方針で決定するかを選択するこの場合codepoint/PHB。
A PHB specification should clearly state the circumstances under which packets marked for a PHB within a PHB group may, or should be modified (e.g., promoted or demoted) to another PHB within the group. If it is undesirable for a packet's PHB to be modified, the
PHB仕様は明確に、PHBのためにPHBグループの中でマークされたパケットが変更されるべきであるか、またはグループの中で別のPHBに変更されるべきである(例えば、促進されるか、または格下げされます)事情を述べるべきです。 パケットのPHBが変更されるのが、望ましくないなら
Blake, et. al. Informational [Page 22] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[22ページ]のRFC2475構造
specification should clearly state the consequent risks when the PHB is modified. A possible risk to changing a packet's PHB, either within or outside a PHB group, is a higher probability of packet re- ordering within a microflow. PHBs within a group may carry some host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge semantics which may be difficult to duplicate if packets are re- marked to select another PHB from the group (or otherwise).
PHBが変更されているとき、仕様は明確に結果の危険を述べるべきです。 グループ以内かPHBグループの外でパケットのPHBを変えることへの可能なリスクはパケットにmicroflowの中で再注文されるというより高い確率です。 グループの中のPHBsはパケットがグループ(そうでなければ)から別のPHBを選択するために再マークされるならコピーするのが難しいかもしれないホストからホスト、WAN縁からWANへの縁、そして/または、ドメイン縁からドメインへの縁の意味論を運ぶかもしれません。
For certain PHB groups, it may be appropriate to reflect a state change in the node by re-marking packets to specify another PHB from within the group. If a PHB group is designed to reflect the state of a network, the PHB definition must adequately describe the relationship between the PHBs and the states they reflect. Further, if these PHBs limit the forwarding actions a node can perform in some way, these constraints may be specified as actions the node should, or must perform.
あるPHBグループに、グループから別のPHBを指定するためにパケットを述べさせることによってノードにおける州の変化を反映するのは適切であるかもしれません。 PHBグループがネットワークの事情を反映するように設計されるなら、PHB定義は適切にPHBsとそれらが反映する州との関係について説明しなければなりません。 さらに、これらのPHBsがノードが何らかの方法で実行できる推進動作を制限するなら、これらの規制はノードが実行するはずであるか、または実行するはずでなければならない動作として指定されるかもしれません。
G.7: A PHB group specification should include a section defining the implications of tunneling on the utility of the PHB group. This section should specify the implications for the utility of the PHB group of a newly created outer header when the original DS field of the inner header is encapsulated in a tunnel. This section should also discuss what possible changes should be applied to the inner header at the egress of the tunnel, when both the codepoints from the inner header and the outer header are accessible (see Sec. 6.2).
G.7: PHBグループ仕様はPHBグループに関するユーティリティでトンネルを堀る含意を定義するセクションを含むべきです。 内側のヘッダーの元のDS野原がトンネルでカプセルに入れられるとき、このセクションは新たに作成された外側のヘッダーのPHBグループに関するユーティリティに含意を指定するべきです。 また、このセクションは、どんな可能な変化がトンネルの出口の内側のヘッダーに適用されるべきであるかを論ずるべきです、内側のヘッダーと外側のヘッダーからの両方のcodepointsがアクセスしやすいときに(Secを見てください。 6.2).
G.8: The process of specifying PHB groups is likely to be incremental in nature. When new PHB groups are proposed, their known interactions with previously specified PHB groups should be documented. When a new PHB group is created, it can be entirely new in scope or it can be an extension to an existing PHB group. If the PHB group is entirely independent of some or all of the existing PHB specifications, a section should be included in the PHB specification which details how the new PHB group can co-exist with those PHB groups already standardized. For example, this section might indicate the possibility of packet re-ordering within a microflow for packets marked by codepoints associated with two separate PHB groups. If concurrent operation of two (or more) different PHB groups in the same node is impossible or detrimental this should be stated. If the concurrent operation of two (or more) different PHB groups requires some specific behaviors by the node when packets marked for PHBs from these different PHB groups are being processed by the node at the same time, these behaviors should be stated.
G.8: PHBグループを指定する過程は現実に増加である傾向があります。 新しいPHBグループが提案されるとき、以前に指定されたPHBグループとのそれらの知られている相互作用は記録されるべきです。 新しいPHBグループが創設されるとき、それは範囲で完全に新しい場合がありますか、それが既存のPHBグループへの拡大であるかもしれません。 PHBグループが既存のPHB仕様のいくつかかすべてから完全に独立しているなら、セクションは新しいPHBグループがどう既に標準化されるそれらのPHBグループに共存できるかを詳しく述べるPHB仕様に含まれるべきです。 例えば、このセクションはパケットに2つの別々のPHBグループに関連しているcodepointsによってマークされたパケットのためにmicroflowの中で再注文される可能性を示すかもしれません。 同じノードにおける、2つ(さらに)の異なったPHBグループの並行操作が不可能であるか、または有害であるなら、これは述べられるべきです。 PHBsのためにこれらの異なったPHBグループからマークされたパケットが同時にノードによって処理される予定であるとき、2つ(さらに)の異なったPHBグループの並行操作がノードでいくつかの特異的行動を必要とするなら、これらの振舞いは述べられるべきです。
Care should be taken to avoid circularity in the definitions of PHB groups.
PHBグループの定義における円形を避けるために注意するべきです。
Blake, et. al. Informational [Page 23] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[23ページ]のRFC2475構造
If the proposed PHB group is an extension to an existing PHB group, a section should be included in the PHB group specification which details how this extension interoperates with the behavior being extended. Further, if the extension alters or more narrowly defines the existing behavior in some way, this should also be clearly indicated.
提案されたPHBグループが既存のPHBグループへの拡大であるなら、セクションは振舞いが広げられている状態でこの拡大がどう共同利用するかを詳しく述べるPHBグループ仕様に含まれるべきです。 また、さらに、拡大が変わるか、または何らかの方法で既存の振舞いをより辛うじて定義するなら、これは明確に示されるべきです。
G.9: Each PHB specification should include a section specifying minimal conformance requirements for implementations of the PHB group. This conformance section is intended to provide a means for specifying the details of a behavior while allowing for implementation variation to the extent permitted by the PHB specification. This conformance section can take the form of rules, tables, pseudo-code, or tests.
G.9: それぞれのPHB仕様はPHBグループの実現のための最小量の順応要件を指定するセクションを含むべきです。 この順応部が実現変化をPHB仕様で受入れられた範囲まで考慮している間、振舞いの詳細を指定するための手段を提供することを意図します。 この順応部は規則、テーブル、中間コード、またはテストの形を取ることができます。
G.10: A PHB specification should include a section detailing the security implications of the behavior. This section should include a discussion of the re-marking of the inner header's codepoint at the egress of a tunnel and its effect on the desired forwarding behavior.
G.10: PHB仕様は振舞いのセキュリティ含意を詳しく述べるセクションを含むべきです。 このセクションは必要な推進の振舞いへのトンネルとその効果の出口に内側のヘッダーのcodepointの異状の議論を含むべきです。
Further, this section should also discuss how the proposed PHB group could be used in denial-of-service attacks, reduction of service contract attacks, and service contract violation attacks. Lastly, this section should discuss possible means for detecting such attacks as they are relevant to the proposed behavior.
また、さらに、このセクションはサービス不能攻撃、サービス削減契約攻撃、および役務契約違反攻撃にどう提案されたPHBグループを使用できたかを論ずるべきです。 最後に、このセクションはそれらが提案された振舞いに関連しているのでそのような攻撃を検出するための可能な手段を論ずるべきです。
G.11: A PHB specification should include a section detailing configuration and management issues which may affect the operation of the PHB and which may impact candidate services that might utilize the PHB.
G.11: PHB仕様はPHBの操作に影響するかもしれなくて、PHBを利用するかもしれない候補サービスに影響を与えるかもしれない構成を詳しく述べるセクションと管理問題を、含むべきです。
G.12: It is strongly recommended that an appendix be provided with each PHB specification that considers the implications of the proposed behavior on current and potential services. These services could include but are not restricted to be user-specific, device- specific, domain-specific or end-to-end services. It is also strongly recommended that the appendix include a section describing how the services are verified by users, devices, and/or domains.
G.12: 付録がそれぞれのPHB仕様で、それが現在の、そして、潜在的のサービスのときに提案された振舞いの含意を考えるかどうかということであることが強く推薦されます。 これらのサービスは、包含できましたが、ユーザ特有の、または、装置特有の、または、ドメイン特有の、または、終わりに終わっているサービスになるように制限されません。 また、付録がサービスがユーザ、装置、そして/または、ドメインによってどう確かめられるかを説明するセクションを含むことが強く勧められます。
G.13: It is recommended that an appendix be provided with each PHB specification that is targeted for local use within a domain, providing guidance for PHB selection for packets which are forwarded into a peer domain which does not support the PHB group.
G.13: ドメインの中の地方の使用のために狙うそれぞれのPHB仕様を付録に提供するのはお勧めです、PHBグループを支持しない同輩ドメインに送られるパケットのためのPHB選択のための指導を提供して。
Blake, et. al. Informational [Page 24] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[24ページ]のRFC2475構造
G.14: It is recommended that an appendix be provided with each PHB specification which considers the impact of the proposed PHB group on existing higher-layer protocols. Under some circumstances PHBs may allow for possible changes to higher-layer protocols which may increase or decrease the utility of the proposed PHB group.
G.14: 提案されたPHBグループの既存の上位層プロトコルへの影響を考えるそれぞれのPHB仕様を付録に提供するのはお勧めです。 いくつかの状況で、PHBsは提案されたPHBグループに関するユーティリティを増加するか、または減少させるかもしれない上位層プロトコルへの可能な変化を考慮するかもしれません。
G.15: It is recommended that an appendix be provided with each PHB specification which recommends mappings to link-layer QoS mechanisms to support the intended behavior of the PHB across a shared-medium or switched link-layer. The determination of the most appropriate mapping between a PHB and a link-layer QoS mechanism is dependent on many factors and is outside the scope of this document; however, the specification should attempt to offer some guidance.
G.15: リンクレイヤQoSメカニズムへのマッピングが共有された媒体か切り換えられたリンクレイヤの向こう側にPHBの意図している動きを支持することを勧めるそれぞれのPHB仕様を付録に提供するのはお勧めです。 PHBとリンクレイヤQoSメカニズムの間の最も適切なマッピングの決断は、多くの要素に依存していて、このドキュメントの範囲の外にあります。 しかしながら、仕様は、何らかの指導を提供するのを試みるべきです。
4. Interoperability with Non-Differentiated Services-Compliant Nodes
4. 非微分されたサービス対応することのノードの相互運用性
We define a non-differentiated services-compliant node (non-DS- compliant node) as any node which does not interpret the DS field as specified in [DSFIELD] and/or does not implement some or all of the standardized PHBs (or those in use within a particular DS domain). This may be due to the capabilities or configuration of the node. We define a legacy node as a special case of a non-DS-compliant node which implements IPv4 Precedence classification and forwarding as defined in [RFC791, RFC1812], but which is otherwise not DS- compliant. The precedence values in the IPv4 TOS octet are compatible by intention with the Class Selector Codepoints defined in [DSFIELD], and the precedence forwarding behaviors defined in [RFC791, RFC1812] comply with the Class Selector PHB Requirements also defined in [DSFIELD]. A key distinction between a legacy node and a DS-compliant node is that the legacy node may or may not interpret bits 3-6 of the TOS octet as defined in [RFC1349] (the "DTRC" bits); in practice it will not interpret these bit as specified in [DSFIELD]. We assume that the use of the TOS markings defined in [RFC1349] is deprecated. Nodes which are non-DS-compliant and which are not legacy nodes may exhibit unpredictable forwarding behaviors for packets with non-zero DS codepoints.
私たちが非微分されたサービス対応することのノードを定義する、(非、-、DS対応することのノード) DS分野が[DSFIELD]で指定されていると解釈しない、またそして/または、標準化されたPHBs(または、特定のDSドメインの中で使用中のそれら)のいくつかかすべてを実行しないどんなノードとしても。 これはノードの能力か構成のためであるかもしれません。 私たちが特殊なものとしてaについて遺産ノードを定義する、非DS対応する、[RFC791、RFC1812]で定義されるように実行していますが、そうでなければIPv4 Precedence分類と推進のDS対応でないノード。 IPv4 TOS八重奏における先行値は故意に[DSFIELD]で定義されるClass Selector Codepointsと互換性があります、そして、振舞いが[RFC791、RFC1812]で定義した先行推進はまた、[DSFIELD]で定義されるClass Selector PHB Requirementsに応じます。 遺産ノードとDS対応することのノードの主要な区別は遺産ノードが[RFC1349]("DTRC"ビット)で定義されるようにTOS八重奏のビット3-6を解釈するかもしれないということです。 実際には、それは[DSFIELD]で指定されるように噛み付かれたこれらを解釈しないでしょう。 私たちは、[RFC1349]で定義されたTOS印の使用が推奨しないと思います。 そうするノード、非DS対応する、どれが遺産ノードであるかはどんな非ゼロDS codepointsがあるパケットのための展示品の予測できない推進の振舞いがそうしないかもしれません。
Differentiated services depend on the resource allocation mechanisms provided by per-hop behavior implementations in nodes. The quality or statistical assurance level of a service may break down in the event that traffic transits a non-DS-compliant node, or a non-DS- capable domain.
微分されたサービスは1ホップあたりの振舞い実現でノードに提供された資源配分メカニズムによります。 交通がaを通過する場合サービスの上質的、または、統計的な保証レベルが故障するかもしれない、非DS対応する、ノード、またはa、非、-、DSできるドメイン。
We will examine two separate cases. The first case concerns the use of non-DS-compliant nodes within a DS domain. Note that PHB forwarding is primarily useful for allocating scarce node and link resources in a controlled manner. On high-speed, lightly loaded links, the worst-case packet delay, jitter, and loss may be
私たちは2回の別件を調べるつもりです。 最初のこの件は使用に関係がある、非DS対応する、DSドメインの中のノード。 PHB推進が主として制御方法で不十分なノードとリンクリソースを割り当てることの役に立つことに注意してください。 高速で、軽く積み込まれたリンクに関して、最悪の場合パケット遅れ、ジター、および損失はそうです。
Blake, et. al. Informational [Page 25] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[25ページ]のRFC2475構造
negligible, and the use of a non-DS-compliant node on the upstream end of such a link may not result in service degradation. In more realistic circumstances, the lack of PHB forwarding in a node may make it impossible to offer low-delay, low-loss, or provisioned bandwidth services across paths which traverse the node. However, use of a legacy node may be an acceptable alternative, assuming that the DS domain restricts itself to using only the Class Selector Codepoints defined in [DSFIELD], and assuming that the particular precedence implementation in the legacy node provides forwarding behaviors which are compatible with the services offered along paths which traverse that node. Note that it is important to restrict the codepoints in use to the Class Selector Codepoints, since the legacy node may or may not interpret bits 3-5 in accordance with [RFC1349], thereby resulting in unpredictable forwarding results.
取るにたらなさ、aの使用、非DS対応する、そのようなリンクの上流の端のノードはサービス退行をもたらさないかもしれません。 より現実的な事情では、ノードのPHB推進の不足で低い遅れを提供するのは不可能になるかもしれません、ノードを横断する経路中の低い損失の、または、食糧を供給された帯域幅サービス。 しかしながら、遺産ノードの使用は受け入れられる代案であるかもしれません、DSドメインがそのノードを横断する経路に沿って提供するサービスと互換性がある振舞いを進めながらそれ自体を[DSFIELD]で定義されて、遺産ノードにおける特定の先行実現が提供されると仮定しながらClass Selector Codepointsだけを使用するのに制限すると仮定して。 Class Selector Codepointsに使用中のcodepointsを制限するのが重要であることに注意してください、[RFC1349]に従って遺産ノードがビット3-5を解釈するかもしれないので、その結果、予測できない推進結果をもたらします。
The second case concerns the behavior of services which traverse non-DS-capable domains. We assume for the sake of argument that a non-DS-capable domain does not deploy traffic conditioning functions on domain boundary nodes; therefore, even in the event that the domain consists of legacy or DS-compliant interior nodes, the lack of traffic enforcement at the boundaries will limit the ability to consistently deliver some types of services across the domain. A DS domain and a non-DS-capable domain may negotiate an agreement which governs how egress traffic from the DS-domain should be marked before entry into the non-DS-capable domain. This agreement might be monitored for compliance by traffic sampling instead of by rigorous traffic conditioning. Alternatively, where there is knowledge that the non-DS-capable domain consists of legacy nodes, the upstream DS domain may opportunistically re-mark differentiated services traffic to one or more of the Class Selector Codepoints. Where there is no knowledge of the traffic management capabilities of the downstream domain, and no agreement in place, a DS domain egress node may choose to re-mark DS codepoints to zero, under the assumption that the non- DS-capable domain will treat the traffic uniformly with best-effort service.
2番目のこの件はできる非DSドメインを横断するサービスの振舞いに関係があります。 私たちは、できる非DSドメインがドメイン境界ノードを機能を条件とさせる交通を配備しないと議論するために思います。 したがって、ドメインが遺産かDS対応することの内部のノードから成りさえする場合、境界の道路交通法施行の不足は一貫して何人かのタイプのサービスをドメインの向こう側に届ける能力を制限するでしょう。 DSドメインとできる非DSドメインはDS-ドメインからの出口交通がエントリーの前にどうできる非DSドメインに示されるべきであるかを治める協定を交渉するかもしれません。 この協定は承諾ために厳しいことの代わりに交通調節を抽出する交通でモニターされるかもしれません。 あるいはまた、できる非DSドメインが遺産ノードから成るという知識があるところでは、上流のDSドメインはClass Selector Codepointsの1つ以上への微分されたサービス交通を便宜主義的に述べさせるかもしれません。 川下のドメインにもかかわらず、協定がない輸送管理能力に関する知識が全く適所にないところでは、DSドメイン出口ノードは、DS codepointsをゼロに述べさせるのを選ぶかもしれません、DSできる非ドメインがベストエフォート型サービスで一様に交通を扱うという仮定で。
In the event that a non-DS-capable domain peers with a DS domain, traffic flowing from the non-DS-capable domain should be conditioned at the DS ingress node of the DS domain according to the appropriate SLA or policy.
できる非DSドメインがDSドメインでじっと見る場合、適切なSLAか方針によると、できる非DSドメインから流れる交通はDSドメインのDSイングレスノードで条件とするべきです。
5. Multicast Considerations
5. マルチキャスト問題
Use of differentiated services by multicast traffic introduces a number of issues for service provisioning. First, multicast packets which enter a DS domain at an ingress node may simultaneously take multiple paths through some segments of the domain due to multicast packet replication. In this way they consume more network resources
マルチキャスト交通による微分されたサービスの使用はサービスの食糧を供給するために多くの問題を紹介します。 イングレスノードでDSドメインに入るマルチキャストパケットは同時に、まず最初に、マルチキャストパケット模写のためドメインのいくつかのセグメントを通して複数の経路を取るかもしれません。 彼らが、より多くのネットワーク資源を消費するこのように
Blake, et. al. Informational [Page 26] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[26ページ]のRFC2475構造
than unicast packets. Where multicast group membership is dynamic, it is difficult to predict in advance the amount of network resources that may be consumed by multicast traffic originating from an upstream network for a particular group. A consequence of this uncertainty is that it may be difficult to provide quantitative service guarantees to multicast senders. Further, it may be necessary to reserve codepoints and PHBs for exclusive use by unicast traffic, to provide resource isolation from multicast traffic.
ユニキャストパケットより。 マルチキャストグループ会員資格がダイナミックであるところでは、あらかじめ特定のグループのために上流のネットワークから発するマルチキャスト交通で消費されるかもしれないネットワーク資源の量を予測するのは難しいです。 この不確実性の結果は量的なサービス保証をマルチキャスト送付者に提供するのが難しいかもしれないということです。 さらに、ユニキャスト交通で専用にcodepointsとPHBsを予約するのが、マルチキャスト交通からリソース孤立を提供するのに必要であるかもしれません。
The second issue is the selection of the DS codepoint for a multicast packet arriving at a DS ingress node. Because that packet may exit the DS domain at multiple DS egress nodes which peer with multiple downstream domains, the DS codepoint used should not result in the request for a service from a downstream DS domain which is in violation of a peering SLA. When establishing classifier and traffic conditioner state at an DS ingress node for an aggregate of traffic receiving a differentiated service which spans across the egress boundary of the domain, the identity of the adjacent downstream transit domain and the specifics of the corresponding peering SLA can be factored into the configuration decision (subject to routing policy and the stability of the routing infrastructure). In this way peering SLAs with downstream DS domains can be partially enforced at the ingress of the upstream domain, reducing the classification and traffic conditioning burden at the egress node of the upstream domain. This is not so easily performed in the case of multicast traffic, due to the possibility of dynamic group membership. The result is that the service guarantees for unicast traffic may be impacted. One means of addressing this problem is to establish a separate peering SLA for multicast traffic, and to either utilize a particular set of codepoints for multicast packets, or to implement the necessary classification and traffic conditioning mechanisms in the DS egress nodes to provide preferential isolation for unicast traffic in conformance with the peering SLA with the downstream domain.
第2刷はDSイングレスノードに到着するマルチキャストパケットのためのDS codepointの選択です。 そのパケットが複数の川下のドメインでじっと見る複数のDS出口ノードでDSドメインを出るかもしれないので、使用されるDS codepointはじっと見るSLAを違反している川下のDSドメインからのサービスを求める要求をもたらすはずがありません。 微分されたサービスを受けながら交通の集合のためのDSイングレスノードにクラシファイアと交通コンディショナー州を設立するとき、構成決定(ルーティングインフラストラクチャのルーティング方針と安定性を条件とした)をどれがドメインの出口境界、隣接している川下のトランジットドメインのアイデンティティ、および対応するじっと見ることの詳細の向こう側にSLAにかかるかの要因として考慮できます。 このように、上流のドメインのイングレスで川下のDSドメインがあるじっと見るSLAを部分的に実施できます、上流のドメインの出口ノードにおける負担を条件とさせる分類と交通を抑えて。 これはダイナミックなグループ会員資格の可能性によるマルチキャスト交通の場合でそれほど容易に実行されません。 結果はユニキャスト交通のためのサービス保証に影響を与えるかもしれないということです。 このその問題を訴える1つの手段は、別々のじっと見るSLAをマルチキャスト交通に設立して、codepointsの特定のセットをマルチキャストパケットに利用するか、または川下のドメインと共に順応におけるユニキャスト交通のための優先の孤立をじっと見るSLAに提供するためにDS出口ノードで必要な分類と交通調節メカニズムを実行することです。
6. Security and Tunneling Considerations
6. セキュリティとトンネリング問題
This section addresses security issues raised by the introduction of differentiated services, primarily the potential for denial-of- service attacks, and the related potential for theft of service by unauthorized traffic (Sec. 6.1). In addition, the operation of differentiated services in the presence of IPsec and its interaction with IPsec are also discussed (Sec. 6.2), as well as auditing requirements (Sec. 6.3). This section considers issues introduced by the use of both IPsec and non-IPsec tunnels.
このセクションが微分されたサービスの導入、主として否定の可能性によって提起された安全保障問題を記述する、-、-権限のない交通で攻撃、およびサービスの窃盗の関連する可能性を修理してください。(秒 6.1). また、さらに、IPsecの面前で微分されたサービスの操作とIPsecとのその相互作用について議論します。(秒 6.2), 監査要求事項と同様に(秒 6.3). このセクションはIPsecと非IPsecトンネルの両方の使用で紹介された問題を考えます。
Blake, et. al. Informational [Page 27] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 微分されたサービス1998年12月のための情報[27ページ]のRFC2475構造
6.1 Theft and Denial of Service
6.1 窃盗とサービス妨害
The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of resource management techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better) service than others. The mapping of network traffic to the specific behaviors that result in different (e.g., better or worse) service is indicated primarily by the DS field, and hence an adversary may be able to obtain better service by modifying the DS field to codepoints indicating behaviors used for enhanced services or by injecting packets with the DS field set to such codepoints. Taken to its limits, this theft of service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams. The defense against such theft- and denial-of- service attacks consists of the combination of traffic conditioning at DS boundary nodes along with security and integrity of the network infrastructure within a DS domain.
差別化されたサービスのプライマリ目標は異なったレベルのサービスが一般的なネットワークインフラでトラフィックストリームに提供されるのを許容することです。 さまざまなリソース管理技術がこれを達成するのに使用されるかもしれませんが、結末はいくつかのパケットが他のものと異なった(例えば、より良い)サービスを受けるということでしょう。 異なった(例えば、より良いか、より悪い)サービスをもたらす特異的行動へのネットワークトラフィックに関するマッピングは主としてDS分野によって示されます、そして、したがって、敵は高度サービスかDS分野をパケットに注射することによって使用される振舞いがそのようなcodepointsにセットしたのを示すcodepointsにDS分野を変更することによって、より良いサービスを得ることができるかもしれません。 限界に取ります、変更されたか注入されたトラフィックがそのような窃盗と-サービスでは、攻撃がDSドメインの中でネットワークインフラのセキュリティと保全に伴うDS境界ノードでトラフィック調節の組み合わせから成るという否定に対して他のトラフィックストリームそれを進めるために利用可能なリソースとディフェンスを使い果たすとき、このサービスの窃盗はサービス不能攻撃になります。
As described in Sec. 2, DS ingress nodes must condition all traffic entering a DS domain to ensure that it has acceptable DS codepoints. This means that the codepoints must conform to the applicable TCA(s) and the domain's service provisioning policy. Hence, the ingress nodes are the primary line of defense against theft- and denial-of- service attacks based on modified DS codepoints (e.g., codepoints to which the traffic is not entitled), as success of any such attack constitutes a violation of the applicable TCA(s) and/or service provisioning policy. An important instance of an ingress node is that any traffic-originating node in a DS domain is the ingress node for that traffic, and must ensure that all originated traffic carries acceptable DS codepoints.
Secで説明されるように。 2、DSイングレスノードは、許容できるDS codepointsを持っているのを保証するようにDSドメインに入るすべてのトラフィックを条件とさせなければなりません。 これは、codepointsが適切なTCA(s)とドメインのサービス食糧を供給する方針に一致しなければならないことを意味します。 したがって、イングレスノードは窃盗と-どんなそのような攻撃の成功も適切なTCA(s)の違反を構成するので、サービスでは、攻撃が(例えば、トラフィックが権利を与えられないcodepoints)を変更されたDS codepointsに基礎づけたという否定、そして/または、方針に食糧を供給するサービスに対してプライマリ防衛線です。 イングレスノードの重要なインスタンスはDSドメインのどんなトラフィックを溯源するノードも、そのトラフィックのためのイングレスノードであり、すべての溯源されたトラフィックが許容できるDS codepointsを運ぶのを確実にしなければならないということです。
Both a domain's service provisioning policy and TCAs may require the ingress nodes to change the DS codepoint on some entering packets (e.g., an ingress router may set the DS codepoint of a customer's traffic in accordance with the appropriate SLA). Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD]. Traffic authentication may be required to validate the use of some DS codepoints (e.g., those corresponding to enhanced services), and such authentication may be performed by technical means (e.g., IPsec) and/or non-technical means (e.g., the inbound link is known to be connected to exactly one customer site).
ドメインのサービス食糧を供給する方針とTCAsの両方が、パケットに入りながら、イングレスノードがいくつかでDS codepointを変えるのを必要とするかもしれません(適切なSLAによると、例えば、イングレスルータは顧客のトラフィックのDS codepointを設定するかもしれません)。 イングレスノードは、DS codepointsが許容できるのを保証するように他のすべてのインバウンドトラフィックを条件とさせなければなりません。 容認できないcodepointsを持つために見つけられたパケットで、進める前に、捨てなければならないか、またはそれらのDS codepointsを許容値に変更しなければなりません。 例えば、高度サービス協定が全く存在しないドメインからトラフィックを受けるイングレスノードはDefault PHB codepoint[DSFIELD]にDS codepointをリセットするかもしれません。 トラフィック認証がいくつかのDS codepoints(例えば、高度サービスに対応するそれら)の使用を有効にするのに必要であるかもしれません、そして、そのような認証は技術手段(例えば、IPsec)、そして/または、非技術系の手段で実行されるかもしれません(例えば、インバウンドリンクによってまさに1つの顧客サイトに関連づけられるのを知られています)。
Blake, et. al. Informational [Page 28] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[28ページ]のRFC2475アーキテクチャ
An inter-domain agreement may reduce or eliminate the need for ingress node traffic conditioning by making the upstream domain partly or completely responsible for ensuring that traffic has DS codepoints acceptable to the downstream domain. In this case, the ingress node may still perform redundant traffic conditioning checks to reduce the dependence on the upstream domain (e.g., such checks can prevent theft-of-service attacks from propagating across the domain boundary). If such a check fails because the upstream domain is not fulfilling its responsibilities, that failure is an auditable event; the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform under these circumstances.
相互ドメイン協定は、上流のドメインをトラフィックでDS codepointsが川下のドメインに許容できるようになるのを確実にするのに一部か完全に責任感が強くすることによって、イングレスノードトラフィック調節の必要性を減少するか、または排除するかもしれません。 この場合、イングレスノードは、上流のドメインへの依存を減少させるためにまだ余分なトラフィック調節チェックを実行しているかもしれません(例えば、そのようなチェックは、サービスの窃盗攻撃がドメイン境界の向こう側に伝播されるのを防ぐことができます)。 上流のドメインが責任を遂行していないのでそのようなチェックが失敗するなら、その失敗は監査可能イベントです。 発生している監査ログエントリーはパケットが受け取られた日付/時、ソース、送付先IPアドレス、および失敗を引き起こしたDS codepointを含むべきです。 実際には、そのようなチェックからの限られた利得は、何がこういう事情ですから働くためにもしあればチェックするかを決定することにおけるそれらの潜在的性能影響に比較考量される必要があります。
Interior nodes in a DS domain may rely on the DS field to associate differentiated services traffic with the behaviors used to implement enhanced services. Any node doing so depends on the correct operation of the DS domain to prevent the arrival of traffic with unacceptable DS codepoints. Robustness concerns dictate that the arrival of packets with unacceptable DS codepoints must not cause the failure (e.g., crash) of network nodes. Interior nodes are not responsible for enforcing the service provisioning policy (or individual SLAs) and hence are not required to check DS codepoints before using them. Interior nodes may perform some traffic conditioning checks on DS codepoints (e.g., check for DS codepoints that are never used for traffic on a specific link) to improve security and robustness (e.g., resistance to theft-of-service attacks based on DS codepoint modifications). Any detected failure of such a check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform at interior nodes.
DSドメインの内部のノードは、高度サービスを実装するのに使用される振舞いに差別化されたサービストラフィックを関連づけるためにDS分野を当てにするかもしれません。 そうするどんなノードも、容認できないDS codepointsとのトラフィックの到着を防ぐためにDSドメインの正しい操作によります。 丈夫さ関心は、容認できないDS codepointsとのパケットの到着がネットワーク・ノードの失敗(例えば、ダウンする)を引き起こしてはいけないと決めます。 内部のノードは、サービス食糧を供給する方針(または、個々のSLA)を実施するのに責任がなくて、したがって、彼らを使用する前に、DS codepointsをチェックする必要はありません。 内部のノードはセキュリティと丈夫さ(例えば、DS codepoint変更に基づくサービスの窃盗攻撃への抵抗)を向上させるようにDS codepoints(例えば、トラフィックに特定のリンクの上に決して使用されないDS codepointsがないかどうかチェックする)のチェックを条件とさせる何らかのトラフィックを実行するかもしれません。 そのようなチェックのどんな検出された失敗も、監査可能イベントと、エントリーがパケットを受け取った日付/時代に含むべきである発生している監査ログと、ソースと、送付先IPアドレスと、失敗を引き起こしたDS codepointです。 実際には、そのようなチェックからの限られた利得は、何が内部のノードで働くためにもしあればチェックするかを決定することにおけるそれらの潜在的性能影響に比較考量される必要があります。
Any link that cannot be adequately secured against modification of DS codepoints or traffic injection by adversaries should be treated as a boundary link (and hence any arriving traffic on that link is treated as if it were entering the domain at an ingress node). Local security policy provides the definition of "adequately secured," and such a definition may include a determination that the risks and consequences of DS codepoint modification and/or traffic injection do not justify any additional security measures for a link. Link security can be enhanced via physical access controls and/or software means such as tunnels that ensure packet integrity.
敵が適切にDS codepointsかトラフィック注射の変更に対して固定できないどんなリンクも境界リンクとして扱われるべきです(したがって、そのリンクの上のどんな到着トラフィックもまるでイングレスノードでドメインに入っているかのように扱われます)。 ローカルの安全保障政策は「適切に機密保護されること」の定義を提供します、そして、そのような定義は決断を含むかもしれません。変更、そして/または、トラフィック注射がするDS codepointのリスクと結果は少しの追加セキュリティ対策もリンクに正当化しません。 パケット保全を確実にするトンネルなどの物理的なアクセス制御、そして/または、ソフトウェア手段でリンクセキュリティを高めることができます。
Blake, et. al. Informational [Page 29] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[29ページ]のRFC2475アーキテクチャ
6.2 IPsec and Tunneling Interactions
6.2 IPsecとトンネリング相互作用
The IPsec protocol, as defined in [ESP, AH], does not include the IP header's DS field in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IP header's DS field that is not included). Hence modification of the DS field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the DS field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security. In some environments, the ability to modify the DS field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, the DS domains should be configured so that the required processing (e.g., set all DS fields on sensitive traffic to a single value) can be performed at DS egress nodes where traffic exits higher security domains.
[超能力、AH]で定義されるIPsecプロトコルは暗号の計算のいずれにもIPヘッダーのDS分野を含んでいません(トンネルモードの場合では、それは外側のIPヘッダーの含まれていないDS分野です)。 したがって、ネットワーク・ノードによるDS分野の変更は終わりから終わりへのIPsecのセキュリティで効き目がありません、それがどんなIPsec保全チェックにも失敗できないので。 結果として、IPsecは敵のDS分野(すなわち、介入者攻撃)の変更に対してどんなディフェンスも提供しません、また、敵の変更が終わりから終わりへのIPsecのセキュリティで効き目がないとき。 いくつかの環境で、IPsec保全チェックに影響しないでDS分野を変更する能力はひそかなチャンネルを構成するかもしれません。 そのようなチャンネルを排除するか、または帯域幅を減少させるのが必要であるなら、DSドメインは、トラフィックが、より高いセキュリティー領域を出るDS出口ノードで必要な処理(例えば、敏感なトラフィックのすべてのDS分野をただ一つの値に設定する)を実行できるように構成されるべきです。
IPsec's tunnel mode provides security for the encapsulated IP header's DS field. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is hosted (in whole or in part) on a differentiated services network, the intermediate network nodes operate on the DS field in the outer header. At the tunnel egress node, IPsec processing includes stripping the outer header and forwarding the packet (if required) using the inner header. If the inner IP header has not been processed by a DS ingress node for the tunnel egress node's DS domain, the tunnel egress node is the DS ingress node for traffic exiting the tunnel, and hence must carry out the corresponding traffic conditioning responsibilities (see Sec. 6.1). If the IPsec processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), the tunnel egress node can safely assume that the DS field in the inner header has the same value as it had at the tunnel ingress node. This allows a tunnel egress node in the same DS domain as the tunnel ingress node, to safely treat a packet passing such an integrity check as if it had arrived from another node within the same DS domain, omitting the DS ingress node traffic conditioning that would otherwise be required. An important consequence is that otherwise insecure links internal to a DS domain can be secured by a sufficiently strong IPsec tunnel.
IPsecのトンネルモードはカプセル化されたIPヘッダーのDS分野にセキュリティを提供します。 トンネルモードIPsecパケットは2個のIPヘッダーを含んでいます: トンネルイングレスノードを供給された外側のヘッダーとパケットの一次資料によって供給されたカプセル化された内側のヘッダー。 IPsecトンネルが差別化されたサービスネットワークで接待されるとき(全体か一部)、中間ネットワークノードは外側のヘッダーのDSフィールドを作動させます。 トンネル出口ノードでは、IPsec処理は、内側のヘッダーを使用することで外側のヘッダーを裸にして、(必要なら、)パケットを進めるのを含んでいます。 内側のIPヘッダーがトンネル出口ノードのDSドメインのためのDSイングレスノードによって処理されていなくて、トンネル出口ノードがトンネルを出るトラフィックのためのDSイングレスノードであり、したがって、対応するトラフィック調節責任を行わなければならないなら(Secを見てください。 6.1). IPsec処理がカプセル化されたパケット(十分がローカルの安全保障政策で決定するところ)の十分強い暗号の保全チェックを含んでいるなら、トンネル出口ノードは、内側のヘッダーのDS分野がそれが持っていたようにトンネルイングレスノードに同じ値を持っていると安全に仮定できます。 これは同じDSドメインの中で安全にまるで別のノードから到着したかのようにそのような保全チェックを通過するパケットを扱うために同じDSドメインのトンネルイングレスノードとしてのトンネル出口ノードを許容します、別の方法で必要であるDSイングレスノードトラフィック調節を省略して。 重要な結果は十分堅固なIPsecトンネルでDSドメインへの内部のそうでなければ、不安定なリンクを固定できるということです。
This analysis and its implications apply to any tunneling protocol that performs integrity checks, but the level of assurance of the inner header's DS field depends on the strength of the integrity
この分析とその含意は保全チェックを実行するどんなトンネリングプロトコルにも適用されますが、内側のヘッダーのDS分野の保証のレベルは保全の強さに依存します。
Blake, et. al. Informational [Page 30] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[30ページ]のRFC2475アーキテクチャ
check performed by the tunneling protocol. In the absence of sufficient assurance for a tunnel that may transit nodes outside the current DS domain (or is otherwise vulnerable), the encapsulated packet must be treated as if it had arrived at a DS ingress node from outside the domain.
チェックはトンネリングプロトコルで働きました。 現在のDSドメイン(または、そうでなければ、被害を受け易い)の外にノードを通過するかもしれないトンネルのための十分な保証がないとき、まるでドメインの外からのDSイングレスノードに到着したかのようにカプセル化されたパケットを扱わなければなりません。
The IPsec protocol currently requires that the inner header's DS field not be changed by IPsec decapsulation processing at a tunnel egress node. This ensures that an adversary's modifications to the DS field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint. This document makes no change to that IPsec requirement.
IPsecプロトコルは、現在、内側のヘッダーのDS分野がトンネル出口ノードでIPsec被膜剥離術処理で変えられないのを必要とします。 これは、IPsecトンネル終点の向こう側に窃盗かサービス不能攻撃に着手するのにDS分野への敵の変更を使用できないのを確実にします、どんなそのような変更もトンネル終点で捨てられるとき。 このドキュメントはそのIPsec要件への変更を全く行いません。
If the IPsec specifications are modified in the future to permit a tunnel egress node to modify the DS field in an inner IP header based on the DS field value in the outer header (e.g., copying part or all of the outer DS field to the inner DS field), then additional considerations would apply. For a tunnel contained entirely within a single DS domain and for which the links are adequately secured against modifications of the outer DS field, the only limits on inner DS field modifications would be those imposed by the domain's service provisioning policy. Otherwise, the tunnel egress node performing such modifications would be acting as a DS ingress node for traffic exiting the tunnel and must carry out the traffic conditioning responsibilities of an ingress node, including defense against theft- and denial-of-service attacks (See Sec. 6.1). If the tunnel enters the DS domain at a node different from the tunnel egress node, the tunnel egress node may depend on the upstream DS ingress node having ensured that the outer DS field values are acceptable. Even in this case, there are some checks that can only be performed by the tunnel egress node (e.g., a consistency check between the inner and outer DS codepoints for an encrypted tunnel). Any detected failure of such a check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that was unacceptable.
IPsec仕様が将来トンネル出口ノードが外側のヘッダー(例えば、外側のDS分野の部分かすべてを内側のDS分野にコピーする)でDS分野価値に基づく内側のIPヘッダーのDS分野を変更することを許可するように変更されるなら、追加問題は適用されるでしょう。 完全にただ一つのDSドメインの中に保管されて、リンクがどれであるかために適切に外側のDS分野の変更に対して固定されたトンネルに関しては、内側のDS分野変更における唯一の限界が方針に食糧を供給するドメインのサービスで課されたものでしょう。 さもなければ、そのような変更を実行するトンネル出口ノードは、トンネルを出て、トラフィックのためのDSイングレスノードとして機能していて、イングレスノードのトラフィック調節責任を行わなければなりません、窃盗とサービス不能攻撃に対してディフェンスを含めて(秒に遭遇してください。 6.1). トンネルがトンネル出口ノードと異なったノードでDSドメインに入るなら、上流のDSイングレスノードの上で外側のDS分野値が許容できるのを確実にして、トンネル出口ノードはよるかもしれません。 この場合さえ、トンネル出口ノード(例えば、暗号化されたトンネルへの内側の、そして、外側のDS codepointsの間の一貫性チェック)で実行できるだけであるいくつかのチェックがあります。 そのようなチェックのどんな検出された失敗も、監査可能イベントと、エントリーがパケットを受け取った日付/時代に含むべきである発生している監査ログと、ソースと、送付先IPアドレスと、容認できなかったDS codepointです。
An IPsec tunnel can be viewed in at least two different ways from an architectural perspective. If the tunnel is viewed as a logical single hop "virtual wire", the actions of intermediate nodes in forwarding the tunneled traffic should not be visible beyond the ends of the tunnel and hence the DS field should not be modified as part of decapsulation processing. In contrast, if the tunnel is viewed as a multi-hop participant in forwarding traffic, then modification of the DS field as part of tunnel decapsulation processing may be desirable. A specific example of the latter situation occurs when a tunnel terminates at an interior node of a DS domain at which the domain administrator does not wish to deploy traffic conditioning
少なくとも2つの建築見解と異なった方法でIPsecトンネルを見ることができます。 トンネルを堀られたトラフィックを進めることにおける、中間的ノードの機能はトンネルの端のときに目に見えるべきではありません、そして、トンネルが論理的なシングルとして見なされるなら、「仮想のワイヤ」を飛び越してください、そして、したがって、被膜剥離術処理の一部としてDS分野を変更するべきではありません。 対照的に、トンネルが推進トラフィックのマルチホップ関係者として見なされるなら、トンネル被膜剥離術処理の一部としてのDS分野の変更は望ましいかもしれません。 トンネルがドメイン管理者がトラフィックが調節であると配布したがっていないDSドメインの内部のノードで終わると、後者の状況の特定の例は現れます。
Blake, et. al. Informational [Page 31] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[31ページ]のRFC2475アーキテクチャ
logic (e.g., to simplify traffic management). This could be supported by using the DS codepoint in the outer IP header (which was subject to traffic conditioning at the DS ingress node) to reset the DS codepoint in the inner IP header, effectively moving DS ingress traffic conditioning responsibilities from the IPsec tunnel egress node to the appropriate upstream DS ingress node (which must already perform that function for unencapsulated traffic).
論理(例えば輸送管理を簡素化する)。 内側のIPヘッダーにDS codepointをリセットするのに外側のIPヘッダー(DSイングレスノードでのトラフィック調節を受けることがあった)でDS codepointを使用することによって、これをサポートすることができるでしょう、事実上、移行しているDSイングレストラフィックが責任をIPsecトンネル出口ノードから適切な上流のDSイングレスノード(非カプセル化されたトラフィックのために既にその機能を実行しなければならない)まで条件とさせて。
6.3 Auditing
6.3 監査
Not all systems that support differentiated services will implement auditing. However, if differentiated services support is incorporated into a system that supports auditing, then the differentiated services implementation should also support auditing. If such support is present the implementation must allow a system administrator to enable or disable auditing for differentiated services as a whole, and may allow such auditing to be enabled or disabled in part.
差別化されたサービスをサポートするというわけではないすべてのシステムが監査を実装するでしょう。 しかしながら、差別化されたサービスサポートが監査をサポートするシステムに組み入れられるなら、また、差別化されたサービス実装は監査をサポートするべきです。 そのようなサポートが存在しているなら、実装は、システム管理者が全体で差別化されたサービスのための監査を可能にするか、または無効にするのを許容しなければならなくて、そのような監査が一部可能にされるか、または無効にされるのを許容するかもしれません。
For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document and for each of these events a minimum set of information that should be included in an audit log is defined. Additional information (e.g., packets related to the one that triggered the auditable event) may also be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also may result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
監査の粒状はだいたい、地域にかかわる事柄です。 しかしながら、いくつかの監査可能イベントが本書では特定されます、そして、それぞれのこれらのイベントにおいて、監査ログに含まれるべきである最小の情報は定義されます。 また、追加情報(例えば監査可能イベントの引き金となったものに関連するパケット)はこの仕様で明らかに大声で叫んで、また、監査航空日誌記入事項をもたらすかもしれないのではなく、それぞれのこれらのイベント、および追加イベントのための監査ログに含まれるかもしれません。 受信機が監査可能イベントの検出に対応してどんなメッセージも主張された送付者に送るという要件が全くありません、そのような動作でサービスの否定を引き起こす可能性のために。
7. Acknowledgements
7. 承認
This document has benefitted from earlier drafts by Steven Blake, David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski, and Lixia Zhang.
このドキュメントはスティーブン・ブレーク、デヴィッド・クラーク、エドEllesson、ポールファーガソン、ユハHeinanen、ヴァン・ジェーコブソン、カレビKilkki、キャサリーン・ニコルズ、ウォルター・ウィス、ジョンWroclawski、およびLixiaチャンによる以前の草稿の利益を得ました。
The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould- Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill, James Fu, and Bob Braden.
作者は彼らの役に立つコメントと提案のために以下の個人を承認したがっています: ハミド・オールドブライアン大工(コンスタンチノスDovrolis)のキャサリーン・ニコルズ、Shivkumar Kalyana、武昌フォン、マーティボーデン、ヨラムBernet、ロナルドBonica、ジェームスBinder、Borje Ohlman、アレッシオ・カサーティ、スコット縁、カーティスVillamizar、Brahi、アンドリュー・スミス、ジョン・レンウィック、ヴェルナーAlmesberger、アラン・オニール、ジェームス・フー、およびボブ・ブレーデン。
Blake, et. al. Informational [Page 32] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[32ページ]のRFC2475アーキテクチャ
8. References
8. 参照
[802.1p] ISO/IEC Final CD 15802-3 Information technology - Tele-
communications and information exchange between systems -
Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC)
bridges, (current draft available as IEEE P802.1D/D15).
[802.1p]ISO/IEC Final CD15802-3情報技術--テレビシステムの間のコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: メディアAccess Control(MAC)ブリッジ、(IEEE P802.1D/D15として利用可能な現在の草稿。)
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-
0056.000>, ATM Forum, April 1996.
[気圧]気圧輸送管理仕様バージョン4.0<af-tm-0056.000>、気圧フォーラム、1996年4月。
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K.
Nichols, and M. Speer, "A Framework for Use of RSVP with
Diff-serv Networks", Work in Progress.
R.Yavatkar、P.フォード、F.ベイカー、L.チャン、K.ニコルズ、およびM.シュペーア、「デフ-servネットワークとのRSVPの使用のためのフレームワーク」という[Bernet]Y.Bernetは進行中で働いています。
[DSFIELD] 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.
[DSFIELD]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort
Packet Delivery Service", IEEE/ACM Trans. on Networking,
vol. 6, no. 4, August 1998, pp. 362-373.
[EXPLICIT] Networking、vol.6、No.4、1998年8月、ページのD.クラークとW.Fang、「ベストエフォート型パケット配信サービスの明白な配分」(IEEE/ACM Trans) 362-373.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
[FRELAY]ANSI T1S1、「フレームのDSSIコア局面は当てにする」1990年3月。
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、エディタ、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: An Overview", RFC
1633, July 1994.
[RFC1633] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年7月。
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エディタ、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP] ブレーデン、B.、チャン、L.、Berson S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
Blake, et. al. Informational [Page 33] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[33ページ]のRFC2475アーキテクチャ
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
[2ビット] K.ニコルズ、V.ジェーコブソン、およびL.チャン、「インターネットへの安っぽい差別化されたサービスアーキテクチャ」、 ftp://ftp.ee.lbl.gov/papers/dsarch.pdf 、1997年11月。
[TR] ISO/IEC 8802-5 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 5: Token Ring Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.5-
1995), 1995.
[TR]ISO/IEC8802-5情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート5: トークンリングアクセス法と物理的な層の仕様、(ANSI/IEEE Std802.5- 1995も)、1995
Authors' Addresses
作者のアドレス
Steven Blake Torrent Networking Technologies 3000 Aerial Center, Suite 140 Morrisville, NC 27560
スティーブンブレーク急流ネットワーク・テクノロジー3000の空中センター、140Morrisville、Suite NC 27560
Phone: +1-919-468-8466 x232 EMail: slblake@torrentnet.com
以下に電話をしてください。 +1-919-468-8466 x232 EMail: slblake@torrentnet.com
David L. Black EMC Corporation 35 Parkwood Drive Hopkinton, MA 01748
デヴィッド・L.の黒いEMC社35のParkwood Driveホプキントン、MA 01748
Phone: +1-508-435-1000 x76140 EMail: black_david@emc.com
以下に電話をしてください。 +1-508-435-1000 x76140 EMail: black_david@emc.com
Mark A. Carlson Sun Microsystems, Inc. 2990 Center Green Court South Boulder, CO 80301
マークA.カールソンサン・マイクロシステムズ・インク2990のセンターのグリーンコートの南ボウルダー、CO 80301
Phone: +1-303-448-0048 x115 EMail: mark.carlson@sun.com
以下に電話をしてください。 +1-303-448-0048 x115 EMail: mark.carlson@sun.com
Elwyn Davies Nortel UK London Road Harlow, Essex CM17 9NA, UK
Elwynデイヴィース・ノーテルイギリスのロンドン街道ハーロー、エセックスCM17 9NAイギリス
Phone: +44-1279-405498 EMail: elwynd@nortel.co.uk
以下に電話をしてください。 +44-1279-405498はメールされます: elwynd@nortel.co.uk
Blake, et. al. Informational [Page 34] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[34ページ]のRFC2475アーキテクチャ
Zheng Wang Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
ツェンワングベル研究所ルーセントテクノロジーズ101Crawfordsコーナー道路Holmdel、ニュージャージー 07733
EMail: zhwang@bell-labs.com
メール: zhwang@bell-labs.com
Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100 Concord, MA 01742-2168
ウォルターワイスルーセントテクノロジーズ300ベイカーAvenue、スイート100一致、MA01742-2168
EMail: wweiss@lucent.com
メール: wweiss@lucent.com
Blake, et. al. Informational [Page 35] RFC 2475 Architecture for Differentiated Services December 1998
etブレーク、アル。 差別化されたサービス1998年12月のための情報[35ページ]のRFC2475アーキテクチャ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Blake, et. al. Informational [Page 36]
etブレーク、アル。 情報[36ページ]
一覧
スポンサーリンク
