RFC 8436 - Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8436
タイトル : RFC 8436 - 差別化サービスフィールドコードポイント（DSCP）レジストリのプール3値のIANA登録手順の更新
翻訳編集 : 自動生成

[要約] RFC 8436は、Differentiated Services Field Codepoints（DSCP）レジストリのPool 3の値のIANA登録手順の更新に関するものです。このRFCの目的は、DSCPレジストリの管理と更新手順を改善し、ネットワークの品質サービス（QoS）の実装を支援することです。

Internet Engineering Task Force (IETF)                      G. Fairhurst
Request for Comments: 8436                        University of Aberdeen
Updates: 2474                                                August 2018
Category: Standards Track
ISSN: 2070-1721

Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry

差別化サービスフィールドコードポイント（DSCP）レジストリのプール3値のIANA登録手順の更新

Abstract

概要

The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.

Differentiated Services（Diffserv）アーキテクチャは、IPv4およびIPv6パケットヘッダーのDSフィールドの使用を指定して、64の個別のDifferentiated Service Field Codepoint（DSCP）値の1つを伝送します。 Internet Assigned Numbers Authority（IANA）は、割り当てられたDSCP値のレジストリを維持しています。

This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

このRFC 2474の更新により、レジストリのプール3のIANA登録ポリシー（つまり、xxxx01のDSCP値）が標準アクションに変更されます。つまり、値は、標準トラックまたは現在のベストプラクティスRFCを通じて割り当てられます。このアップデートでは、DSCPレジストリのプール3を形成するコードポイントの実験的およびローカルでの使用の許可も削除されます。プール2コードポイント（xxxx11形式のDSCP値）は、これらの目的で引き続き使用できます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8436.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8436で入手できます。

著作権表示

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The Updates to RFC 2474 . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

The Differentiated Services (Diffserv) [RFC2475] architecture (updated by [RFC3260]) provides scalable service differentiation in the Internet. Diffserv uses the six most significant bits of the former IPv4 Type of Service (TOS) octet or the former IPv6 Traffic Class octet to convey the field, which is used to carry the DSCP. This DSCP value is used to select a Diffserv per-hop behavior (PHB).

Differentiated Services（Diffserv）[RFC2475]アーキテクチャ（[RFC3260]によって更新）は、インターネットでスケーラブルなサービスの差別化を提供します。 Diffservは、以前のIPv4 Type of Service（TOS）オクテットの6つの最上位ビットまたは以前のIPv6トラフィッククラスオクテットを使用して、DSCPの伝送に使用されるフィールドを伝達します。このDSCP値は、Diffservのホップごとの動作（PHB）を選択するために使用されます。

The six-bit field is capable of conveying 64 distinct codepoints, and this codepoint space has been divided into three pools for the purpose of codepoint assignment and management (as shown in Figure 1). Pool 1 comprises 32 codepoints [RFC2474]. These are assigned by Standards Action, as defined in [RFC8126]. Pool 2 comprises a pool of 16 codepoints reserved for Experimental or Local Use (EXP/LU) as defined in [RFC2474]. Pool 3 comprises 16 codepoints, which were originally specified as "initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted" by [RFC2474].

6ビットフィールドは64の異なるコードポイントを伝達でき、このコードポイントスペースは、コードポイントの割り当てと管理のために3つのプールに分割されています（図1を参照）。プール1は32個のコードポイント[RFC2474]で構成されています。これらは、[RFC8126]で定義されているように、標準アクションによって割り当てられます。プール2は、[RFC2474]で定義されているように、実験的またはローカルでの使用（EXP / LU）用に予約された16個のコードポイントのプールで構成されています。プール3は16のコードポイントで構成され、[RFC2474]によって当初「実験的またはローカルでの使用が可能ですが、プール1が使い果たされた場合、標準化された割り当てに優先的に使用する必要がある」と指定されていました。

                  +------+-----------------+
                  | Pool | Codepoint Space |
                  +------+-----------------+
                  |  1   |      xxxxx0     |
                  +------+-----------------+
                  |  2   |      xxxx11     |
                  +------+-----------------+
                  |  3   |      xxxx01     |
                  +------+-----------------+

Figure 1: Format of the Field for Codepoints Allocated in the Three IANA Pools (Where "x" Refers to Either "0" or "1")

図1：3つのIANAプールに割り当てられたコードポイントのフィールドの形式（「x」は「0」または「1」を参照）

At the time of writing this document, 22 of the 32 Pool 1 codepoints have been assigned.

このドキュメントの執筆時点では、32のプール1コードポイントのうち22が割り当てられています。

Although Pool 1 has not yet been completely exhausted, there is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. This document changes the IANA registration policy of Pool 3 to assignment by Standards Action. (Section 4.9 of [RFC8126] defines this as "assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream".)

