Network Working Group D. Grossman
Request for Comments: 3260 Motorola, Inc.
Updates: 2474, 2475, 2597 April 2002
Category: Informational
New Terminology and Clarifications for Diffserv
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs.
このメモは、新しい改良用語についてのDiffservワーキンググループ協定を取り込み、そしてマイナーな技術的な明確化を提供します。標準トラック上のRFC 2474、RFC 2475およびRFC 2597ときのRFC 2474および2597の前進を更新するためのものであり、RFC 2475が更新され、それがこのメモでリビジョンが組み込まれることを意図しており、このメモはなること新しいRFCで廃止。
As the Diffserv work has evolved, there have been several cases where terminology has needed to be created or the definitions in Diffserv standards track RFCs have needed to be refined. Some minor technical clarifications were also found to be needed. This memo was created to capture group agreements, rather than attempting to revise the base RFCs and recycle them at proposed standard. It updates in part RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been obsoleted by RFC 3246, and clarifications agreed by the group were incorporated in that revision.
Diffservの作業が進化したように、用語を作成する必要があったかDiffservの基準の定義はRFCが洗練される必要があった追跡いくつかの例がありました。いくつかのマイナーな技術の明確化も必要になることが判明しました。このメモは、むしろベースのRFCを改訂し、提案された標準でそれらをリサイクルしようとするよりも、グループの契約をキャプチャするために作成されました。これは、一部のRFC 2474に更新し、RFC 2475およびRFC 2597 RFC 2598は、RFC 3246で廃止された、およびグループによって合意された明確化は、そのリビジョンに組み込まれました。
The Diffserv Architecture [2] uses the term "Service Level Agreement" (SLA) to describe the "service contract... that specifies the forwarding service a customer should receive". The SLA may include traffic conditioning rules which (at least in part) constitute a Traffic Conditioning Agreement (TCA). A TCA is "an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply...."
Diffservのアーキテクチャは、[2]「サービス契約...顧客が受けるべき転送サービスを指定する」を記載する用語「サービスレベルアグリーメント」（SLA）を使用しています。 SLAは、（少なくとも部分的に）トラフィックコンディショニング契約（TCA）を構成するトラフィック調整ルールを含んでもよいです。 TCAは、「廃棄及び/又は適用される規則を整形、マーキング、分類子ルール及び任意の対応するトラフィックプロファイルおよび計量を指定する契約...」であります
As work progressed in Diffserv (as well as in the Policy WG [6]), it came to be believed that the notion of an "agreement" implied considerations that were of a pricing, contractual or other business nature, as well as those that were strictly technical. There also could be other technical considerations in such an agreement (e.g., service availability) which are not addressed by Diffserv. It was therefore agreed that the notions of SLAs and TCAs would be taken to represent the broader context, and that new terminology would be used to describe those elements of service and traffic conditioning that are addressed by Diffserv.
仕事はDiffservの中で進むにつれて（だけでなく、ポリシーWGに[6]）、それが価格設定であった「合意」暗黙の考慮事項、契約上またはその他のビジネス自然だけでなく、それらの概念と考えられるようになりました厳密に技術的でした。また、このような契約の他の技術的な考慮事項があるかもしれません（例えば、サービスの可用性）のDiffservによって対処されていません。したがって、SLAとのTCAの概念がより広い文脈を表現するために取られるでしょう、そしてその新しい用語がDiffservのことで対処しているサービスやトラフィックコンディショニングのそれらの要素を記述するために使用されることが合意されました。
- A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain.
- サービス・レベル仕様（SLS）は、一緒にDSドメインによってトラフィックストリームに提供されるサービスを定義するパラメータとその値のセットです。
- A Traffic Conditioning Specification (TCS) is a set of parameters and their values which together specify a set of classifier rules and a traffic profile. A TCS is an integral element of an SLS.
- トラフィックコンディショニング仕様（TCS）は、一緒に分類器規則のセットとトラフィック・プロファイルを指定するパラメータとその値のセットです。 TCSはSLSの不可欠な要素です。
Note that the definition of "Traffic stream" is unchanged from RFC 2475. A traffic stream can be an individual microflow or a group of microflows (i.e., in a source or destination DS domain) or it can be a BA. Thus, an SLS may apply in the source or destination DS domain to a single microflow or group of microflows, as well as to a BA in any DS domain.
「トラフィックストリーム」の定義は、RFC 2475.からのトラフィック・ストリームは、個々のマイクロまたは（すなわち、送信元または宛先DSドメイン内の）マイクロフローの基であり得るか、BAであってもよい不変であることに留意されたいです。したがって、SLSは、マイクロフローの単一のマイクロフローまたはグループに、ならびに任意のDSドメインにおけるBAに送信元または送信先DSドメインに適用することができます。
Also note that the definition of a "Service Provisioning Policy" is unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning Policy as "a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services." According to one definition given in RFC 3198 [6], a policy is "...a set of rules to administer, manage, and control access to network resources". Therefore, the relationship between an SLS and a service provisioning policy is that the latter is, in part, the set of rules that express the parameters and range of values that may be in the former.
また、RFC 2475は、トラフィックコンディショナーはDS境界ノード上で構成されているか、トラフィックストリームがDSの行動にどのようにマッピングされるかを定義するポリシー「としてサービスプロビジョニングポリシー」を定義する「サービスプロビジョニングポリシー」の定義はRFC 2475.から変更されていないことに注意してくださいサービスの範囲を達成するために凝集体。「RFC 3198に指定された一つの定義によれば、[6]、ポリシーが」...ルールのセットは、管理、管理、およびネットワークリソースへのアクセスを制御する」との間のため、関係SLSおよびポリシープロビジョニングサービスは、後者は、部分的には、前者であってもよく、パラメータおよび値の範囲を表現するルールのセットであることです。
Further note that this definition is more restrictive than that in RFC 3198.
また、この定義は、RFC 3198のそれよりも制限であることに注意してください。
RFC 2475 defines a Per-hop behavior (PHB) group to be:
RFC 2475は、あることがホップ単位動作（PHB）グループを定義します。
"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に適用による共通の制約にのみ有意に指定すると同時に実施することができる1つのまたは複数のPHBのセット。PHBグループができるサービス・ビルディング・ブロックを提供します一緒に指定することに関連する転送動作のセット（例えば、4滴の優先順位）。単一PHBはPHBグループの特別な場合です。」
One standards track PHB Group is defined in RFC 2597 [3], "Assured Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding behavior with some assigned level of queuing resources and three drop precedences. An AF PHB Group consists of three PHBs, and uses three Diffserv Codepoints (DSCPs).
一つの基準はPHBグループは、RFC 2597 [3]、「保証転送PHBグループ」に定義されているトラック。保証転送（AF）は、キューイングリソース三の廃棄優先順位のいくつかの割り当てレベルの挙動を転送するタイプです。 AF PHBグループ三件のPHBから成り、3つのDiffservのコードポイント（DSCPを）を使用します。
RFC 2597 defines twelve DSCPs, corresponding to four independent AF classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class is one instance of an AF PHB Group.
RFC 2597は、4つの独立したAFクラスに対応する、12個のDSCPを定義します。 AFクラスはAF1x、AF2x、AF3x、及びAF4xと呼ばれる（ 'X' のドロップ優先順位を表すために1、2、または3です）。各AFクラスは、AF PHBグループの1つのインスタンスです。
There has been confusion expressed that RFC 2597 refers to all four AF classes with their three drop precedences as being part of a single PHB Group. However, since each AF class operates entirely independently of the others, (and thus there is no common constraint among AF classes as there is among drop precedences within an AF class) this usage is inconsistent with RFC 2475. The inconsistency exists for historical reasons and will be removed in future revisions of the AF specification. It should now be understood that AF is a _type_ of PHB group, and each AF class is an _instance_ of the AF type.
混乱がありましたRFC 2597は、単一のPHBグループの一部であるとして、その三の廃棄優先順位を持つすべての4つのAFクラスを参照していることを表明しました。この使用は、RFC 2475.と矛盾している各AFクラスは、完全に独立して他の動作（及びAFクラス内の廃棄優先順位間であるように、したがってAFクラスの間で共通の制約がない）ので、矛盾は歴史的な理由のために存在してAF仕様の将来の改訂で削除されます。今AFはPHBグループの_type_であり、各AFクラスはAF型の_instance_であることを理解すべきです。
Authors of new PHB specifications should be careful to adhere to the RFC 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB specifications from assigning enough DSCPs to represent multiple independent instances of their PHB Group. However, such a set of DSCPs must not be referred to as a single PHB Group.
新しいPHB仕様の著者はPHBグループのRFC 2475の定義に準拠するように注意する必要があります。 RFC 2475には、彼らのPHBグループの複数の独立したインスタンスを表現するために十分なのDSCPを割り当てることから、新たなPHBの仕様を禁止していません。しかし、DSCPをのようなセットは、単一のPHBグループと呼ばれてはなりません。
Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 header, respectively, to the DS field. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bits.
DiffServはPHBを選択するのDiffServコードポイント（DSCP）を、伝達するためにIPv4またはIPv6ヘッダの6ビットを使用します。 RFC 2474の試みは、DSフィールドに、それぞれ、IPv4ヘッダのTOSオクテットの名前を変更し、IPv6ヘッダのトラフィッククラスオクテットします。 DSフィールドは、6ビットのDiffservコードポイントと二つの「現在未使用」ビットを有します。
It has been pointed out that this leads to inconsistencies and ambiguities. In particular, the "Currently Unused" (CU) bits of the DS Field have not been assigned to Diffserv, and subsequent to the publication of RFC 2474, they were assigned for explicit congestion notification, as defined in RFC 3168 [4]. In the current text, a DSCP is, depending on context, either an encoding which selects a PHB or a sub-field in the DS field which contains that encoding.
矛盾と曖昧につながることが指摘されています。具体的には、DSフィールドの「現在未使用」（CU）ビットのDiffservに割り当てられていない、およびRFC 3168で定義されているRFC 2474の刊行以降は、それらが[4]、明示的輻輳通知のために割り当てられました。現在のテキストでは、DSCPのいずれか、文脈に応じて、その符号化が含まDSフィールドのPHBまたはサブフィールドを選択する符号化です。
The present text is also inconsistent with BCP 37, IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field are superseded by the 6 bit DS field and a 2 bit CU field. The IANA allocates values in the DS field following the IANA considerations section in RFC 2474, as clarified in section 8 of this memo.
現在のテキストは、[5]、また、インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドラインBCP 37と矛盾しています。 IPV4タイプオブサービス（TOS）フィールドとIPv6のトラフィッククラスフィールドは、6ビットのDSフィールドと2ビットのCUフィールドによって置き換えされます。 IANAは、このメモのセクション8で明らかなように、RFC 2474でIANAの考慮事項のセクション以下のDSフィールドに値を割り当てます。
The consensus of the DiffServ working group is that BCP 37 correctly restates the structure of the former TOS and traffic class fields.
DiffServのワーキンググループのコンセンサスはBCP 37が正しく元TOSおよびトラフィッククラスフィールドの構造を修正再表示ということです。
Therefore, for use in future documents, including the next update to RFC 2474, the following definitions should apply:
したがって、RFC 2474に、次の更新を含め、今後の文書、で使用するために、以下の定義を適用する必要があります。
- the Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet.
- 差別化されたサービス分野（DSFIELD）は、（旧）IPV4 TOSオクテットまたは（旧）IPV6トラフィッククラスオクテットの上位6ビットです。
- the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards.
- 差別化サービスコードポイント（DSCP）は、DSフィールドに符号化された値であり、かつ各DSノードは各パケット転送それによって経験されるPHBを選択するために使用しなければなりません。
The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv.
IPV4 TOSオクテットとIPv6のトラフィッククラスオクテットの2つの最下位ビットは、Diffservのによって使用されません。
When RFC 2474 is updated, consideration should be given to changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor).
RFC 2474が更新されると、考慮すべきことは、「明示的輻輳通知（ECN）」を指定「現在未使用（CU）」を変更し、RFC 3168（またはその後継）を参照に与えられるべきです。
The update should also reference BCP 37.
更新はまた、BCP 37を参照すべきです。
Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to the realization that a concept was needed in Diffserv to capture the notion of a set of BAs with a common ordering constraint. This presently applies to AF behavior aggregates, since a DS node may not reorder packets of the same microflow if they belong to the same AF class. This would, for example, prevent an MPLS LSR, which was also a DS node, from discriminating between packets of an AF Behavior Aggregate (BA) based on drop precedence and forwarding packets of the same AF class but different drop precedence over different LSPs. The following new terms are defined.
MPLSラベルでのDiffservサポートの作業はルータ（LSRのを）スイッチ概念は、共通の順序制約付きのBAの集合の概念をキャプチャするDiffservの中で必要とされた実現につながりました。彼らは同じAFのクラスに属している場合、DSノードは同じマイクロフローのパケットの順序を変更しない場合がありますので、これは現在、AFの挙動集合体に適用されます。これは、例えば、ドロップ優先順位に基づいて、AF動作集約（BA）のパケットを区別し、異なるのLSP上同じAFクラスが、異なる廃棄優先順位のパケットを転送するよりも、DSノードたMPLS LSRを、防止します。次の新しい用語が定義されています。
PHB Scheduling Class: A PHB group for which a common constraint is that, ordering of at least those packets belonging to the same microflow must be preserved.
PHBスケジューリングクラス：一般的な制約は、同じマイクロフローに属する少なくともそれらのパケットの順序が保存されなければならない、ということであるためPHBグループ。
Ordered Aggregate (OA): A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class.
注文した集計（OA）：順序制約を共有する行動凝集体のセット。行動集約のこのセットに適用されているのPHBのセットは、PHBスケジューリングクラスを構成しています。
Several implementors have pointed out ambiguities or conflicts in the Diffserv RFCs concerning behavior when a DS-node receives a packet with a DSCP which it does not understand.
いくつかの実装は、DS-ノードが、それは理解していないDSCPを持つパケットを受信したときの挙動についてのDiffserv RFCで曖昧さや矛盾を指摘しています。
RFC 2475 states: "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]."
RFC 2475本の状態：「進入ノードはDSコードポイントが許容可能であることを保証するために、他のすべての着信トラフィックを調整する必要があり、許容できないコードポイントを有することが見出されたパケットを廃棄しなければならないのいずれかまたは転送される前に、許容可能な値に変更それらのDSコードポイントを持っている必要があり、例えば、AN。何の拡張サービス契約が存在しないと、ドメインからのトラフィックを受信した入口ノードは、DSは[DSFIELD]デフォルトPHBコードポイントにコードポイントリセットされることがあります。」
On the other hand, RFC 2474 states: "Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed."
「（4秒を参照してください。）パケットが認識されていないコードポイントを受け取った彼らはデフォルトの動作のためにマークされたかのように転送されるべきであり、そのコードポイントを変更すべきではありません。」：一方で、RFC 2474で述べて
RFC 2474 is principally concerned with DS-interior nodes. However, this behavior could also be performed in DS-ingress nodes AFTER the traffic conditioning required by RFC 2475 (in which case, an unrecognized DSCP would occur only in the case of misconfiguration). If a packet arrives with a DSCP that hadn't been explicitly mapped to a particular PHB, it should be treated the same way as a packet marked for Default. The alternatives were to assign it another PHB, which could result in misallocation of provisioned resources, or to drop it. Those are the only alternatives within the framework of RFC 2474. Neither alternative was considered desirable. There has been discussion of a PHB which receives worse service than the default; this might be a better alternative. Hence the imperative was "SHOULD" rather than "SHALL".
RFC 2474は、DS-内部ノードと、主に懸念しています。しかし、この現象はまた、RFC 2475によって要求されるトラフィックコンディショニングの後DS-入口ノードで実行することができる（この場合、認識されていないDSCPは、設定ミスの場合に生じるであろう）。パケットが明示的に特定のPHBにマッピングされていなかったDSCPで到着した場合、それがデフォルトのためにマークされたパケットと同じように扱われるべきです。選択肢はそれをプロビジョニングされたリソースの不適切な配分につながる可能性が別のPHBを割り当てるために、またはそれをドロップすることでした。これらはどちらも代替が望ましいと考えられたRFC 2474の枠組みの中で唯一の選択肢です。デフォルトよりも悪いサービスを受けるPHBの議論がありました。これは、より良い選択肢かもしれません。したがって、不可欠では「SHOULD」ではなく「SHALL」でした。
The intent of RFC 2475 clearly concerns DS-ingress nodes, or more precisely, the ingress traffic conditioning function. This is another context where the "SHOULD" in RFC 2474 provides the flexibility to do what the group intended. Such tortured readings are not desirable.
RFC 2475の意図は明確に、より正確に入力トラフィック調整機能をDS-イングレスノードに関する、または。これは、「SHOULD」はRFC 2474でグループが意図したもの行うための柔軟性を提供し、別のコンテキストです。このような拷問を受けた測定値は望ましいものではありません。
Therefore, the statement in RFC 2474 will be clarified to indicate that it is not intended to apply at the ingress traffic conditioning function at a DS-ingress node, and cross reference RFC 2475 for that case.
したがって、RFC 2474内のステートメントは、DS-入口ノードにおける入力トラフィック調整機能に適用することを意図していないことを示すために、明らかに、その場合の相互参照RFC 2475であろう。
There was a similar issue, which manifested itself with the first incarnation of Expedited Forwarding (EF). RFC 2598 states:
緊急転送（EF）の最初の化身で自分自身を明らかに同様の問題がありました。 RFC 2598本の状態：
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. (This rate must be <= the EF PHB configured rate.) Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all EF marked packets).
サービス拒否攻撃から自身を保護するために、DSドメインのエッジは、厳密に警察のすべてのEFは、隣接する上流のドメインと交渉レートにパケットをマークしなければなりません。ネゴシエートされたレートを超える（このレートは、<= EF PHB構成率でなければならない。）パケットは廃棄されなければなりません。隣接する二つのドメインがEF率を交渉していない場合、下流のドメインがレート（すなわち、すべてのEFマーキングされたパケットをドロップ）として0を使用しなければなりません。
The problem arose in the case of misconfiguration or routing problems. An egress DS-node at the edge of one DS-domain forwards packets to an ingress DS-node at the edge of another DS domain. These packets are marked with a DSCP that the egress node understands to map to EF, but which the ingress node does not recognize. The statement in RFC 2475 would appear to apply to this case. RFC 3246 [7] clarifies this point.
問題は、設定ミスやルーティングの問題の場合に生じました。 1 DSドメインのエッジで出力DSノードは、別のDSドメインのエッジで入力DS-ノードにパケットを転送します。これらのパケットは、出口ノードは、EFにマッピングするために理解しますが、入口ノードが認識しないことをDSCPでマークされます。 RFC 2475での声明は、この場合に適用されますように思われます。 RFC 3246 [7]この点を明確にしています。
At least one implementor has expressed confusion about the relationship of the DSField, as defined in RFC 2474, to the use of the TOS bits, as described in RFC 1349. The RFC 1349 usage was intended to interact with OSPF extensions in RFC 1247. These were never widely deployed and thus removed by standards action when STD 54, RFC 2328, was published. The processing of the TOS bits is described as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. RFC 2474 states:
RFC 2474で定義されるように少なくとも一つの実装は、RFC 1349に記載されているようにRFC 1349が使用RFC 1247でOSPF拡張でこれらと相互作用することを意図した、TOSビットの使用、DSFIELDの関係について混乱を表明しています広く展開しないので、STD 54、RFC 2328は、出版されたときの標準アクションによって除去んでした。 TOSビットの処理は、RFC 1812年要件として記載されている[8] RFC 1122 [9]およびRFC 1123 [10]。 RFC 2474本の状態：
"No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",
「[RFC791]で定義されるように、またはIPv4のTOSオクテットのTOSビット。 『DTR』試みはとの下位互換性を維持するようになされていません」、
In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For completeness, when RFC 2474 is updated, the sentence should read:
また、RFC 2474は、IESGの作用により、RFC 1349を廃止します。 RFC 2474が更新されると完全にするために、文章を読んでください。
"No attempt is made to maintain backwards compatibility with the "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and [RFC1349]. This implies that TOS bit processing as described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted by this memo. Also see [RFC2780]."
[RFC791]と[RFC1349]で定義されるように、DTR / MBZ 『又はIPv4のTOSオクテットのTOSビット「いいえ試みがとの後方互換性を維持するようになされていない』。これは、[RFC1812]に記載されているように、そのTOSビット処理を、[暗示しますRFC1122]と[RFC1123]も、このメモで廃止される。また、[RFC2780]を参照してください。」
IANA has requested clarification of a point in RFC 2474, concerning registration of experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6:
IANAは、実験/ローカル利用のDSCPの登録に関する、RFC 2474でのポイントの明確化を要求しました。 RFC 2474が改訂された場合、以下は第6章を追加する必要があります。
IANA is requested to maintain a registry of RECOMMENDED DSCP values assigned by standards action. EXP/LU values are not to be registered.
IANAは標準アクションによって割り当てられた推奨DSCP値のレジストリを維持することが要求されています。 EXP / LU値が登録されてはなりません。
The following standards track and informational RFCs are expected to be updated to reflect the agreements captured in this memo. It is intended that these updates occur when each standards track RFC progresses to Draft Standard (or if some issue arises that forces recycling at Proposed). RFC 2475 is expected to be updated at about the same time as RFC 2474. Those updates will also obsolete this memo.
以下の規格トラックおよび情報のRFCは、このメモで撮影し合意を反映するように更新されることが期待されます。それぞれの規格はRFC標準のドラフトに進む追跡する場合、これらの更新が発生することが意図されている（またはいくつかの問題が勢力提案でリサイクルという問題が生じる場合）。 RFC 2475は、これらの更新プログラムは、このメモRFC 2474とほぼ同時に更新する時代遅れもが期待されます。
RFC 2474: revise definition of DS field. Clarify that the suggested default forwarding in the event of an unrecognized DSCP is not intended to apply to ingress conditioning in DS-ingress nodes. Clarify effects on RFC 1349 and RFC 1812. Clarify that only RECOMMENDED DSCPs assigned by standards action are to be registered by IANA.
RFC 2474：DSフィールドの改訂定義。認識されていないDSCPのイベントで推奨デフォルトの転送はDS-イングレスノードに進入コンディショニングに適用することを意図されていないことを明確にします。標準アクションによって割り当てられた唯一の推奨のDSCPは、IANAによって登録されることを明確にRFC 1349およびRFC 1812への影響を明確にします。
RFC 2475: revise definition of DS field. Add SLS and TCS definitions. Update body of document to use SLS and TCS appropriately. Add definitions of PHB scheduling class and ordered aggregate.
RFC 2475：DSフィールドの改訂定義。 SLSとTCSの定義を追加します。適切SLSとTCSを使用するために文書の本文を更新します。 PHBスケジューリングクラスの定義を追加し、集計を命じました。
RFC 2497: revise to reflect understanding that, AF classes are instances of the AF PHB group, and are not collectively a PHB group.
RFC 2497：AFクラスはAFのPHBグループのインスタンスである、と総称PHBグループではない、という理解を反映するために改訂。
In addition, RFC 3246 [7] has added a reference to RFC 2475 in the security considerations section to cover the case of a DS egress node receiving an unrecognized DSCP which maps to EF in the DS ingress node.
また、RFC 3246 [7] DSイングレスノードにEFにマッピング認識されていないDSCPを受信DS出口ノードの場合をカバーするために、セキュリティ問題部にRFC 2475への参照を追加しました。
Security considerations are addressed in RFC 2475.
セキュリティに関する考慮事項は、RFC 2475で対処されています。
Acknowledgements
謝辞
This memo captures agreements of the Diffserv working group. Many individuals contributed to the discussions on the Diffserv list and in the meetings. The Diffserv chairs were Brian Carpenter and Kathie Nichols. Among many who participated actively in these discussions were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea Westerinen provided valuable editorial comments.
このメモはDiffservのワーキンググループの合意をキャプチャします。多くの個人は、Diffservのリストに、会議での議論に貢献しました。 Diffservの椅子は、ブライアン・カーペンターとキャシーニコルズました。これらの議論に積極的に参加した多くの人々の中でロイド・ウッド、ユハHeinanen、グレンヴィルアーミテージ、スコット・ブリム、Sharam Davari、デビッド・ブラック、ジェラルドGastaud、ジョエル・ハルパーン、ジョンSchnizlein、フランソワ・ル・Faucheur、そしてフレッドベイカーでした。マイク・エアーズ、マイク聞いて、アンドレアWesterinenは貴重な編集コメントを提供しました。
Normative References
引用規格
[1] 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.
[1]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[2]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[3] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wrocklawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[4] Ramakrishnan, K., Floyd, S. and D. Black "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[4]ラマクリシュナン、K.、フロイド、S.及びD.黒 "の明示的輻輳通知の添加（ECN）をIPに"、RFC 3168、2001年9月。
[5] Bradner, S. and V. Paxon, "IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers", BCP 37, RFC2780, March 2000.
[5]ブラドナー、S.とV. Paxon、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC2780、2000年3月を。
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[6] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、およびS. Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[7]デイビー、B.、Charny、A.、ベイカー、F.、ベネット、JCR、ベンソン、K.、ルBoudec、J.、チウ、A.、コートニー、W.、Cavari、S.、Firoiu、 V.、Kalmanek、C.、Ramakrishnam、K.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）"、RFC 3246、2002年3月。
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[8]ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[9] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[9]ブレーデン、R.、 "インターネットホストのための要件 - 通信レイヤー"、STD 3、RFC 1122、1989年10月。
[10] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[10]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
Author's Address
著者のアドレス
Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048
ダン・グロスマンモトローラ社20カボットブルバードマンスフィールド、MA 02048
EMail: dan@dma.isg.mot.com
メールアドレス：dan@dma.isg.mot.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。