[要約] RFC 9435 は、新しい推奨される異なるサービスコードポイント（DSCP）の割り当てに関する考慮事項を議論し、インターネット経路上でDiffservフィールドが受ける一般的な再マーキング動作を考慮しています。このRFCの目的は、特定のDSCPを使用する際のいくつかの影響を指摘することです。
Internet Engineering Task Force (IETF) A. Custura
Request for Comments: 9435 G. Fairhurst
Category: Informational R. Secchi
ISSN: 2070-1721 University of Aberdeen
July 2023
This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standard Per-Hop Behavior (PHB). It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along an Internet path. It also notes some implications of using a specific DSCP.
このドキュメントでは、標準的なホップごとの動作（PHB）に新しい推奨差別化されたサービスコードポイント（DSCP）を割り当てるための考慮事項について説明します。それは、DiffServフィールドがインターネットパスに沿って受けられる可能性があるという一般的な観察された再マーク行動を考慮します。また、特定のDSCPを使用することのいくつかの意味を指摘しています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9435.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9435で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Current Usage of DSCPs
3.1. IP-Layer Semantics
3.2. DSCPs Used for Network Control Traffic
4. Re-marking the DSCP
4.1. Bleaching the DSCP Field
4.2. IP Type of Service Manipulations
4.2.1. Impact of ToS Precedence Bleaching
4.2.2. Impact of ToS Precedence Re-marking
4.3. Re-marking to a Particular DSCP
5. Interpretation of the IP DSCP at Lower Layers
5.1. Mapping Specified for IEEE 802
5.1.1. Mapping Specified for IEEE 802.1
5.1.2. Mapping Specified for IEEE 802.11
5.2. Diffserv and MPLS
5.2.1. Mapping Specified for MPLS
5.2.2. Mapping Specified for MPLS Short Pipe
5.3. Mapping Specified for Mobile Networks
5.4. Mapping Specified for Carrier Ethernet
5.5. Re-marking as a Side Effect of Another Policy
5.6. Summary
6. Considerations for DSCP Selection
6.1. Effect of Bleaching and Re-marking to a Single DSCP
6.2. Where the Proposed DSCP > 0x07 (7)
6.2.1. Where the Proposed DSCP&0x07=0x01
6.3. Where the Proposed DSCP <= 0x07 (7)
6.4. Impact on Deployed Infrastructure
6.5. Considerations to Guide the Discussion of a Proposed New
DSCP
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The Differentiated Services (Diffserv) architecture has been deployed in many networks. It provides differentiated traffic forwarding based on the DSCP carried in the Diffserv field of the IP packet header [RFC2474]. A common set of DSCPs are defined for both IPv4 and IPv6, and both network protocols use a common IANA registry [DSCP-registry].
差別化されたサービス（DIFFSERV）アーキテクチャは、多くのネットワークに展開されています。IPパケットヘッダー[RFC2474]のDiffServフィールドに搭載されたDSCPに基づいた差別化されたトラフィック転送を提供します。DSCPの共通セットは、IPv4とIPv6の両方に対して定義され、両方のネットワークプロトコルは共通のIANAレジストリ[DSCP-Registry]を使用します。
Diffserv associates traffic with a service class and categorizes it into Behavior Aggregates (BAs) [RFC4594]. Configuration guidelines for service classes are provided in [RFC4594]. BAs are associated with a DSCP, which in turn maps to a Per-Hop Behavior (PHB). Treatment differentiation can be achieved by using a variety of schedulers and queues and also algorithms that implement access to the physical media.
DiffServは、トラフィックをサービスクラスに関連付け、それを行動集計（BAS）[RFC4594]に分類します。サービスクラスの構成ガイドラインは[RFC4594]に記載されています。BASはDSCPに関連付けられており、DSCPはホップごとの動作（PHB）にマップします。さまざまなスケジュールとキュー、および物理メディアへのアクセスを実装するアルゴリズムを使用することで、治療の分化を実現できます。
Within a Diffserv domain, operators can set Service Level Specifications [RFC3086], each of which maps to a particular Per-Domain Behavior (PDB) that is based on one or more PHBs. The PDB defines which PHB (or set of PHBs) and, hence, for a specific operator, which DSCP (or set of DSCPs) will be associated with specific BAs as the packets pass through a Diffserv domain. It also defines whether the packets are re-marked as they are forwarded (i.e., changing the DSCP of a packet [RFC2475]).
DiffServドメイン内で、演算子はサービスレベルの仕様[RFC3086]を設定できます。それぞれが、1つ以上のPHBに基づく特定のドメインごとの動作（PDB）にマッピングできます。PDBは、PHB（またはPHBのセット）、したがって、特定の演算子に対して、どのDSCP（またはDSCPのセット）がDiffServドメインを通過するときに特定のBASに関連付けられるかを定義します。また、パケットが転送されたときにパケットが再マ化されているかどうか（つまり、パケットのDSCP [RFC2475]の変更）を定義します。
Application -> Service
Traffic Class
|
Behavior -> Diffserv -> Per Hop
Aggregate Codepoint Behavior
|
Schedule,
Queue, Drop
Figure 1: The Role of DSCPs in Classifying IP Traffic for Differential Network Treatment by a Diffserv Node
図1：DIFFSERVノードによる差動ネットワーク処理のためのIPトラフィックの分類におけるDSCPの役割
This document discusses considerations for assigning a new DSCP for a standard PHB. It considers some commonly observed DSCP re-marking behaviors that might be experienced along an Internet path. It also describes some packet forwarding treatments that a packet with a specific DSCP can expect to receive when forwarded across a link or subnetwork.
このドキュメントでは、標準のPHBに新しいDSCPを割り当てるための考慮事項について説明します。インターネットパスに沿って経験される可能性のある一般的に観察されるDSCPの再マーク行動を考慮します。また、特定のDSCPを備えたパケットがリンクまたはサブネットワークに転送されたときに受け取ることが期待できるパケット転送処理についても説明しています。
The document is motivated by new opportunities to use Diffserv end-to-end across multiple domains, such as [NQB-PHB], proposals to build mechanisms using DSCPs in other standards-setting organizations, and the desire to use a common set of DSCPs across a range of infrastructure (e.g., [RFC8622], [NQB-PHB], [AX.25-over-IP]).
このドキュメントは、[NQB-PHB]などの複数のドメインにわたってDIFFSERVエンドツーエンドを使用する新しい機会、他の標準設定組織でDSCPを使用してメカニズムを構築する提案、およびDSCPの共通セットを使用したいという要望に動機付けられています。さまざまなインフラストラクチャ（例：[RFC8622]、[NQB-PHB]、[AX.25-Over-IP]）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
DSCPs are specified in the IANA registry [DSCP-registry], where a variety of different formats are described. A DSCP can sometimes be referred to by name, such as "CS1", and sometimes by a decimal, hex, or binary value. Hex values are represented in text using prefix "0x". Binary values use prefix "0b".
DSCPはIANAレジストリ[DSCP-Registry]で指定されており、さまざまな形式が記載されています。DSCPは、「cs1」などの名前で、時には小数、16進数、またはバイナリ値によって参照される場合があります。六角値は、プレフィックス「0x」を使用してテキストで表されます。バイナリ値はプレフィックス「0B」を使用します。
In this document, the symbol "&" denotes a bitwise AND of two unsigned values.
このドキュメントでは、シンボル "＆"はビットワイズと2つの符号なしの値を示します。
This section describes the current usage of DSCPs.
このセクションでは、DSCPの現在の使用について説明します。
The Diffserv architecture specifies the use of the Diffserv field in the IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. Within a given administrative boundary, each DSCP value can be mapped to a distinct PHB [RFC2474]. When a new PHB is specified, a recommended DSCP value among those 64 values is normally reserved for that PHB and is assigned by IANA. An operator is not formally required to use the recommended value; indeed, [RFC2474] states that "the mapping of codepoints to PHBs MUST be configurable." However, use of the recommended value is usually convenient and avoids confusion.
diffservアーキテクチャは、IPv4およびIPv6パケットヘッダーでDiffServフィールドを使用して、64個の異なるDSCP値のいずれかを運ぶことを指定しています。特定の管理境界内で、各DSCP値は異なるPHB [RFC2474]にマッピングできます。新しいPHBが指定されている場合、これらの64値の間で推奨されるDSCP値は通常、そのPHBのために予約され、IANAによって割り当てられます。オペレーターは、推奨値を使用するために正式に必要はありません。実際、[RFC2474]は、「PHBへのコードポイントのマッピングは構成可能でなければならない」と述べています。ただし、推奨される値の使用は通常便利であり、混乱を避けます。
The DSCP space is divided into three pools for the purpose of assignment and management [DSCP-registry]. A summary of the pools is provided in a table (where 'x' refers to a bit position with value either '0' or '1').
DSCPスペースは、割り当てと管理を目的として3つのプールに分割されます[DSCP-Registry]。プールの概要はテーブルに記載されています（「x」は、値「0」または「1」のいずれかの値のビット位置を指します）。
DSCP Pool 1:
DSCPプール1：
A pool of 32 codepoints with a format of 0bxxxxx0, to be assigned by IANA Standards Action [RFC8126].
IANA標準アクション[RFC8126]によって割り当てられる0BXXXXX0の形式の32コードポイントのプール。
DSCP Pool 2:
DSCPプール2：
A pool of 16 codepoints with a format of 0bxxxx11, reserved for Experimental or Local (Private) Use by network operators (see Sections 4.1 and 4.2 of [RFC8126].
ネットワーク演算子による実験的またはローカル（プライベート）使用のために予約されている0BXXXX11の形式の16コードポイントのプール（[RFC8126]のセクション4.1および4.2を参照してください。
DSCP Pool 3:
DSCPプール3：
A pool of 16 codepoints with a format of 0bxxxx01. This was initially available for Experimental (EXP) Use or Local Use (LU) but was originally specified to be "preferentially utilized for standardized assignments if Pool 1 is ever exhausted" [RFC2474]. Pool 3 codepoints are now "utilized for standardized assignments (replacing the previous availability for experimental or local use)" [RFC8436]. [RFC8622] assigned 0x01 from this pool and consequentially updated [RFC4594]. Any future request to assign 0x05 would be expected to similarly update [RFC4594].
0BXXXX01の形式の16コードポイントのプール。これは最初に実験（EXP）使用またはローカル使用（LU）に利用可能でしたが、もともと「プール1が疲れている場合、標準化された割り当てに優先的に利用される」[RFC2474]を指定していました。プール3コードポイントは、「実験または局所使用のために以前の可用性を置き換える）[RFC8436]に「標準化された割り当てに使用されています」。[RFC8622]このプールから0x01を割り当て、結果として更新された[RFC4594]。0x05を割り当てるという将来の要求は、同様に更新されると予想されます[RFC4594]。
Note that [RFC4594] previously recommended a Local Use of DSCP values 0x01, 0x03, 0x05, and 0x07 (codepoints with the format of 0b000xx1), until this was updated by [RFC8436].
[RFC4594]は、これが[RFC8436]で更新されるまで、以前にDSCP値0x01、0x03、0x05、および0x07（0b000xx1の形式のコードポイント）の局所使用を推奨していたことに注意してください。
The DSCP space is shown in the following table. Each row corresponds to one setting of the first three bits of the DSCP field, and each column to one setting of the last three bits of the DSCP field.
DSCPスペースを次の表に示します。各行は、DSCPフィールドの最初の3ビットの1つの設定に対応し、各列はDSCPフィールドの最後の3ビットの1つの設定に対応します。
+--------+------+---------+----+---------+----+---------+----+
| 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+--------+------+---------+----+---------+----+---------+----+
| 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
+--------+------+---------+----+---------+----+---------+----+
| 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 |
+--------+------+---------+----+---------+----+---------+----+
| 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 |
+--------+------+---------+----+---------+----+---------+----+
| 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 |
+--------+------+---------+----+---------+----+---------+----+
| 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 |
+--------+------+---------+----+---------+----+---------+----+
| 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 |
+========+======+=========+====+=========+====+=========+====+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+========+======+=========+====+=========+====+=========+====+
Table 1: Currently Assigned DSCPs and Their Assigned PHBs
表1：現在割り当てられているDSCPSと割り当てられたPHB
+----+----------------------+-----------+
| CS | Class Selector | [RFC2474] |
+----+----------------------+-----------+
| BE | Best Effort (CS0) | [RFC2474] |
+----+----------------------+-----------+
| AF | Assured Forwarding | [RFC2597] |
+----+----------------------+-----------+
| EF | Expedited Forwarding | [RFC3246] |
+----+----------------------+-----------+
| VA | Voice Admit | [RFC5865] |
+----+----------------------+-----------+
| LE | Lower Effort | [RFC8622] |
+----+----------------------+-----------+
Table 2: Abbreviations for DSCPs and PHB Groups
表2：DSCPおよびPHBグループの略語
Table 2 summarizes the DSCP abbreviations used in currently published RFCs, [RFC2474] [RFC2597] [RFC3246] [RFC5865] [RFC8622], as described in the IANA registry [DSCP-registry]. The Default PHB is defined in Section 4.1 of [RFC2474]. This provides Best Effort (BE) forwarding, and the recommended DSCP of '000000' (Section 4.2.2.1 of [RFC2474]). This is the lowest value in the set of Class Selector (CS) DSCPs, and hence is also known as "CS0" [DSCP-registry].
表2は、現在公開されているRFCS [RFC2474] [RFC2597] [RFC3246] [RFC5865] [RFC8622]で使用されているDSCPの略語をまとめたものです。デフォルトのPHBは、[RFC2474]のセクション4.1で定義されています。これにより、最善の努力（BE）転送、および「000000」の推奨DSCP（[RFC2474]のセクション4.2.2.1）が提供されます。これは、クラスセレクター（CS）DSCPのセットで最も低い値であるため、「CS0」[DSCP-Registry]としても知られています。
NOTE: [RFC4594] specified a now deprecated use of Class Selector 1 (CS1) as the codepoint for the Lower Effort PHB. [RFC8622] updated [RFC4594] and [RFC8325] and obsoleted [RFC3662], assigning the LE DSCP codepoint to the Lower Effort PHB.
注：[RFC4594]は、より低い努力のPHBのコードポイントとして、クラスセレクター1（CS1）を現在非推奨使用していることを指定しました。[RFC8622]は[RFC4594]および[RFC8325]を更新し、[RFC3662]を廃止し、LE DSCP CodePointを低努力PHBに割り当てました。
The Diffserv architecture allows forwarding treatments to be associated with each DSCP, and the RFC series describes some of these as PHBs. Although DSCPs are intended to identify specific treatment requirements, multiple DSCPs might also be mapped (aggregated) to the same forwarding treatment. DSCPs can be mapped to Treatment Aggregates (TAs) that might result in re-marking (e.g., [RFC5160] suggests Meta-QoS-Classes to help enable deployment of standard end-to-end QoS classes).
Diffservアーキテクチャにより、転送処理を各DSCPに関連付けることができ、RFCシリーズはこれらの一部をPHBとして説明しています。DSCPは特定の治療要件を特定することを目的としていますが、複数のDSCPも同じ転送治療にマッピング（凝集）される可能性があります。DSCPは、リマークにつながる可能性のある処理集合体（TA）にマッピングできます（例：[RFC5160]は、標準のエンドツーエンドQoSクラスの展開を可能にするメタQOSクラスを示唆しています）。
Network control traffic is defined as packet flows that are essential for stable operation of the administered network (see [RFC4594], Section 3). The traffic consists of the network control service class and the OAM service class. This traffic is marked with a value from a set of CS DSCPs. This traffic is often a special case within a provider network, and ingress traffic with these DSCP markings can be re-marked.
ネットワーク制御トラフィックは、管理されたネットワークの安定した動作に不可欠なパケットフローとして定義されます（[RFC4594]、セクション3を参照）。トラフィックは、ネットワーク制御サービスクラスとOAMサービスクラスで構成されています。このトラフィックには、CS DSCPSのセットからの値がマークされています。このトラフィックは、多くの場合、プロバイダーネットワーク内の特別なケースであり、これらのDSCPマークを使用したトラフィックを再マ化することができます。
DSCP CS2 is recommended for the OAM (Operations, Administration, and Maintenance) service class (see [RFC4594], Section 3.3).
DSCP CS2は、OAM（操作、管理、およびメンテナンス）サービスクラスに推奨されます（[RFC4594]、セクション3.3を参照）。
DSCP CS6 is recommended for local network control traffic. This includes routing protocols and OAM traffic that are essential to network operation administration, control, and management. Section 3.2 of [RFC4594] recommends that "CS6 marked packet flows from untrusted sources (for example, end user devices) SHOULD be dropped or remarked at ingress to the Diffserv network".
DSCP CS6は、ローカルネットワーク制御トラフィックに推奨されます。これには、ネットワーク運用管理、制御、および管理に不可欠なルーティングプロトコルとOAMトラフィックが含まれます。[RFC4594]のセクション3.2は、「CS6マークされたパケットフローが信頼できないソース（エンドユーザーデバイスなど）からのマークされたパケットフローを、IngressでDiffServネットワークに削除または紹介する必要がある」ことを推奨しています。
DSCP CS7 is reserved for future use by network control traffic. "CS7 marked packets SHOULD NOT be sent across peering points" [RFC4594], Section 3.1.
DSCP CS7は、ネットワーク制御トラフィックによる将来の使用のために予約されています。「CS7マークされたパケットは、ピアリングポイントを越えて送信しないでください」[RFC4594]、セクション3.1。
Section 4.2.2.2 of [RFC2474] recommends PHBs selected by CS6 and CS7 "MUST give packets a preferential forwarding treatment by comparison to the PHB selected by codepoint '000000'".
[RFC2474]のセクション4.2.2.2は、CS6およびCS7で選択されたPHBを推奨しています。
At the time of writing, there is evidence to suggest CS6 is actively used by network operators for control traffic. A study of traffic at a large Internet Exchange showed around 40% of ICMP traffic carried this mark [IETF115-IEPG]. Similarly, another study found many routers re-mark all traffic, except for packets carrying a DSCP with the format 0b11xxxx (i.e., setting the higher order bits to 0b11, see Section 4.2.1 of this document).
執筆時点では、CS6がコントロールトラフィックのためにネットワークオペレーターが積極的に使用していることを示唆する証拠があります。大規模なインターネット交換でのトラフィックの調査では、ICMPトラフィックの約40％がこのマークを搭載していることが示されました[IETF115-IEPG]。同様に、別の研究では、多くのルーターがすべてのトラフィックを再マークしていることがわかりました。ただし、フォーマット0B11XXXXを使用してDSCPを運ぶパケットを除き（つまり、高次ビットを0B11に設定します。このドキュメントのセクション4.2.1を参照）。
It is a feature of the Diffserv architecture that the Diffserv field of packets can be re-marked at the Diffserv domain boundaries (see Section 2.3.4.2 of [RFC2475]). A DSCP can be re-marked at the ingress of a domain. This re-marking can change the DSCP value used on the remainder of an IP path, or the network can restore the initial DSCP marking at the egress of the domain. The Diffserv field can also be re-marked based on common semantics and agreements between providers at a Diffserv domain boundary. Furthermore, [RFC2474] states that re-marking must occur when there is a possibility of theft or denial-of-service attack.
これは、diffservパケットのフィールドをDiffservドメイン境界に再マ化できることをdiffservアーキテクチャの特徴です（[RFC2475]のセクション2.3.4.2を参照）。DSCPは、ドメインの侵入で再マ化できます。このリマークは、IPパスの残りの部分で使用されるDSCP値を変更するか、ネットワークがドメインの出口で初期のDSCPマーキングを復元することができます。DiffServフィールドは、Diffservドメイン境界でプロバイダー間の共通のセマンティクスと合意に基づいて再マ化することもできます。さらに、[RFC2474]は、盗難やサービス拒否攻撃の可能性がある場合は再マークが発生する必要があると述べています。
A packet that arrives with a DSCP that is not associated with a PHB, results in an "unknown DSCP." A node could receive a packet with an "unexpected DSCP" due to misconfiguration, or because there is no consistent policy in place. The treatment of packets that are marked with an unknown or an unexpected DSCP at Diffserv domain boundaries is determined by the policy for a Diffserv domain. If packets are received that are marked with an unknown or an unexpected DSCP by a Diffserv domain interior node, [RFC2474] recommends forwarding the packet using a default (Best Effort) treatment but without changing the DSCP. This seeks to support incremental Diffserv deployment in existing networks as well as preserve DSCP markings by routers that have not been configured to support Diffserv (see also Section 4.3). [RFC3260] clarifies that this re-marking specified by [RFC2474] is intended for interior nodes within a Diffserv domain. For Diffserv ingress nodes, the traffic conditioning required by [RFC2475] applies first.
PHBに関連付けられていないDSCPで到着するパケットは、「不明なDSCP」になります。ノードは、誤った構成のため、または一貫したポリシーが整っていないため、「予期しないDSCP」を備えたパケットを受信できます。DiffServドメイン境界で未知のまたは予期しないDSCPでマークされたパケットの処理は、DiffServドメインのポリシーによって決定されます。DiffServドメイン内部ノードによって未知のDSCPまたは予期しないDSCPでマークされたパケットが受信された場合、[RFC2474]は、デフォルト（ベストエフェクション）処理を使用してDSCPを変更することなくパケットを転送することをお勧めします。これは、既存のネットワークでの増分DIFFSERV展開をサポートし、DIFFSERVをサポートするように構成されていないルーターによるDSCPマーキングを保持することを目指しています（セクション4.3も参照）。[RFC3260]は、[RFC2474]によって指定されたこの再マークが、DiffServドメイン内の内部ノードを対象としていることを明確にします。Diffserv Ingressノードの場合、[RFC2475]で必要なトラフィックコンディショニングが最初に適用されます。
Reports measuring existing deployments have defined a set of categories for DSCP re-marking [Cus17] [Bar18] in the following seven observed re-marking behaviors:
既存の展開を測定するレポートは、次の7つの観察された再マーク行動で、DSCPの再マーク[CUS17] [BAR18]の一連のカテゴリを定義しました。
Bleach-DSCP:
Bleach-DSCP：
bleaches all traffic (sets the DSCP to zero)
すべてのトラフィックを漂白します（DSCPをゼロに設定します）
Bleach-ToS-Precedence:
Bleach-Tos-Precedence：
set the first three bits of the DSCP field to 0b000 (reset the three bits of the former ToS Precedence field, defined in [RFC0791] and clarified in [RFC1122])
DSCPフィールドの最初の3ビットを0b000に設定します（[RFC0791]で定義され、[RFC1122]で明確にされた前のTOS優先順位フィールドの3ビットをリセット））
Bleach-some-ToS:
漂白剤 - トス：
set the first three bits of the DSCP field to 0b000 (reset the three bits of the former ToS Precedence field), unless the first two bits of the DSCP field are 0b11
DSCPフィールドの最初の2ビットが0B11でない限り、DSCPフィールドの最初の3ビットを0b000に設定します（前のTOS優先フィールドの3ビットをリセット）
Re-mark-ToS:
re-mark-tos：
set the first three bits of the DSCP field to any value different from 0b000 (replace the three bits of the former ToS Precedence field)
DSCPフィールドの最初の3ビットを0b000とは異なる任意の値に設定します（前のTOS優先フィールドの3ビットを置き換えます）
Bleach-low:
漂白剤：
set the last three bits of the DSCP field to 0b000
DSCPフィールドの最後の3ビットを0b000に設定します
Bleach-some-low:
漂白剤-Some-low：
set the last three bits of the DSCP field to 0b000, unless the first two bits of the DSCP field are 0b11
DSCPフィールドの最初の2ビットが0B11でない限り、DSCPフィールドの最後の3ビットを0b000に設定します
Re-mark-DSCP:
re-mark-dscp：
re-marks all traffic to one or more particular (non-zero) DSCP values
すべてのトラフィックを1つ以上の特定の（ゼロ以外）DSCP値に再マークします
These behaviors are explained in the following subsections and cross-referenced in the remainder of the document.
これらの動作は、次のサブセクションで説明され、文書の残りの部分で相互参照されます。
The network nodes forming a particular path might or might not have supported Diffserv. It is not generally possible for an external observer to determine which mechanism results in a specific re-marking solely from the change in an observed DSCP value.
特定のパスを形成するネットワークノードは、diffservをサポートしている場合とサポートしていない場合があります。一般に、外部のオブザーバーは、どのメカニズムが観察されたDSCP値の変化からのみ、特定の再マークをもたらすかを決定することはできません。
NOTE: More than one mechanism could result in the same DSCP re-marking (see below). These behaviors were measured on both IPv4 and IPv6 Internet paths between 2017 and 2021 [Cus17]. IPv6 routers were found to perform all the types of re-marking described above to a lesser extent than IPv4 ones.
注：複数のメカニズムにより、同じDSCPの再マークが発生する可能性があります（以下を参照）。これらの動作は、2017年から2021年の間にIPv4とIPv6インターネットパスの両方で測定されました[CUS17]。IPv6ルーターは、上記のすべてのタイプの再マッキングを実行することがわかった。
A specific form of re-marking occurs when the Diffserv field is re-assigned to the default treatment: CS0 (0x00). This results in traffic being forwarded using the BE PHB. For example, AF31 (0x1a) would be bleached to CS0.
DiffServフィールドがデフォルトの治療に再割り当てされた場合、CS0（0x00）に再編成された場合、特定の形式の再マークが発生します。これにより、BE PHBを使用してトラフィックが転送されます。たとえば、AF31（0x1a）はCS0に漂白されます。
A survey reported that resetting all the bits of the Diffserv field to 0 was seen to be more prevalent at the edge of the network and rather less common in core networks [Cus17].
調査では、Diffservフィールドのすべてのビットを0にリセットすることが、ネットワークの端でより一般的であり、コアネットワークではかなり一般的ではないことが見られたことが報告されています[CUS17]。
The IETF first defined ToS precedence for IP packets in [RFC0791] and updated it to be part of the ToS field in [RFC1349]. Since 1998, this practice has been deprecated by [RFC2474]. [RFC2474] defines DSCPs 0bxxx000 as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the "Class Selector PHB Requirements" described in Section 4.2.2.2 of [RFC2474].
IETFは、[RFC0791]のIPパケットのTOSの優先順位を最初に定義し、[RFC1349]のTOSフィールドの一部に更新しました。1998年以来、この慣行は[RFC2474]によって非推奨されています。[RFC2474]は、DSCPS 0BXXX000をクラスセレクターのコードポイントとして定義します。これらのコードポイントで選択されたPHBは、[RFC2474]のセクション4.2.2.2で説明されている「クラスセレクターPHB要件」を満たす必要があります。
A recent survey reports practices based on ToS semantics have not yet been eliminated from the Internet and need to still be considered when making new DSCP assignments [Cus17].
TOSセマンティクスに基づいた最近の調査報告書は、インターネットからまだ排除されていないため、新しいDSCP割り当てを行う際にまだ考慮する必要があります[CUS17]。
Bleaching of the ToS Precedence field (see Section 4) resets the first three bits of the DSCP field to zero (the former ToS Precedence field), leaving the last three bits unchanged (see Section 4.2.1 of [RFC2474]). A Diffserv node can be configured in a way that results in this re-marking. This re-marking can also occur when packets are processed by a router that is not configured with Diffserv (e.g., configured to operate on the former ToS Precedence field [RFC0791]). At the time of writing, this is a common manipulation of the Diffserv field. The following Figure depicts this re-marking.
TOS優先順位フィールドの漂白（セクション4を参照）は、DSCPフィールドの最初の3ビットをゼロにリセットし（前のTOS優先フィールド）、最後の3ビットを変更せずに残します（[RFC2474]のセクション4.2.1を参照）。DiffServノードは、この再マークをもたらす方法で構成できます。この再マッキングは、diffservで構成されていないルーター（例えば、以前のTOS優先順位フィールド[RFC0791]で動作するように構成されている）でパケットが処理される場合にも発生します。執筆時点では、これはdiffservフィールドの一般的な操作です。次の図は、この再マークを示しています。
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|0 0 0|x x x|
+-+-+-+-+-+-+
Figure 2: Bits in the Diffserv Field Modified by Bleaching of the ToS Precedence
図2：TOSの優先順位の漂白によって変更されたdiffservフィールドのビット
Figure 2 shows bleaching of the ToS Precedence (see Section 4), based on Section 3 of [RFC1349]. The bit positions marked 'x' are not changed.
図2は、[RFC1349]のセクション3に基づくTOSの優先順位の漂白（セクション4を参照）を示しています。「x」とマークされたビット位置は変更されていません。
+--------+------+---------+----+---------+----+---------+----+
| 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+--------+------+---------+----+---------+----+---------+----+
| 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
+--------+------+---------+----+---------+----+---------+----+
| 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 |
+--------+------+---------+----+---------+----+---------+----+
| 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 |
+--------+------+---------+----+---------+----+---------+----+
| 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 |
+--------+------+---------+----+---------+----+---------+----+
| 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 |
+--------+------+---------+----+---------+----+---------+----+
| 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 |
+========+======+=========+====+=========+====+=========+====+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+========+======+=========+====+=========+====+=========+====+
Table 3: DSCP Values
表3：DSCP値
As a result of ToS Precedence Bleaching, each of the DSCPs in a column are re-marked to the smallest DSCP in that column. Therefore, the DSCPs in the bottom row have higher survivability across an end-to-end Internet path.
TOSの優先順位が漂白された結果、列内の各DSCPはその列の最小のDSCPに再マ化されます。したがって、一番下の行のDSCPは、エンドツーエンドのインターネットパスでより高い生存性を備えています。
Data on the observed re-marking at the time of writing was presented in [IETF115-IEPG].
執筆時点で観測された再マークに関するデータは、[IETF115-IEPG]で提示されました。
+========+=======+===============+======+===+===+===========+======+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+========+=======+===============+======+===+===+===========+======+
| Assigned | Re-marked | EXP/ | * | | Re-marked | EXP/ |
| | from AF11..41 | LU | | | from | LU |
| | | | | | AF13..EF | |
+----------------+---------------+------+---+---+-----------+------+
Table 4: 0b000xxx DSCPs
表4：0B000XXX DSCPS
*
*
DSCP 4 has been historically used by the SSH application [Kol10]
DSCP 4は歴史的にSSHアプリケーションで使用されてきました[KOL10]
Table 4 shows 0b000xxx DSCPs. This highlights any current assignments and whether they are affected by any known re-marking behaviors, such as ToS Precedence Bleaching.
表4は、0B000XXX DSCPSを示しています。これは、現在の割り当てと、TOSの優先順位漂白などの既知の再マーク行動の影響を受けるかどうかを強調します。
DSCPs of the form 0b000xxx can be impacted by known re-marking behaviors of other assigned DSCPs. For example, ToS Precedence Bleaching of popular DSCPs AF11, AF21, AF31, and AF41 would result in traffic being re-marked with DSCP 2 in the Internet core. The Lower Effort (LE) Per-Hop Behavior PHB uses a DSCP of 1. The DSCP value of 4 has been historically used by the SSH application, following semantics that precede Diffserv [Kol10].
フォーム0B000XXXのDSCPSは、他の割り当てられたDSCPの既知の再マーク動作によって影響を受ける可能性があります。たとえば、人気のあるDSCPS AF11、AF21、AF31、およびAF41のTOS優先漂白は、インターネットコアのDSCP 2でトラフィックを再マ化することになります。低い努力（LE）の動作PHBは、DSCPを1のDSCPを使用します。DSCP値4は、diffserv [kol10]に先行するセマンティクスに従って、SSHアプリケーションで歴史的に使用されてきました。
Bleach-ToS-Precedence (see Section 4) of packets with a DSCP 'x' results in the DSCP being re-marked to 'x' & 0x07 and then forwarded using the PHB specified for the resulting DSCP in that Diffserv domain. In subsequent networks, the packet will receive treatment as specified by the domain's operator corresponding to the re-marked codepoint.
DSCP 'X'を持つパケットの漂白剤と予測（セクション4を参照）により、DSCPが「X」と0x07に再マイクされ、そのDIFSERVドメインで結果のDSCPに指定されたPHBを使用して転送されます。後続のネットワークでは、パケットは、再マークされたコードポイントに対応するドメインの演算子によって指定された処理を受けます。
A variation of this observed re-marking behavior clears the top three bits of a DSCP, unless these have values 0b110 or 0b111 (corresponding to the CS6 and CS7 DSCPs). As a result, a DSCP value greater than 48 decimal (0x30) is less likely to be impacted by ToS Precedence Bleaching.
この観察された再マーク動作のバリエーションは、値0B110または0B111（CS6およびCS7 DSCPに対応）を持たない限り、DSCPの上位3ビットをクリアします。その結果、48小数（0x30）を超えるDSCP値は、TOSの優先順位漂白の影響を受けにくくなります。
[RFC2474] states:
[RFC2474]状態：
Implementors should note that the DSCP field is six bits wide. DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device.
実装者は、DSCPフィールドの幅は6ビットであることに注意する必要があります。DS準拠のノードは、たとえば、フィールドの値をそのデバイスに実装されている特定のパケット処理メカニズムを選択するために使用するテーブルインデックスとして扱うことにより、6ビットDSCPフィールド全体と一致することにより、PHBを選択する必要があります。
This replaced re-marking according to ToS precedence (see Section 4) [RFC1349]. These practices based on ToS semantics have not yet been eliminated from deployed networks.
これは、TOSの優先順位（セクション4を参照）[RFC1349]に従って再マッキングに取って代わりました。TOSセマンティクスに基づくこれらのプラクティスは、展開されたネットワークからまだ排除されていません。
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|0 0 1|x x x|
+-+-+-+-+-+-+
Figure 3: Bits in the Diffserv Field Modified by ToS Precedence Re-marking
図3：TOSの優先順位によって変更されたdiffservフィールドのビット再マーク
Figure 3 shows the ToS Precedence Re-marking (see Section 4) observed behavior, based on Section 3 of [RFC1349]. The bit positions marked 'x' remain unchanged.
図3は、[RFC1349]のセクション3に基づいて、TOSの優先順位の再マーク（セクション4を参照）を示しています。「x」とマークされたビット位置は変更されていません。
A less common re-marking, ToS Precedence Re-marking sets the first three bits of the DSCP to a non-zero value corresponding to a CS PHB. This re-marking occurs when routers are not configured to perform Diffserv re-marking.
あまり一般的ではないリマーク、TOSの優先順位は、DSCPの最初の3ビットをCS PHBに対応する非ゼロ値に設定します。この再マッキングは、ルーターがDiffServの再マークを実行するように構成されていない場合に発生します。
If ToS Precedence Re-marking occurs, packets are forwarded using the PHB specified for the resulting DSCP in that domain. For example, the AF31 DSCP (0x1a) could be re-marked to either AF11 or AF21. If such a re-marked packet further traverses other Diffserv domains, it would receive treatment as specified by each domain's operator corresponding to the re-marked codepoint.
TOSの優先順位が発生した場合、パケットは、そのドメインで得られたDSCPに指定されたPHBを使用して転送されます。たとえば、AF31 DSCP（0x1a）をAF11またはAF21のいずれかに再マ化できます。このような再マークされたパケットが他のdiffservドメインをさらに移動する場合、再マークされたコードポイントに対応する各ドメインの演算子によって指定されているように治療を受けます。
A network device might re-mark the Diffserv field of an IP packet based on a local policy with a specific set of DSCPs (see Section 4).
ネットワークデバイスは、特定のDSCPSセットを備えたローカルポリシーに基づいて、IPパケットのDiffServフィールドを再マークする場合があります（セクション4を参照）。
Section 3 of [RFC2474] recommends: "Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior, and their codepoints should not be changed." Some networks might not follow this recommendation and instead re-mark packets with these codepoints to the default class: CS0 (0x00). This re-marking is sometimes performed using a Multi-Field (MF) classifier [RFC2475] [RFC3290] [RFC4594].
[RFC2474]のセクション3には、「認識されていないコードポイントで受信されたパケットは、デフォルトの動作に対してマークされているかのように転送されるべきであり、コードポイントを変更しないでください」と推奨しています。一部のネットワークは、この推奨事項に従わず、代わりにこれらのコードポイントをデフォルトのクラスであるCS0（0x00）に再マークする場合があります。この再マークは、マルチフィールド（MF）分類器[RFC2475] [RFC3290] [RFC4594]を使用して実行されることがあります。
If re-marking occurs, packets are forwarded using the PHB specified for the resulting DSCP in that domain. As an example, re-marking traffic AF31, AF32, and AF33 all to a single DSCP, e.g., AF11, stops any drop probability differentiation, which may have been expressed by these three DSCPs. If such a re-marked packet further traverses other domains, it would receive treatment as specified by the domain's operator corresponding to the re-marked codepoint. Bleaching (see Section 4) is a specific example of this observed re-marking behavior that re-marks to CS0 (0x00) (see Section 4.1).
再マークが発生した場合、パケットは、そのドメイン内の結果のDSCPに指定されたPHBを使用して転送されます。例として、トラフィックAF31、AF32、およびAF33をすべて単一のDSCP（たとえば、AF11）に再マークすると、これら3つのDSCPによって表された可能性のあるドロップ確率分化が停止します。このような再マークされたパケットが他のドメインをさらに通過すると、再マークされたコードポイントに対応するドメインの演算子が指定した処理を受けます。漂白（セクション4を参照）は、CS0（0x00）に再マークするこの観測された再マーク動作の具体的な例です（セクション4.1を参照）。
Transmission systems and subnetworks can, and do, utilize the Diffserv field in an IP packet to set a QoS-related field or function at the lower layer. A lower layer could also implement a traffic-conditioning function that could re-mark the DSCP used at the IP layer. This function is constrained by designs that utilize fewer than 6 bits to express the service class and, therefore, infer a mapping to a smaller L2 QoS field, for example, the 3-bit Priority Code Point (PCP) field in an IEEE Ethernet 802.1Q header, the 3-bit User Priority (UP) field, or the 3-bit Traffic Class field of Multi-Protocol Label Switching (MPLS). A Treatment Aggregate (TA) [RFC5127] is an optional intermediary mapping group of BAs to PHBs.
トランスミッションシステムとサブネットワークは、IPパケットのDiffServフィールドを利用して、QoS関連のフィールドまたは機能を下層に設定できます。下層は、IPレイヤーで使用されるDSCPを再マークできるトラフィック条件関数を実装することもできます。この関数は、6ビット未満を利用してサービスクラスを表現する設計によって制約されているため、IEEEイーサネット802.1の3ビット優先コードポイント（PCP）フィールドなど、より小さなL2 QoSフィールドへのマッピングを推測します。Qヘッダー、3ビットユーザー優先度（UP）フィールド、またはマルチプロトコルラベルスイッチング（MPLS）の3ビットトラフィッククラスフィールド。治療集計（TA）[RFC5127]は、PHBからBASのオプションの仲介マッピンググループです。
The IEEE specifies standards that include mappings for DSCPs to lower layer elements.
IEEEは、DSCPSのマッピングが層要素を下げるためのマッピングを含む標準を指定します。
IEEE 802.1Q specified a 3-bit PCP field, which includes a tag that allows Ethernet frames to be marked as one of eight priority values [IEEE-802.1Q]. Use of this field is described by various documents, including IEEE P802.1p and IEEE 802.1D.
IEEE 802.1Qは、イーサネットフレームを8つの優先値のいずれかとしてマークすることを可能にするタグ[IEEE-802.1Q]を含む3ビットPCPフィールドを指定しました。このフィールドの使用は、IEEE P802.1pやIEEE 802.1dを含むさまざまなドキュメントで説明されています。
The mapping specified in [IEEE-802.1Q] revises a previous standard, [IEEE-802.1D], in an effort to align with Diffserv practice [RFC4594]. In 802.1Q, the traffic types are specified to match the first three bits of a suitable DSCP (e.g., the first three bits of the Expedited Forwarding (EF) DSCP are mapped to a PCP of 5).
[IEEE-802.1Q]で指定されたマッピングは、Diffserv Practice [RFC4594]に合わせて、以前の標準[IEEE-802.1d]を修正します。802.1Qでは、適切なDSCPの最初の3ビットと一致するようにトラフィックタイプが指定されています（たとえば、迅速な転送（EF）DSCPの最初の3ビットは5のPCPにマッピングされます）。
In this mapping, PCP0 is used to indicate the default Best Effort treatment, and PCP1 indicates a background traffic class. The remaining PCP values indicate increasing priority. Internet control traffic can be marked as CS6, and network control is marked as CS7.
このマッピングでは、PCP0を使用してデフォルトの最適な努力治療を示すため、PCP1はバックグラウンドトラフィッククラスを示します。残りのPCP値は、優先度の増加を示しています。インターネット制御トラフィックはCS6としてマークでき、ネットワーク制御はCS7としてマークされています。
Other re-marking behaviors have also been implemented in Ethernet equipment. Historically, a previous standard, [IEEE-802.1D], used both PCP1 (Background) and PCP2 (Spare) to indicate lower priority than PCP0, and some other devices do not assign a lower priority to PCP1.
他の再マーク行動もイーサネット機器に実装されています。歴史的に、以前の標準[IEEE-802.1D]は、PCP1（バックグラウンド）とPCP2（スペア）の両方を使用してPCP0よりも優先度が低く、他の一部のデバイスはPCP1の優先度が低いことを割り当てません。
Section 6 of [RFC8325] provides a brief overview of IEEE 802.11 QoS. The IEEE 802.11 standards [IEEE-802.11] provide Media Access Control (MAC) functions to support QoS in WLANs using Access Categories (ACs). The upstream UP in the 802.11 header has a 3-bit QoS value. A DSCP can be mapped to the UP. [RFC8622] added a mapping for the LE DSCP to AC_BK (Background).
[RFC8325]のセクション6では、IEEE 802.11 Qosの簡単な概要を説明します。IEEE 802.11標準[IEEE-802.11]は、アクセスカテゴリ（ACS）を使用してWLANのQOをサポートするメディアアクセス制御（MAC）関数を提供します。802.11ヘッダーの上流には、3ビットQoS値があります。DSCPをUPにマッピングできます。[RFC8622]は、LE DSCPのマッピングをAC_BK（バックグラウンド）に追加しました。
Most current Wi-Fi implementations use a default mapping that maps the first three bits of the DSCP to the 802.11 UP value. This is an example of equipment still classifying on ToS Precedence (which could be seen as a simple method to map IP layer Diffserv to layers offering only 3-bit QoS codepoints). Then, in turn, this is mapped to the four Wi-Fi Multimedia (WMM) Access Categories. The Wi-Fi Alliance has also specified a more flexible mapping that follows [RFC8325] and provides functions at an Access Point (AP) to re-mark packets as well as a QoS Map that maps each DSCP to an AC [WIFI-ALLIANCE].
現在のWi-Fi実装のほとんどは、DSCPの最初の3ビットを802.11 Up値にマッピングするデフォルトマッピングを使用します。これは、TOSの優先順位でまだ分類されている機器の例です（これは、3ビットQoSコードポイントのみを提供するレイヤーにIPレイヤーdiffservをマッピングする簡単な方法と見なすことができます）。次に、これは4つのWi-Fiマルチメディア（WMM）アクセスカテゴリにマッピングされます。Wi-Fi Allianceは、[RFC8325]に続くより柔軟なマッピングを指定し、アクセスポイント（AP）にパケットを再マークする機能を提供し、各DSCPをACにマッピングするQOSマップ[Wifi-Alliance]を指定しました[Wifi-Alliance]。
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|x x x|. . .|
+-+-+-+-+-+-+
Figure 4: DSCP Bits Commonly Mapped to the UP in 802.11
図4：DSCPビットは一般に802.11でUPにマッピングされます
The bit positions marked 'x' are mapped to the 3-bit UP value, while the ones marked '.' are ignored.
「x」とマークされたビット位置は、3ビットアップ値にマッピングされ、マークされた位置は「」とマッピングされます。無視されます。
[RFC8325] notes inconsistencies that can result from such re-marking and recommends a different mapping to perform this re-marking, dependent on the direction in which a packet is forwarded. It provides recommendations for mapping a DSCP to an IEEE 802.11 UP for interconnection between wired and wireless networks. The recommendation in Section 5.1.2 maps network control traffic, CS6 and CS7, as well as unassigned DSCPs, to UP 0 when forwarding in the upstream direction (wireless-to-wired). It also recommends mapping CS6 and CS7 traffic to UP 7 when forwarding in the downstream direction (Section 4.1 of [RFC8325]).
[RFC8325]そのような再マッキングから生じる可能性のある矛盾は、パケットが転送される方向に応じて、この再マッピングを実行するための異なるマッピングを推奨します。WIREDネットワークとワイヤレスネットワークの相互接続のために、DSCPをIEEE 802.11にマッピングするための推奨事項を提供します。セクション5.1.2の推奨事項は、ネットワーク制御トラフィック、CS6およびCS7をマップし、上流方向に転送するときに0に分類されていないDSCPをマップします（ワイヤレスからワイヤード）。また、下流方向に転送するときにCS6およびCS7トラフィックを7にマッピングすることを推奨します（[RFC8325]のセクション4.1）。
For other UPs, [RFC8325] recommends a mapping in the upstream direction (wireless-to-wired interconnections) that derives the DSCP from the value of the UP multiplied by 8. This mapping, currently used by some Access Points (APs), can result in a specific DSCP re-marking behavior:
他のUPSの場合、[RFC8325]は、UPの値からDSCPを導出する上流方向（ワイヤレス対ワイヤード相互接続）でのマッピングを推奨します。特定のDSCPの再マーク動作をもたらします：
wherein DSCP values are derived from UP values by multiplying the UP values by 8 (i.e., shifting the three UP bits to the left and adding three additional zeros to generate a DSCP value). This derived DSCP value is then used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network). Alternatively, in the case where there is no other classification and marking policy enforcement point, then this derived DSCP value will be used on the remainder of the Internet path.
ここで、DSCP値は、UP値に8を掛けることでUP値から派生します（つまり、3つのUPビットを左にシフトし、DSCP値を生成するために3つのゼロを追加します）。この導出されたDSCP値は、ワイヤレスAPと最も近い分類およびマーキングポリシー施行ポイント（これは、ネットワーク内に比較的深い中央のワイヤレスLANコントローラーである可能性がある）の間のQOS処理に使用されます。あるいは、他の分類とマークのポリシー施行ポイントがない場合、この導出されたDSCP値は、インターネットパスの残りの部分で使用されます。
This can result in re-marking by Bleach-low (see Section 4).
これにより、漂白剤低下による再マークが発生する可能性があります（セクション4を参照）。
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|x x x|0 0 0|
+-+-+-+-+-+-+
Figure 5: Bits in the Diffserv Field Modified by Re-marking Observed as a Result of UP-to-DSCP Mapping in Some 802.11 Networks
図5：いくつかの802.11ネットワークで最新のマッピングの結果として観察された再マークによって変更されたDiffservフィールドのビット
An alternative to UP-to-DSCP remapping uses the DSCP value of a downstream IP packet (e.g., the Control and Provisioning of Wireless Access Points, CAPWAP, protocol [RFC5415] maps an IP packet Diffserv field to the Diffserv field of the outer IP header in a CAPWAP tunnel).
最新の再マッピングの代替案では、ダウンストリームIPパケットのDSCP値を使用します（たとえば、ワイヤレスアクセスポイント、CapWap、プロトコル[RFC5415]の制御とプロビジョニングを使用します。キャップワップトンネルのヘッダー）。
Some current constraints of Wi-Fi mapping are discussed in Section 2 of [RFC8325]. A QoS profile can be used to limit the maximum DSCP value used for the upstream and downstream traffic.
Wi-Fiマッピングの現在の制約については、[RFC8325]のセクション2で説明しています。QoSプロファイルを使用して、上流および下流のトラフィックに使用される最大DSCP値を制限できます。
Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic Classes (TCs), which restrict the number of different treatments [RFC5129]. [RFC5127] describes the aggregation of Diffserv service classes and introduces four Diffserv TAs. Traffic marked with multiple DSCPs can be forwarded in a single MPLS TC.
マルチプロトコルラベルスイッチング（MPLS）は、異なる治療の数を制限する8つのMPLSトラフィッククラス（TCS）を指定しました[RFC5129]。[RFC5127]は、diffservサービスクラスの集約を説明し、4つのdiffserv Tasを導入します。複数のDSCPでマークされたトラフィックは、単一のMPLS TCで転送できます。
There are three Label Switching Router (LSR) models: the Pipe, the Short Pipe, and the Uniform Model [RFC3270]. In the Uniform and Pipe models, the egress MPLS router forwards traffic based on the received MPLS TC. The Uniform Model includes an egress DSCP rewrite. With the Short Pipe Model, the egress MPLS router forwards traffic based on the Diffserv DSCP as present at the egress router. If the domain supports IP and MPLS QoS differentiation, controlled behavior requires the DSCP of an (outer) IP header to be assigned or re-written by all domain ingress routers to conform with the domain's internal Diffserv deployment. Note that the Short Pipe Model is prevalent in MPLS domains.
3つのラベルスイッチングルーター（LSR）モデルがあります：パイプ、ショートパイプ、均一モデル[RFC3270]。均一モデルとパイプモデルでは、出力MPLSルーターは、受信したMPLS TCに基づいてトラフィックを転送します。ユニフォームモデルには、出口DSCP書き換えが含まれています。短いパイプモデルを使用すると、出力MPLSルーターは、出力ルーターに存在するDiffserv DSCPに基づいてトラフィックを転送します。ドメインがIPおよびMPLS QOSの分化をサポートする場合、制御された動作には、（外側）IPヘッダーのDSCPが、すべてのドメインイングレスルーターによって割り当てまたは書き直される必要があります。短いパイプモデルはMPLSドメインで普及していることに注意してください。
[RFC3270] defines a flexible solution for support of Diffserv over MPLS networks. This allows an MPLS network administrator to select how BAs (marked by DSCPs) are mapped onto Label Switched Paths (LSPs) to best match the Diffserv, Traffic Engineering, and protection objectives within their particular network.
[RFC3270]は、MPLSネットワークを介してDiffServをサポートするための柔軟なソリューションを定義しています。これにより、MPLSネットワーク管理者は、BAS（DSCPSでマークされた）がラベルスイッチ付きパス（LSP）にマッピングされ、特定のネットワーク内のDiffServ、トラフィックエンジニアリング、および保護目標に最適な方法を選択できます。
Mappings from the IP DSCP to the MPLS header are defined in Section 4.2 of [RFC3270].
IP DSCPからMPLSヘッダーへのマッピングは、[RFC3270]のセクション4.2で定義されています。
The Pipe Model conveys the "LSP Diff-Serv Information" to the LSP Egress so that its forwarding treatment can be based on the IP DSCP.
パイプモデルは、「LSP Diff-Serv情報」をLSP Egressに伝え、その転送処理がIP DSCPに基づくことができるようにします。
When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs to be aware of the encapsulation mapping for a PHB to the label corresponding to the exposed header to perform Diffserv Information Encoding (Section 2.5.2 of [RFC3270]).
最後から2番目のホップポップ（PHP）を使用する場合、最後から2番目のLSRは、露出したヘッダーに対応するラベルのPHBのカプセル化マッピングを認識して、[RFC3270]のセクション2.5.2）を実行する必要があります。
The Short Pipe Model is an optional variation of the Pipe Model [RFC3270].
短いパイプモデルは、パイプモデルのオプションのバリエーションです[RFC3270]。
ITU-T Y.1566 [ITU-T-Y.1566] further defined a set of four common QoS classes and four auxiliary classes to which a DSCP can be mapped when interconnecting Ethernet, IP, and MPLS networks. [RFC8100] describes four TAs for interconnection with four defined DSCPs. This was motivated by the requirements of MPLS network operators that use Short Pipe tunnels but can be applicable to other networks, both MPLS and non-MPLS.
ITU-T Y.1566 [ITU-T-Y.1566]は、イーサネット、IP、およびMPLSネットワークを相互接続するときにDSCPをマッピングできる4つの一般的なQoSクラスと4つの補助クラスのセットをさらに定義しました。[RFC8100]は、4つの定義されたDSCPとの相互接続のための4つのTAを説明しています。これは、短いパイプトンネルを使用するが、MPLSと非MPLの両方の他のネットワークに適用できるMPLSネットワークオペレーターの要件に動機付けられました。
[RFC8100] recommends preserving the notion of end-to-end service classes and recommends a set of standard DSCPs mapped to a small set of standard PHBs at interconnection. The key requirement is that the DSCP at the network ingress is restored at the network egress. The current version of [RFC8100] limits the number of DSCPs to 6, and 3 more are suggested for extension. [RFC8100] respects the deployment of PHB groups for DS domain-internal use, which limits the number of acceptable external DSCPs (and possibilities for their transparent transport or restoration at network boundaries). In this design, packets marked with DSCPs not part of the codepoint scheme [RFC8100] are treated as unexpected and will possibly be re-marked (a Re-mark-DSCP, see Section 4 behavior) or dealt with via additional agreements among the operators of the interconnected networks. [RFC8100] can be extended to support up to 32 DSCPs by future standards. [RFC8100] is operated by at least one Tier 1 backbone provider. Use of the MPLS Short Pipe Model favors re-marking unexpected DSCP values to zero in the absence of additional agreements, as explained in [RFC8100]. This can result in bleaching (see Section 4).
[RFC8100]は、エンドツーエンドサービスクラスの概念を保存することを推奨し、相互接続時に小さな標準PHBのセットにマッピングされた標準DSCPのセットを推奨します。重要な要件は、ネットワークイングレスのDSCPがネットワーク出口で復元されることです。[RFC8100]の現在のバージョンは、DSCPの数を6に制限し、さらに3つは拡張に提案されています。[RFC8100]は、DSドメイン内使用のためのPHBグループの展開を尊重し、許容可能な外部DSCPの数（およびネットワーク境界での透明な輸送または修復の可能性）を制限します。この設計では、CodePointスキーム[RFC8100]の一部ではないDSCPSでマークされたパケットは、予期しないものとして扱われ、おそらく再マーク（再マークDSCP、セクション4の動作を参照）またはオペレーター間の追加契約を介して対処される可能性があります。相互接続されたネットワークの。[RFC8100]は、将来の基準で最大32のDSCPをサポートするために拡張できます。[RFC8100]は、少なくとも1つのティア1バックボーンプロバイダーによって操作されます。MPLSショートパイプモデルの使用は、[RFC8100]で説明されているように、追加の契約がない場合、予期しないDSCP値をゼロに再マークすることを支持します。これにより、漂白が発生する可能性があります（セクション4を参照）。
+=======================================+==========+
| Treatment Aggregate [RFC8100] | DSCP |
+=======================================+==========+
| Telephony Service Treatment Aggregate | EF |
| | VA |
+---------------------------------------+----------+
| Bulk Real-Time Treatment Aggregate | AF41 |
| | (AF42)* |
| | (AF43)* |
+---------------------------------------+----------+
| Assured Elastic Treatment Aggregate | AF31 |
| | AF32 |
| | (AF33)** |
+---------------------------------------+----------+
| Default / Elastic Treatment Aggregate | BE/CS0 |
+---------------------------------------+----------+
| Network Control: Local Use (LU) | CS6 |
+---------------------------------------+----------+
Table 5: The Short Pipe MPLS Mapping from [RFC8100]
表5：[RFC8100]からの短いパイプMPLSマッピング
*
*
May be added
追加される場合があります
**
**
Reserved for the extension of PHBs
PHBの拡張のために予約されています
Mobile LTE and 5G standards have evolved from older Universal Mobile Telecommunications System (UMTS) standards and support Diffserv. LTE (4G) and 5G standards [SA-5G] identify traffic classes at the interface between User Equipment (UE) and the mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G QoS Identifier). The 3GPP standards do not define or recommend any specific mapping between each QCI or 5QI and Diffserv (and mobile QCIs are based on several criteria service class definitions). The way packets are mapped at the Packet Data Network Gateway (P-GW) boundary is determined by network operators. However, TS 23.107 (version 16.0.0, applies to LTE and below) mandates that Differentiated Services, defined by the IETF, shall be used to interoperate with IP backbone networks.
モバイルLTEおよび5G標準は、古いUniversal Mobile Telecommunications System（UMTS）標準とサポートDiffServから進化しています。LTE（4G）および5G標準[SA-5G]は、QCI（QOSクラス識別子）と5QI（5G QOS識別子）によるモバイルパケットコアネットワークの間のインターフェース（UE）とモバイルパケットコアネットワークの間のトラフィッククラスを識別します。3GPP標準では、各QCIまたは5QIとdiffServの間の特定のマッピングを定義または推奨しません（およびモバイルQCIは、いくつかの基準サービスクラスの定義に基づいています）。パケットデータネットワークゲートウェイ（P-GW）境界でのパケットのマッピング方法は、ネットワーク演算子によって決定されます。ただし、TS 23.107（バージョン16.0.0はLTEおよび以下に適用されます）は、IETFによって定義される差別化されたサービスを、IPバックボーンネットワークと相互運用するために使用することを義務付けています。
The GSM Association (GSMA) has defined four aggregated classes and seven associated PHBs in their guidelines for IP Packet eXchange (IPX) Provider networks [GSMA-IR.34]. This was previously specified as the "Inter-Service Provider IP Backbone Guidelines" and provides a mobile ISP to ISP QoS mapping mechanism and interconnection with other IP networks in the general Internet. If provided an IP VPN, the operator is free to apply its DS domain-internal codepoint scheme at outer headers and inner IPX DSCPs may be transported transparently. The guidelines also describe a case where the DSCP marking from a Service Provider cannot be trusted (depending on the agreement between the Service Provider and its IPX Provider). In this situation, the IPX Provider can re-mark the DSCP value to a static default value.
GSM Association（GSMA）は、IPパケットExchange（IPX）プロバイダーネットワークのガイドラインで、4つの集計クラスと7つの関連PHBを定義しました[GSMA-IR.34]。これは以前に「サービス間プロバイダーIPバックボーンガイドライン」として指定されており、ISP QoSマッピングメカニズムと一般的なインターネットの他のIPネットワークとの相互接続にモバイルISPを提供します。IP VPNを提供すると、オペレーターは外部ヘッダーにDSドメイン内部コードポイントスキームを自由に適用でき、内部IPX DSCPは透過的に輸送できます。ガイドラインでは、サービスプロバイダーからのDSCPマーキングが信頼できない場合（サービスプロバイダーとそのIPXプロバイダーの間の契約に応じて）。この状況では、IPXプロバイダーはDSCP値を静的なデフォルト値に再マークできます。
+====================================+======+
| QoS Class in [GSMA-IR.34] | PHB |
+====================================+======+
| Conversational | EF |
+------------------------------------+------+
| Streaming | AF41 |
+------------------------------------+------+
| Interactive | AF31 |
| +------+
| (ordered by priority, AF3 highest) | AF32 |
| +------+
| | AF21 |
| +------+
| | AF11 |
+------------------------------------+------+
| Background | CS0 |
+------------------------------------+------+
Table 6: The PHB Mapping Recommended in the Guidelines Recommended in [GSMA-IR.34]
表6：[GSMA-IR.34]で推奨されるガイドラインで推奨されるPHBマッピング
MEF Forum (MEF) provides a mapping of DSCPs at the IP layer to quality of service markings in the Ethernet frame headers [MEF-23.1].
MEFフォーラム（MEF）は、イーサネットフレームヘッダー[MEF-23.1]のサービスマークの品質にIPレイヤーでのDSCPのマッピングを提供します。
This includes any other re-marking that does not happen as a result of traffic conditioning, such as policies and L2 procedures that result in re-marking traffic as a side effect of other functions (e.g., in response to Distributed Denial of Service, DDoS).
これには、他の機能の副作用としてトラフィックを再マークするポリシーやL2手順など、トラフィックコンディショニングの結果としては発生しない他の再マッキングが含まれます（たとえば、分散型サービス拒否に応じて、DDOS）。
This section has discussed the various ways in which DSCP re-marking behaviors can arise from interactions with lower layers.
このセクションでは、DSCPの再マーク行動が下層との相互作用から生じるさまざまな方法について説明しました。
A provider service path may consist of sections where multiple and changing layers use their own code points to determine differentiated forwarding (e.g., IP to MPLS to IP to Ethernet to Wi-Fi).
プロバイダーサービスパスは、複数の変更レイヤーが独自のコードポイントを使用して差別化された転送を決定するセクションで構成されている場合があります（例：IPからIPからIPからイーサネットへのWi-Fi）。
This section provides advice for the assignment of a new DSCP value. It is intended to aid the IETF and IESG in considering a request for a new DSCP. This section identifies known issues that might influence the finally assigned DSCP and provides a summary of considerations for assignment of a new DSCP.
このセクションでは、新しいDSCP値の割り当てに関するアドバイスを提供します。これは、新しいDSCPのリクエストを検討する際にIETFとIESGを支援することを目的としています。このセクションでは、最終的に割り当てられたDSCPに影響を与える可能性のある既知の問題を特定し、新しいDSCPの割り当てに関する考慮事項の要約を提供します。
Section 4 describes re-marking of the DSCP. New DSCP assignments should consider the impact of bleaching or re-marking (see Section 4) to a single DSCP, which can limit the ability to provide the expected treatment end-to-end. This is particularly important for cases where the codepoint is intended to result in lower than Best Effort treatment, as was the case when defining the LE PHB [RFC8622]. Forwarding LE using the default PHB is in line with [RFC8622], but it is recommended to maintain the distinct LE DSCP codepoint end-to-end to allow for differentiated treatment by domains supporting LE. Rewriting the LE DSCP to the default class (CS0) results in an undesired promotion of the priority for LE traffic in such a domain. Bleaching the lower three bits of the DSCP (both Bleach-low and Bleach-some-low in Section 4), as well as re-marking to a particular DSCP, can result in similar changes of priority relative to traffic that is marked with other DSCPs.
セクション4では、DSCPの再マークについて説明します。新しいDSCPの割り当ては、漂白または再マーク（セクション4を参照）の単一のDSCPへの影響を考慮する必要があります。これは、LE PHB [RFC8622]を定義する場合のように、CodePointがベスト努力よりも低い場合を意図している場合に特に重要です。デフォルトのPHBを使用してLEを転送することは[RFC8622]と一致していますが、LEをサポートするドメインによる区別化処理を可能にするために、異なるLE DSCPコードポイントエンドツーエンドを維持することをお勧めします。LE DSCPをデフォルトのクラス（CS0）に書き換えると、そのようなドメインでのLEトラフィックの優先度が望ましくないプロモーションが得られます。DSCPの下部3ビット（セクション4の漂白剤と漂白剤と漂白剤の両方）を漂白し、特定のDSCPに再マークすると、他のトラフィックとマークされたトラフィックと同様の優先度の変化をもたらす可能性があります。DSCPS。
This considers a proposed DSCP with a codepoint larger than 7.
これにより、提案されたDSCPが7を超えるコードポイントを考慮します。
Although the IETF specifications require systems to use DSCP marking semantics in place of methods based on the former ToS field, the current recommendation is that any new assignment where the DSCP is greater than 0x07 should consider the semantics associated with the resulting DSCP when the ToS Precedence is bleached (Bleach-ToS-Precedence and Bleach-some-ToS, Section 4) or ToS Precedence Re-marking (Re-mark-ToS, Section 4) is experienced. For example, it can be desirable to avoid choosing a DSCP that could be re-marked to LE, Lower Effort [RFC8622], which could otherwise potentially result in a priority inversion in the treatment.
IETF仕様では、以前のTOSフィールドに基づいたメソッドの代わりにDSCPマーキングセマンティクスを使用するシステムが必要ですが、現在の推奨事項は、DSCPが0x07を超える新しい割り当ては、TOSの優先順位が結果のDSCPに関連するセマンティクスを考慮する必要があることです。漂白されている（漂白剤と漂白症と漂白剤-Some-TOS、セクション4）またはTOSの優先順位（Re-Mark-TOS、セクション4）が経験されています。たとえば、LE、より低い努力[RFC8622]に再マ化できるDSCPを選択しないようにすることが望ましい場合があります。
This considers a proposed DSCP where the least significant 3 bits together represent a value of 1 (i.e., 0b001).
これは、最も重要な3ビットが1の値を表す（つまり、0B001）を表す提案されたDSCPを考慮します。
As a consequence of assigning the LE PHB [RFC8622], the IETF allocated the DSCP 0b000001 from Pool 3.
LE PHB [RFC8622]の割り当ての結果として、IETFはプール3からDSCP 0B000001を割り当てました。
When making assignments where the DSCP has a format "0bxxx001", the case of Bleach-ToS-Precedence (Section 4) of a DSCP to a value of 0x01 needs to be considered. ToS Precedence Bleaching will result in demoting the traffic to the Lower Effort PHB. Care should be taken to consider the implications of re-marking when choosing to assign a DSCP with this format.
DSCPにフォーマット「0BXXX001」がある場合に割り当てを作成する場合、DSCPの漂白剤（セクション4）の場合は0x01の値に考慮する必要があります。TOS優先漂白により、トラフィックが低い努力のPHBに降格することになります。この形式でDSCPを割り当てることを選択する際に、再マッキングの意味を考慮するように注意する必要があります。
This considers a proposed DSCP where the DSCP is less than or equal to 7.
これは、DSCPが7以下である提案されたDSCPを考慮します。
ToS Precedence Bleaching or ToS Precedence Re-marking can unintentionally result in extra traffic aggregated to the same DSCP. For example, after experiencing ToS Precedence Bleaching, all traffic marked AF11, AF21, AF31, and AF41 would be aggregated with traffic marked with DSCP 2 (0x02), increasing the volume of traffic that receives the treatment associated with DSCP 2. New DSCP assignments should consider unexpected consequences arising from this observed re-marking behavior.
TOSの優先順位漂白またはTOSの優先順位は、意図せずに同じDSCPに追加のトラフィックが集約される可能性があります。たとえば、TOS優先漂白を経験した後、AF11、AF21、AF31、およびAF41とマークされたすべてのトラフィックは、DSCP 2（0x02）でマークされたトラフィックと集約され、DSCP 2に関連する治療を受けるトラフィックの量を増やします。この観察された再マーク動作から生じる予期しない結果を考慮する必要があります。
Behavior of deployed PHBs and conditioning treatments also needs to be considered when assigning a new DSCP. Network operators have choices when it comes to configuring Diffserv support within their domains, and the observed re-marking behaviors described in the previous section can result from different configurations and approaches:
展開されたPHBとコンディショニングトリートメントの動作も、新しいDSCPを割り当てる際に考慮する必要があります。ネットワークオペレーターは、ドメイン内でdiffservサポートの構成に関して選択肢があり、前のセクションで説明されている観測された再マーク動作は、さまざまな構成とアプローチから生じる可能性があります。
Networks not re-marking Diffserv:
ネットワークはdiffservを再マークしていません：
A network that either does not implement PHBs or implements one or more PHBs while restoring the DSCP field at network egress with the value at network ingress. Operators in this category pass all DSCPs transparently.
ネットワークイングレスでの値でネットワーク出口でDSCPフィールドを復元しながら、PHBを実装しないか、1つ以上のPHBを実装しているネットワーク。このカテゴリのオペレーターは、すべてのDSCPを透過的に渡します。
Networks that condition the DSCP:
DSCPを条件付けるネットワーク：
A network that implements more than one PHB and enforces Service Level Agreements (SLAs) with its peers. Operators in this category use conditioning to ensure that only traffic that matches a policy is permitted to use a specific DSCP (see [RFC8100]). Operators need to classify the received traffic, assign it to a corresponding PHB, and could re-mark the DSCP to a value that is appropriate for the domain's deployed Diffserv infrastructure.
複数のPHBを実装し、同業他社とサービスレベル契約（SLA）を実施するネットワーク。このカテゴリのオペレーターは、条件付けを使用して、ポリシーに一致するトラフィックのみが特定のDSCPを使用することが許可されていることを確認します（[RFC8100]を参照）。オペレーターは、受信したトラフィックを分類し、対応するPHBに割り当て、DSCPをドメインの展開されたDiffServインフラストラクチャに適した値に再マークする必要があります。
Networks that re-mark in some other way, which includes:
次のことを含む他の方法で再マークするネットワーク
1. Networks containing misconfigured devices that do not comply with the relevant RFCs.
1. 関連するRFCに準拠していない誤ったデバイスを含むネットワーク。
2. Networks containing devices that implement an obsolete specification or contain software bugs.
2. 時代遅れの仕様を実装する、またはソフトウェアバグを含むデバイスを含むネットワーク。
3. Networks containing devices that re-mark the DSCP as a result of lower layer interactions.
3. 下層相互作用の結果としてDSCPを再マークするデバイスを含むネットワーク。
The DSCP re-marking corresponding to the Bleach-ToS-Precedence (Section 4) observed behavior can arise for various reasons, one of which is old equipment that precedes Diffserv. The same re-marking can also arise in some cases when traffic conditioning is provided by Diffserv routers at operator boundaries or as a result of misconfiguration.
観測された漂白症の前処理に対応するDSCPの再マークは、さまざまな理由で発生する可能性があり、そのうちの1つはDiffservに先行する古い機器です。同じ再マークは、場合によっては、オペレーターの境界でのDiffServルーターによってトラフィックコンディショニングが提供される場合、または誤解の結果としても発生する可能性があります。
A series of questions emerge that need to be answered when considering a proposal to the IETF that requests a new assignment. These questions include:
新しい課題を要求するIETFへの提案を検討する際に答える必要がある一連の質問が現れます。これらの質問は次のとおりです。
* Is the request for Local Use within a Diffserv domain that does not require interconnection with other Diffserv domains? This request can use DSCPs in Pool 2 for Local or Experimental Use, without any IETF specification for the DSCP or associated PHB.
* 他のdiffservドメインとの相互接続を必要としないdiffservドメイン内でのローカル使用の要求はありますか？この要求は、DSCPまたは関連PHBのIETF仕様なしで、ローカルまたは実験的使用にプール2のDSCPを使用できます。
* What are the characteristics of the proposed service class? What are the characteristics of the traffic to be carried? What are the expectations for treatment?
* 提案されたサービスクラスの特徴は何ですか？運ばれるトラフィックの特徴は何ですか？治療への期待は何ですか？
* Service classes [RFC4594] that can utilize existing PHBs should use assigned DSCPs to mark their traffic: Could the request be met by using an existing IETF DSCP?
* 既存のPHBを利用できるサービスクラス[RFC4594]は、割り当てられたDSCPを使用してトラフィックをマークする必要があります。既存のIETF DSCPを使用してリクエストを満たすことができますか？
* Specification of a new recommended DSCP requires Standards Action. [RFC2474] states: "Each standardized PHB MUST have an associated RECOMMENDED codepoint". If approved, new IETF assignments are normally made by IANA in Pool 1, but the IETF can request assignments to be made from Pool 3 [RFC8436]. Does the Internet Draft contain an appropriate request to IANA?
* 新しい推奨DSCPの仕様には、標準アクションが必要です。[RFC2474]は次のように述べています。「各標準化されたPHBには、関連する推奨コードポイントが必要です」。承認された場合、新しいIETF割り当ては通常、プール1のIANAによって行われますが、IETFはプール3 [RFC8436]からの割り当てを要求できます。インターネットドラフトにはIANAへの適切なリクエストが含まれていますか？
* The value selected for a new DSCP can impact the ability of an operator to apply logical functions (e.g., a bitwise mask) to related codepoints when configuring Diffserv. A suitable value can simplify configurations by aggregating classification on a range of DSCPs. This classification based on DSCP ranges can increase the comprehensibility of documenting forwarding differentiation.
* 新しいDSCPで選択された値は、diffservを構成する際に関連するコードポイントに論理関数（ビットワイズマスクなど）を適用するオペレーターの能力に影響を与える可能性があります。適切な値は、DSCPの範囲で分類を集約することにより、構成を簡素化できます。DSCP範囲に基づくこの分類は、転送の分化を文書化することの理解可能性を高めることができます。
* Section 5.2 describes examples of treatment aggregation. What are the effects of treatment aggregation on the proposed DSCP?
* セクション5.2では、治療の凝集の例について説明します。提案されているDSCPに対する治療凝集の影響は何ですか？
* Section 5 describes some observed treatments by layers below IP. What are the implications of the treatments and mapping described in Section 5 on the proposed DSCP?
* セクション5では、IPの下の層で観察された治療法について説明します。提案されたDSCPのセクション5で説明されている治療とマッピングの意味は何ですか？
* DSCPs are assigned to PHBs and can be used to enable nodes along an end-to-end path to classify the packet for a suitable PHB. Section 4 describes some observed re-marking behavior, and Section 6.4 identifies root causes for why this re-marking is observed. What is the expected effect of currently-deployed re-marking on the service, end-to-end or otherwise?
* DSCPはPHBに割り当てられ、エンドツーエンドパスに沿ってノードを有効にするために使用できます。適切なPHBのパケットを分類できます。セクション4では、いくつかの観察された再マーク動作について説明し、セクション6.4は、この再マークが観察される理由の根本原因を特定します。エンドツーエンドまたはその他のサービスに対する現在展開されているリマークの予想される効果は何ですか？
IANA has added the following text as a note at the top of the "Differentiated Services Field Codepoints (DSCP)" registry [DSCP-registry]: "See RFC 9435 for considerations when assigning a new codepoint from the DSCP registry."
IANAは、「Distemiated Servicesフィールドコードポイント（DSCP）」レジストリ[DSCP-Registry]の上部にメモとして次のテキストを追加しました。
The security considerations are discussed in the security considerations of each cited RFC.
セキュリティ上の考慮事項は、引用された各RFCのセキュリティに関する考慮事項で説明されています。
[DSCP-registry]
IANA, "Differentiated Services Field Codepoints (DSCP)",
<https://www.iana.org/assignments/dscp-registry/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for
Pool 3 Values in the Differentiated Services Field
Codepoints (DSCP) Registry", RFC 8436,
DOI 10.17487/RFC8436, August 2018,
<https://www.rfc-editor.org/info/rfc8436>.
[AX.25-over-IP]
Learmonth, I. R., "Internet Protocol Encapsulation of
AX.25 Frames", Work in Progress, Internet-Draft, draft-
learmonth-intarea-rfc1226-bis-03, 23 May 2021,
<https://datatracker.ietf.org/doc/html/draft-learmonth-
intarea-rfc1226-bis-03>.
[Bar18] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and
S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement
Study", 2018 30th International Teletraffic Congress (ITC
30), DOI 10.1109/ITC30.2018.00034, September 2018,
<https://doi.org/10.1109/ITC30.2018.00034>.
[Cus17] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP
modification pathologies in mobile edge networks", 2017
Network Traffic Measurement and Analysis Conference (TMA),
DOI 10.23919/TMA.2017.8002923, June 2017,
<https://doi.org/10.23919/TMA.2017.8002923>.
[GSMA-IR.34]
GSM Association, "Guidelines for IPX Provider networks
(Previously Inter-Service Provider IP Backbone
Guidelines)", Version 17.0, IR.34, May 2021,
<https://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v17.0.pdf>.
[IEEE-802.11]
IEEE, "IEEE Standard for Information Technology -
Telecommunications and Information Exchange Between
Systems - Local and Metropolitan Area Networks - Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
DOI 10.1109/IEEESTD.2021.9363693, IEEE Standard 802.11,
February 2021,
<https://standards.ieee.org/ieee/802.11/7028/>.
[IEEE-802.1D]
IEEE, "IEEE Standard for Local and metropolitan area
network--Media Access Control (MAC) Bridges", IEEE
Standard 802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June
2004, <https://doi.org/10.1109/IEEESTD.2004.94569>.
[IEEE-802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Network--Bridges and Bridged Networks", IEEE Standard
802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018,
<https://doi.org/10.1109/IEEESTD.2018.8403927>.
[IETF115-IEPG]
Custura, A., "Real-world DSCP Traversal Measurements",
November 2022,
<https://datatracker.ietf.org/meeting/115/materials/
slides-115-iepg-sessa-considerations-for-assigning-dscps-
01>.
[ITU-T-Y.1566]
ITU-T Recommendation, "Quality of service mapping and
interconnection between Ethernet, Internet Protocol and
multiprotocol label switching networks", ITU-T Y.1566,
July 2012, <https://www.itu.int/rec/T-REC-Y.1566/en>.
[Kol10] Kolu, A., "Subject: bogus DSCP value for ssh", message to
the freebsd-stable mailing list, 12 July 2010,
<https://lists.freebsd.org/pipermail/freebsd-
stable/2010-July/057710.html>.
[MEF-23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
Class of Service - Phase 2", MEF 23.1, January 2012,
<https://mef.net/Assets/Technical_Specifications/PDF/
MEF_23.1.pdf>.
[NQB-PHB] White, G. and T. Fossati, "A Non-Queue-Building Per-Hop
Behavior (NQB PHB) for Differentiated Services", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-nqb-18, 10 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
tsvwg-nqb-18>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992,
<https://www.rfc-editor.org/info/rfc1349>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, DOI 10.17487/RFC3086,
April 2001, <https://www.rfc-editor.org/info/rfc3086>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.
[RFC3270] Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, DOI 10.17487/RFC3270,
May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<https://www.rfc-editor.org/info/rfc3662>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <https://www.rfc-editor.org/info/rfc5127>.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March
2008, <https://www.rfc-editor.org/info/rfc5160>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/info/rfc5865>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to
IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February
2018, <https://www.rfc-editor.org/info/rfc8325>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[SA-5G] 3GPP, "System architecture for the 5G System (5GS)",
TS 23.501, 2019.
[WIFI-ALLIANCE]
Wi-Fi Alliance, "Wi-Fi QoS Management Specification
Version 2.0", 2021.
The authors acknowledge the helpful discussions and analysis by Greg White and Thomas Fossati in a draft concerning NQB. Ruediger Geib and Brian Carpenter contributed comments, along with other members of the TSVWG.
著者は、NQBに関するドラフトで、Greg WhiteとThomas Fossatiによる有益な議論と分析を認めています。Ruediger GeibとBrian Carpenterは、TSVWGの他のメンバーとともにコメントを提供しました。
Ana Custura
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: ana@erg.abdn.ac.uk
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Raffaello Secchi
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: r.secchi@abdn.ac.uk