プール1はまだ完全に使い尽くされていませんが、プール1の未割り当ての値を使用できない特定のPHBにコードポイントを割り当てる必要があります。このドキュメントは、標準アクションによる割り当てにプール3のIANA登録ポリシーを変更します。（[RFC8126]のセクション4.9は、これを「IETFストリームの標準トラックまたは現在のベストプラクティスRFCを通じてのみ割り当てられる」と定義しています。）

An example is the need to assign a suitable recommended default codepoint for the Lower Effort (LE) PHB [LE-PHB]. The LE PHB is designed to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations (when resources become scarce, best-effort traffic has precedence over LE traffic and is allowed to preempt it). In deployed networks, bleaching (i.e. intentionally setting to zero) of the IP Precedence field continues to be used. (Setting the IP Precedence field to zero disables any class-based flow management by routers configured with TOS-based packet processing.) This causes the first three bits of the former TOS byte (now the upper part of the DSCP field) to become zero. Therefore, there is a need to avoid this remapping of the DSCP for the LE PHB by assigning a codepoint that already has a zero value in the first three bits [LE-PHB].

例としては、Lower Effort（LE）PHB [LE-PHB]に適切な推奨デフォルトコードポイントを割り当てる必要があります。 LE PHBは、輻輳状況でLEトラフィックからベストエフォート（BE）トラフィック（デフォルトのPHBで転送されるパケット）を保護するように設計されています（リソースが不足すると、ベストエフォートトラフィックがLEトラフィックよりも優先され、それをプリエンプトできます）。。展開されたネットワークでは、IP Precedenceフィールドのブリーチング（つまり、意図的にゼロに設定）が引き続き使用されます。（IP Precedenceフィールドをゼロに設定すると、TOSベースのパケット処理で構成されたルーターによるクラスベースのフロー管理が無効になります。）これにより、以前のTOSバイトの最初の3ビット（現在はDSCPフィールドの上部）がゼロになります。。したがって、最初の3ビット[LE-PHB]にすでにゼロ値があるコードポイントを割り当てることにより、LE PHBのDSCPのこの再マッピングを回避する必要があります。

Furthermore, if the LE PHB were to have been assigned one of the currently unused Pool 1 codepoints with a zero value in the first three bits, any bleaching of the IP Precedence field would result in other (higher assurance) traffic being also remapped to the assigned DSCP. This remapping could then cause Diffserv-marked traffic to receive an unintentional LE treatment for the remainder of the Internet path. Therefore, it is important to avoid the resulting priority inversion. The absence of unassigned codepoints in Pool 1 that exhibit these important properties motivates assigning a Pool 3 codepoint as the default that is recommended for use with this PHB.

さらに、LE PHBに最初の3ビットがゼロの値で現在使用されていないプール1コードポイントの1つが割り当てられている場合、IP Precedenceフィールドのブリーチングにより、他の（より高い保証）トラフィックもに再マッピングされます。割り当てられたDSCP。この再マッピングにより、Diffservでマークされたトラフィックが、インターネットパスの残りの部分で意図しないLE処理を受け取る可能性があります。したがって、結果として生じる優先順位の逆転を回避することが重要です。これらの重要なプロパティを示すプール1に未割り当てのコードポイントがないことは、このPHBでの使用が推奨されるデフォルトとしてプール3のコードポイントを割り当てる動機になります。

To allow the IETF to utilize Pool 3 codepoints, this document requests IANA to manage Pool 3 assignments for DSCP values in Pool 3 via the Standards Action policy [RFC8126].

IETFがプール3コードポイントを利用できるようにするために、このドキュメントでは、標準アクションポリシー[RFC8126]を介して、プール3のDSCP値に対するプール3割り当てを管理するようIANAに要求します。

2. Terminology

2. 用語

This document assumes familiarity with the terminology used in [RFC2475] updated by [RFC3260].

このドキュメントは、[RFC3260]によって更新された[RFC2475]で使用される用語に精通していることを前提としています。

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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. The Updates to RFC 2474

3. RFC 2474の更新

This document updates Section 6 of [RFC2474] in the following ways.

このドキュメントは、[RFC2474]のセクション6を次のように更新します。

It updates the following text concerning the assignment policy:

割り当てポリシーに関する次のテキストを更新します。

OLD: which are initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted.

OLD：最初は実験的またはローカルで使用できますが、プール1が使い果たされた場合は、標準化された割り当てに優先的に使用する必要があります。

NEW: which are utilized for standardized assignments (replacing the previous availability for experimental or local use).

NEW：標準化された割り当てに使用されます（実験的またはローカルで使用するための以前の可用性を置き換えます）。

It removes the footnote in RFC 2474 relating to Pool 3:

これは、プール3に関連するRFC 2474の脚注を削除します。

DELETE: "(*) may be utilized for future Standards Action allocations as necessary"

削除：「（*）は、必要に応じて将来の標準アクションの割り当てに使用される可能性があります」

The new registry assignment policy is shown in Figure 2.

新しいレジストリ割り当てポリシーを図2に示します。

       Pool  Codepoint Space  Assignment Policy
       ----  --------------- ------------------
        1         xxxxx0      Standards Action
        2         xxxx11      EXP/LU
        3         xxxx01      Standards Action

