[要約] RFC 3260は、Diffserv（Differentiated Services）に関する新しい用語と明確化を提供するためのものです。その目的は、Diffservの実装と運用の向上を促進することです。
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
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.
Copyright（c）The Internet Society（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を更新することを目的としています。RFCS2474および2597が標準トラックで進歩し、RFC 2475が更新されると、このメモの改訂が組み込まれ、このメモはこのメモが組み込まれます。新しいRFCSによって廃止されました。
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で更新されます。RFC2598は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...."
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ドメインに単一のマイクロフローまたはマイクロフローのグループ、および任意のDSドメインのBAに適用される場合があります。
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から変更されていないことに注意してください。RFC2475は、「サービス提供ポリシー」をDS境界ノードで構成する方法と、トラフィックストリームのマッピング方法をDSの動作に定義するポリシーとして定義しています。RFC 3198 [6]に記載されている1つの定義によれば、ポリシーは「...ネットワークリソースへのアクセスを管理、管理、制御するための一連のルール」です。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).
1つの標準トラックPHBグループは、RFC 2597 [3]で定義されています。「保証されたPHBグループ」。Assured Forwarding（AF）は、配分されたレベルのキューリングリソースと3つのドロップの優先順位を持つ、転送動作の一種です。AF PHBグループは3つのPHBで構成され、3つのDiffServ CodePoints（DSCPS）を使用します。
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グループの一部として3つのドロップの優先順位を持つ4つのAFクラスすべてを指しているという混乱が表明されています。ただし、各AFクラスは他のクラスとは完全に独立して動作するため（したがって、AFクラス内にドロップの優先順位があるため、AFクラスの間に共通の制約はありません）。この使用法はRFC 2475と矛盾しています。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グループの複数の独立したインスタンスを表すために、新しいPHB仕様が十分なDSCPを割り当てることを禁止していません。ただし、このような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 CodePoint（DSCP）を伝達するために、IPv4またはIPv6ヘッダーの6ビットを使用します。RFC 2474は、IPv4ヘッダーのTOSオクテットとIPv6ヘッダーのトラフィッククラスOctetの名前をDSフィールドに変更しようとします。DSフィールドには、6ビットDiffServ CodePointと2つの「現在使用されていない」ビットがあります。
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 2474の公開に続いて、RFC 3168 [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.
現在のテキストは、インターネットプロトコルおよび関連するヘッダーの価値に対するIANAの割り当てガイドラインであるBCP 37とも矛盾しています[5]。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.
- 差別化されたサービスCodePoint（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が更新される場合、指定「現在使用されていない（Cu）」を「明示的な輻輳通知（ECN）」に変更し、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ラベルスイッチ付きルーター（LSRS）によるdiffservサポートの作業により、共通の順序付け制約を伴うBASのセットの概念をキャプチャするために、diffservで概念が必要であるという認識が得られました。これは現在、AFの動作集合体に適用されます。DSノードは、同じAFクラスに属している場合、同じマイクロフローのパケットを再注文できないためです。これにより、たとえば、DSノードでもあるMPLS LSRが、同じAFクラスのドロップの優先順位と転送パケットに基づいてAF動作集約（BA）のパケット間を区別することができなくなりますが、異なるLSPで異なるドロップの優先順位を妨げます。次の新しい用語が定義されています。
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 RFCSのあいまいさまたは競合を指摘しています。
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コードポイントを転送する前に許容値に変更する必要があります。たとえば、たとえば、拡張されたサービス契約が存在しないドメインからトラフィックを受信するIngressノードは、DS CodePointをデフォルトのPHB CodePoint [DSField]にリセットする場合があります。
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."
一方、RFC 2474は次のように述べています。「認識されていないコードポイントで受信されたパケットは、デフォルトの動作に対してマークされているかのように転送する必要があり（セクション4を参照）、コードポイントは変更しないでください。」
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の議論があります。これはより良い選択肢かもしれません。したがって、命令は「そうする」のではなく「すべき」でした。
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-Indressノード、またはより正確には、イングレストラフィックコンディショニング機能に関するものです。これは、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-indressノードのイングレストラフィックコンディショニング機能に適用されないことを示すために明確になり、その場合は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構成レートでなければなりません。）ネゴシエートレートを超えるパケットを削除する必要があります。2つの隣接するドメインがEFレートをネゴシエートしていない場合、ダウンストリームドメインはレートとして0を使用する必要があります（つまり、すべてのEFマークされたパケットをドロップします）。
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.
問題は、誤解やルーティングの問題の場合に発生しました。あるDS-Domainの端にある脱出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で説明されているように、少なくとも1人の実装者がDSFieldの関係について混乱を表明しています。RFC1349の使用は、RFC 1247のOSPF拡張機能と相互作用することを目的としていました。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オクテットの「DTR」またはTOSビットとの逆方向の互換性を維持する試みは行われません。」
In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For completeness, when RFC 2474 is updated, the sentence should read:
さらに、IESGアクションによるRFC 2474 OBTOLETES 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]で定義されているように、IPV4 TOSオクテットの「DTR/MBZ」または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-insressノードのイングレスコンディショニングに適用することを意図していないことを明確にします。RFC 1349およびRFC 1812の効果を明確にします。標準訴訟によって割り当てられた推奨されるDSCPのみがIANAによって登録されることを明確にします。
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とTCを適切に使用します。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 GERSRESSノードのEFにマップする認識されていないDSCPを受信するDS Egressノードのケースをカバーするために、セキュリティに関する考慮事項セクションに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の椅子は、ブライアンカーペンターとキャシーニコルズでした。これらの議論に積極的に参加した多くの人の中には、ロイド・ウッド、ジュハ・ハイナネン、グレンビル・アーミテージ、スコット・ブリム、シャラム・ダバリ、デビッド・ブラック、ジェラルド・ガストー、ジョエル・ハルパーン、ジョン・シュニズレイン、フランソワ・ル・ファウチュール、フレッド・ベイカーがいました。マイク・エアーズ、マイク・ハード、アンドレア・ウェステリネンは貴重な編集コメントを提供しました。
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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、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.、Baker、F.、Weiss、W。and J. Wrocklawski、「Assured Forwarding PHB Group」、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] Ramakrishnan、K.、Floyd、S。and D. Black「IPへの明示的な混雑通知（ECN）の追加」、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] Bradner、S。and 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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J. and 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] 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。、およびD. Stiliadis、「迅速な転送PHB（Hop Behavior）」、RFC 3246、2002年3月。
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[8] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[9] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[9] Braden、R。、「インターネットホストの要件 - 通信層」、STD 3、RFC 1122、1989年10月。
[10] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[10] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Author's Address
著者の連絡先
Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048
Dan Grossman Motorola、Inc。20 Cabot Blvd.マンスフィールド、マサチューセッツ州02048
EMail: dan@dma.isg.mot.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。