Note for Pool 2: "Reserved for Experimental or Local Use"

プール2に関する注意：「実験的またはローカル使用のために予約済み」

Figure 2: Updated Assignment Policy for the DSCP Registry

図2：DSCPレジストリの更新された割り当てポリシー

4. Security Considerations

4. セキュリティに関する考慮事項

Security considerations for the use of DSCP values are described in the RFCs that define their usage. This document does not present new security considerations.

DSCP値の使用に関するセキュリティの考慮事項は、その使用法を定義するRFCに記載されています。このドキュメントでは、セキュリティに関する新しい考慮事項については説明していません。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has changed the use of Pool 3 in the "Differentiated Services Field Codepoints (DSCP)" registry and will manage this pool using Standards Action, as defined as Section 4.9 of [RFC8126].

IANAは「Differentiated Services Field Codepoints（DSCP）」レジストリのプール3の使用を変更し、[RFC8126]のセクション4.9で定義されているように、標準アクションを使用してこのプールを管理します。

IANA has made the following changes to the "Differentiated Services Field Codepoints (DSCP)" registry, made available at [Registry].

IANAは、[Differentiated Services Field Codepoints（DSCP）]レジストリを次のように変更し、[レジストリ]で利用できるようにしました。

IANA has referenced RFC 2474 and Section 4 of RFC 3260 for the overall format of this registry.

IANAは、このレジストリの全体的な形式についてRFC 2474およびRFC 3260のセクション4を参照しています。

IANA has referenced RFC 2474 and Section 4 of RFC 3260 for Pool 1.

IANAは、プール1についてRFC 2474およびRFC 3260のセクション4を参照しています。

This document does not modify the IANA registry text for Pool 2. This pool continues to preserve the note shown in Figure 2.

このドキュメントは、プール2のIANAレジストリテキストを変更しません。このプールは、図2に示すメモを保持し続けます。

The previous registry text for Pool 3:

プール3の以前のレジストリテキスト：

3 xxxx01 Experimental or local use may be utilized for future Standards Action allocations as necessary.

3 xxxx01実験的またはローカルでの使用は、必要に応じて将来の標準アクションの割り当てに利用できます。

is replaced with the following registry text:

次のレジストリテキストに置き換えられます。

3 xxxx01 Standards Action.

3 xxxx01標準アクション。

To manage codepoints in Pool 3, IANA has created and will maintain the "DSCP Pool 3 Codepoints" subregistry. Pool 3 of the registry has been created initially empty, with a format identical to that used for "DSCP Pool 1 Codepoints".

プール3のコードポイントを管理するために、IANAは「DSCPプール3コードポイント」サブレジストリを作成し、維持します。レジストリのプール3は、「DSCPプール1コードポイント」で使用されるものと同じ形式で、最初は空で作成されています。

IANA has referenced RFC 2474, Section 4 of RFC 3260, and the current document for Pool 3.

IANAはRFC 2474、RFC 3260のセクション4、およびプール3の最新のドキュメントを参照しています。

The registration procedure for use of Pool 3 is Standards Action, as defined as Section 4.9 of [RFC8126]. IANA is expected to normally make assignments from Pool 1, until this Pool is exhausted, but it MAY make assignments from Pool 3 when the format of the codepoint has properties that are needed for a specific PHB. The required characteristics for choosing a requested DSCP value MUST be explained in the IANA Considerations section of the document that requests any assignment from Pool 3.

[RFC8126]のセクション4.9で定義されているように、プール3の使用の登録手順は標準アクションです。 IANAは通常、このプールがなくなるまでプール1から割り当てを行うと予想されますが、コードポイントの形式に特定のPHBに必要なプロパティがある場合、プール3から割り当てを行う場合があります。要求されたDSCP値を選択するために必要な特性は、プール3からの割り当てを要求するドキュメントのIANAの考慮事項セクションで説明する必要があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[Registry] IANA, "Differentiated Services Field Codepoints (DSCP)", <https://www.iana.org/assignments/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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.

[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、DOI 10.17487 / RFC3260、2002年4月、<https://www.rfc-editor.org/info/rfc3260>。

[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>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

6.2. Informative References

6.2. 参考引用

[LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Work in Progress, draft-ietf-tsvwg-le-phb-05, July 2018.

[LE-PHB]祝福、R。、「低ホップのPer-Hop動作（LE PHB）」、作業中、draft-ietf-tsvwg-le-phb-05、2018年7月。

[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>.

[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>。

Acknowledgments

謝辞

Godred Fairhurst received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644334 (NEAT).

Godred Fairhurstは、EUのHorizon 2020研究およびイノベーションプログラム2014-2018から、助成金契約番号644334（NEAT）の下で資金を受け取りました。

Author's Address

著者のアドレス

Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom

Godredフェアハーストアバディーン大学工学部フレーザーノーブルビルディングアバディーンAB24 3UEイギリス

   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk/