[要約] RFC 8622は、Differentiated Services（DiffServ）のためのLower-Effort Per-Hop Behavior（LE PHB）に関するものであり、低優先度のトラフィックを扱うためのガイドラインを提供しています。このRFCの目的は、ネットワーク上でのトラフィックの優先度を制御し、リソースの効率的な使用を促進することです。
Internet Engineering Task Force (IETF) R. Bless
Request for Comments: 8622 KIT
Obsoletes: 3662 June 2019
Updates: 4594, 8325
Category: Standards Track
ISSN: 2070-1721
A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
差別化されたサービスのための低努力のホップごとの動作（LE PHB）
Abstract
概要
This document specifies properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.
このドキュメントでは、ローエフォート型のホップ単位の動作（LE PHB）のプロパティと特性を指定します。このLE PHBの主な目的は、輻輳状況でLEトラフィックからベストエフォート（BE）トラフィック（デフォルトのPHBで転送されるパケット）を保護することです。つまり、リソースが不足すると、BEトラフィックがLEトラフィックより優先され、それを優先する可能性があります。 。あるいは、LE PHBによって転送されたパケットは、スカベンジャーサービスクラスに関連付けることができます。つまり、それらは、それ以外の場合は未使用のリソースのみを清掃します。このPHBには多くの用途があります。たとえば、優先度の低いバックグラウンドトラフィック、たとえば、タイムプライオリティが低いバルクデータ転送、タイムクリティカルでないバックアップ、大規模なソフトウェアアップデート、ウェブサーバーからの情報収集中のウェブ検索エンジンなどです。オン。このドキュメントでは、LE PHBに標準のDiffServコードポイント（DSCP）値を推奨しています。
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.
この仕様はRFC 3662を廃止し、RFC 4594および8325で推奨されているDSCPを更新して、この仕様で割り当てられている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/rfc8622.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8622で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Applicability ...................................................3
4. PHB Description .................................................6
5. Traffic-Conditioning Actions ....................................7
6. Recommended DSCP ................................................7
7. Deployment Considerations .......................................8
8. Re-marking to Other DSCPs/PHBs ..................................9
9. Multicast Considerations .......................................10
10. The Updates to RFC 4594 .......................................11
11. The Updates to RFC 8325 .......................................12
12. IANA Considerations ...........................................13
13. Security Considerations .......................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................15
Appendix A. History of the LE PHB .................................18
Acknowledgments ...................................................18
Author's Address ..................................................18
This document defines a Differentiated Services (DS) per-hop behavior [RFC2474] called "Lower-Effort Per-Hop Behavior" (LE PHB), which is intended for traffic of sufficiently low urgency that all other traffic takes precedence over the LE traffic in consumption of network link bandwidth. Low-urgency traffic has a low priority for timely forwarding; note, however, that this does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be considered as a network equivalent to a background priority for processes in an operating system. There may or may not be memory (buffer) resources allocated for this type of traffic.
このドキュメントでは、 "Lower-Effort Per-Hop Behavior"（LE PHB）と呼ばれるDiffServ（DS）のホップごとの動作[RFC2474]を定義しています。これは、他のすべてのトラフィックがLEトラフィックよりも優先されるほど緊急度が低いトラフィックを対象としています。ネットワークリンク帯域幅の消費量。緊急度の低いトラフィックは、タイムリーな転送の優先度が低くなっています。ただし、これは必ずしも一般的に重要性が低いことを意味するわけではありません。この観点からは、オペレーティングシステムのプロセスのバックグラウンド優先度に相当するネットワークと見なすことができます。このタイプのトラフィックに割り当てられるメモリ（バッファ）リソースがある場合とない場合があります。
Some networks carry packets that ought to consume network resources only when no other traffic is demanding them. From this point of view, packets forwarded by the LE PHB scavenge otherwise-unused resources only; this led to the name "scavenger service" in early Internet2 deployments (see Appendix A). Other commonly used names for LE PHB types of services are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003]. In summary, with the above-mentioned feature, the LE PHB has two important properties: it should scavenge residual capacity, and it must be preemptable by the default PHB (or other elevated PHBs) in case they need more resources. Consequently, the effect of this type of traffic on all other network traffic is strictly limited (the "no harm" property). This is distinct from "Best-Effort" (BE) traffic, since the network makes no commitment to deliver LE packets. In contrast, BE traffic receives an implied "good faith" commitment of at least some available network resources. This document proposes an LE DS PHB for handling this "optional" traffic in a DS node.
一部のネットワークは、他のトラフィックが要求していないときにのみネットワークリソースを消費するはずのパケットを伝送します。この観点から見ると、LE PHBによって転送されたパケットは、それ以外は未使用のリソースのみを清掃します。これにより、初期のInternet2展開では「スカベンジャーサービス」という名前になりました（付録Aを参照）。 LE PHBタイプのサービスで一般的に使用される他の名前は、「ベストエフォートより低い」[Carlberg-LBE-2001]または「ベストエフォートより低い」[Chown-LBE-2003]です。要約すると、上記の機能により、LE PHBには2つの重要な特性があります。それは、残りの容量を清掃する必要があること、およびより多くのリソースが必要な場合にデフォルトのPHB（または他の昇格されたPHB）によってプリエンプション可能である必要があることです。したがって、このタイプのトラフィックが他のすべてのネットワークトラフィックに与える影響は厳しく制限されています（「害のない」プロパティ）。これは、ネットワークがLEパケットの配信を約束しないため、「ベストエフォート」（BE）トラフィックとは異なります。対照的に、BEトラフィックは、少なくともいくつかの利用可能なネットワークリソースの暗黙の「誠意」のあるコミットメントを受け取ります。このドキュメントでは、DSノードでこの「オプション」トラフィックを処理するためのLE DS PHBを提案します。
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]で説明されているように解釈されます。
An LE PHB is applicable for many applications that otherwise use BE delivery. More specifically, it is suitable for traffic and services that can tolerate strongly varying throughput for their data flows, especially periods of very low throughput or even starvation (i.e., long interruptions due to significant or even complete packet loss). Therefore, an application sending an LE-marked flow needs to be able to tolerate short or (even very) long interruptions due to the presence of severe congestion conditions during the transmission of the flow. Thus, there ought to be an expectation that packets of the LE PHB could be excessively delayed or dropped when any other traffic is present. Whether or not a lack of progress is considered to be a failure is application dependent (e.g., if a transport connection fails due to timing out, the application may try several times to reestablish the transport connection in order to resume the application session before finally giving up). The LE PHB is suitable for sending traffic of low urgency across a DS domain or DS region.
LE PHBは、BE配信を使用する多くのアプリケーションに適用できます。より具体的には、データフローの大幅に変化するスループット、特に非常に低いスループットの期間、または飢餓状態（つまり、大幅なパケット損失または完全なパケット損失による長時間の中断）を許容できるトラフィックおよびサービスに適しています。したがって、LEマークの付いたフローを送信するアプリケーションは、フローの送信中に深刻な輻輳状態が存在するため、短い中断または（非常に）長い中断を許容できる必要があります。したがって、他のトラフィックが存在する場合、LE PHBのパケットが過度に遅延またはドロップされる可能性があると予想されるはずです。進行状況の欠如が失敗と見なされるかどうかは、アプリケーションに依存します（たとえば、タイムアウトが原因でトランスポート接続が失敗した場合、アプリケーションは、トランスポート接続の再確立を数回試行して、最終的にアプリケーションセッションを再開することができます。アップ）。 LE PHBは、DSドメインまたはDSリージョン全体で緊急度の低いトラフィックを送信するのに適しています。
Just like BE traffic, LE traffic SHOULD be congestion controlled (i.e., use a congestion controlled transport or implement an appropriate congestion control method [RFC2914] [RFC8085]). Since LE traffic could be starved completely for a longer period of time, transport protocols or applications (and their related congestion control mechanisms) SHOULD be able to detect and react to such a starvation situation. An appropriate reaction would be to resume the transfer instead of aborting it, i.e., an LE-optimized transport ought to use appropriate retry strategies (e.g., exponential back-off with an upper bound) as well as corresponding retry and timeout limits in order to avoid the loss of the connection due to the above-mentioned starvation periods. While it is desirable to achieve a quick resumption of the transfer as soon as resources become available again, it may be difficult to achieve this in practice. In the case of a lack of a transport protocol and congestion control that are adapted to LE, applications can also use existing common transport protocols and implement session resumption by trying to reestablish failed connections. Congestion control is not only useful for letting the flows within the LE Behavior Aggregate (BA) adapt to the available bandwidth, which may be highly fluctuating; it is also essential if LE traffic is mapped to the default PHB in DS domains that do not support LE. In this case, the use of background transport protocols, e.g., similar to Low Extra Delay Background Transport (LEDBAT) [RFC6817], is expedient.
BEトラフィックと同様に、LEトラフィックは輻輳制御する必要があります（つまり、輻輳制御トランスポートを使用するか、適切な輻輳制御方法を実装します[RFC2914] [RFC8085]）。 LEトラフィックは長期間にわたって完全に枯渇する可能性があるため、トランスポートプロトコルまたはアプリケーション（およびそれらに関連する輻輳制御メカニズム）は、そのような飢餓状態を検出して対応できる必要があります（SHOULD）。適切な対応は、転送を中止する代わりに再開することです。つまり、LE最適化トランスポートは、適切な再試行戦略（たとえば、上限付きの指数バックオフ）と、対応する再試行およびタイムアウト制限を使用して、上記の飢餓期間が原因で接続が失われるのを避けます。リソースが再び利用可能になるとすぐに転送の迅速な再開を実現することが望ましいですが、実際にはこれを実現するのは難しい場合があります。 LEに適合したトランスポートプロトコルと輻輳制御がない場合、アプリケーションは既存の一般的なトランスポートプロトコルを使用し、失敗した接続の再確立を試みることでセッション再開を実装することもできます。輻輳制御は、LE Behavior Aggregate（BA）内のフローを利用可能な帯域幅に適応させるだけでなく、非常に変動しやすい場合があります。 LEをサポートしないDSドメインのデフォルトのPHBにLEトラフィックがマッピングされている場合も重要です。この場合、バックグラウンドトランスポートプロトコル（たとえば、低遅延遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]など）を使用すると便利です。
The use of the LE PHB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Furthermore, packets can be designated for the LE PHB when the goal is to protect all other packet traffic from competition with the LE aggregate while not completely banning LE traffic from the network. An LE PHB SHOULD NOT be used for a customer's "normal Internet" traffic and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped, particularly when the packets are unauthorized traffic. The LE PHB is expected to have applicability in networks that have at least some unused capacity during certain periods.
LE PHBの使用は、ネットワークオペレーターが特定の種類のトラフィックまたはユーザーをオフピーク時間に移動するのに役立つ場合があります。さらに、ネットワークからのLEトラフィックを完全に禁止せずに、他のすべてのパケットトラフィックをLEアグリゲートとの競合から保護することを目的とする場合、パケットをLE PHBに指定できます。 LE PHBはお客様の「通常のインターネット」トラフィックには使用しないでください。特にパケットが不正なトラフィックである場合、パケットをドロップするのではなく、LE PHBに「ダウングレード」しないでください。 LE PHBは、特定の期間中に少なくともいくつかの未使用の容量があるネットワークに適用可能であると予想されます。
The LE PHB allows networks to protect themselves from selected types of traffic as a complement to giving preferential treatment to other selected traffic aggregates. LE ought not be used for the general case of downgraded traffic, but it could be used by design, e.g., to protect an internal network from untrusted external traffic sources. In this case, there is no way for attackers to preempt internal (non-LE) traffic by flooding. Another use case in this regard is the forwarding of multicast traffic from untrusted sources. Multicast forwarding is currently enabled within domains only for specific sources within a domain -- not for sources from anywhere in the Internet. One major problem is that multicast routing creates traffic sources at (mostly) unpredictable branching points within a domain, potentially leading to congestion and packet loss. In the case where multicast traffic packets from untrusted sources are forwarded as LE traffic, they will not harm traffic from non-LE BAs. A further related use case is mentioned in [RFC3754]: preliminary forwarding of non-admitted multicast traffic.
LE PHBを使用すると、ネットワークは、他の選択されたトラフィック集合体を優先的に処理することを補完するものとして、選択されたタイプのトラフィックから自分自身を保護できます。ダウングレードされたトラフィックの一般的なケースではLEを使用すべきではありませんが、信頼できない外部トラフィックソースから内部ネットワークを保護するなどの目的で使用できます。この場合、攻撃者がフラッディングによって内部（非LE）トラフィックを横取りする方法はありません。これに関するもう1つの使用例は、信頼できないソースからのマルチキャストトラフィックの転送です。マルチキャスト転送は現在、ドメイン内の特定のソースに対してのみドメイン内で有効になっており、インターネットのどこからのソースに対しても有効ではありません。主な問題の1つは、マルチキャストルーティングがドメイン内の（主に）予測不可能な分岐点にトラフィックソースを作成し、輻輳やパケット損失につながる可能性があることです。信頼できないソースからのマルチキャストトラフィックパケットがLEトラフィックとして転送される場合、それらは非LE BAからのトラフィックに害を及ぼすことはありません。 [RFC3754]では、さらに関連するユースケースについて言及しています。許可されていないマルチキャストトラフィックの予備転送です。
There is no intrinsic reason to limit the applicability of the LE PHB to any particular application or type of traffic. It is intended as an additional traffic engineering tool for network administrators. For instance, it can be used to fill protection capacity of transmission links that is otherwise unused. Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf. Section 6 of [RFC3439]). LE-marked traffic can utilize the normally unused capacity and will be preempted automatically in the case of link failure when 100% of the link capacity is required for all other traffic. Ideally, applications mark their packets as LE traffic, because they know the urgency of flows. Since LE traffic may be starved for longer periods of time, it is probably less suitable for real-time and interactive applications.
LE PHBの適用を特定のアプリケーションまたはトラフィックのタイプに制限する本質的な理由はありません。これは、ネットワーク管理者向けの追加のトラフィックエンジニアリングツールとして意図されています。たとえば、他の方法では使用されていない伝送リンクの保護容量を満たすために使用できます。一部のネットワークプロバイダーは、リンク障害によって引き起こされた再ルーティング後、すべてのトラフィックが損失なしに転送されるように、リンク使用率を50％未満に維持しています（[RFC3439]のセクション6を参照）。 LEマークの付いたトラフィックは、通常は未使用の容量を利用でき、リンク障害が発生した場合、他のすべてのトラフィックにリンク容量の100％が必要なときに自動的にプリエンプトされます。理想的には、アプリケーションはフローの緊急度を知っているため、パケットをLEトラフィックとしてマークします。 LEトラフィックは長時間にわたって枯渇する可能性があるため、リアルタイムアプリケーションやインタラクティブアプリケーションにはあまり適していません。
Example uses for the LE PHB:
LE PHBの使用例：
o For traffic caused by World Wide Web search engines while they gather information from web servers.
o Webサーバーから情報を収集しているときに、World Wide Web検索エンジンによって引き起こされるトラフィック用。
o For software updates or dissemination of new releases of operating systems.
o ソフトウェアの更新またはオペレーティングシステムの新しいリリースの普及。
o For reporting errors or telemetry data from operating systems or applications.
o オペレーティングシステムまたはアプリケーションからのエラーまたはテレメトリデータのレポート用。
o For backup traffic, non-time-critical synchronization, or mirroring traffic.
o バックアップトラフィック、非タイムクリティカルな同期、またはミラーリングトラフィック。
o For content distribution transfers between caches.
o キャッシュ間のコンテンツ配信転送。
o For preloading or prefetching objects from web sites.
o Webサイトからオブジェクトをプリロードまたはプリフェッチします。
o For network news and other "bulk mail" of the Internet.
o ネットワークニュースおよびその他のインターネットの「バルクメール」。
o For "downgraded" traffic from some other PHB when this does not violate the operational objectives of the other PHB.
o 他のPHBの運用目標に違反していない場合に、他のPHBからの「ダウングレードされた」トラフィックの場合。
o For multicast traffic from untrusted (e.g., non-local) sources.
o 信頼できない（たとえば、ローカルでない）ソースからのマルチキャストトラフィックの場合。
The LE PHB is defined in relation to the default PHB (BE). A packet forwarded with the LE PHB SHOULD have lower precedence than packets forwarded with the default PHB, i.e., in the case of congestion, LE-marked traffic SHOULD be dropped prior to dropping any default PHB traffic. Ideally, LE packets would be forwarded only when no packet with any other PHB is awaiting transmission. This means that in the case of link resource contention LE traffic can be starved completely, which may not always be desired by the network operator's policy. A scheduler used to implement the LE PHB may reflect this policy accordingly.
LE PHBは、デフォルトのPHB（BE）に関連して定義されます。 LE PHBで転送されたパケットは、デフォルトのPHBで転送されたパケットよりも優先順位が低くなるはずです。つまり、輻輳の場合、LEマークの付いたトラフィックは、デフォルトのPHBトラフィックをドロップする前にドロップする必要があります。理想的には、LEパケットは、他のPHBを持つパケットが送信を待機していない場合にのみ転送されます。これは、リンクリソースの競合が発生した場合、LEトラフィックが完全に枯渇する可能性があることを意味します。これは、ネットワークオペレーターのポリシーで常に望ましいとは限りません。 LE PHBの実装に使用されるスケジューラは、このポリシーを適宜反映する場合があります。
A straightforward implementation could be a simple priority scheduler serving the default PHB queue with higher priority than the LE PHB queue. Alternative implementations may use scheduling algorithms that assign a very small weight to the LE class. This, however, could sometimes cause better service for LE packets compared to BE packets in cases when the BE share is fully utilized and the LE share is not.
単純な実装は、LE PHBキューよりも高い優先度でデフォルトのPHBキューを提供する単純な優先度スケジューラである可能性があります。代替実装では、LEクラスに非常に小さな重みを割り当てるスケジューリングアルゴリズムを使用できます。ただし、これにより、BE共有が完全に利用され、LE共有が利用されない場合、BEパケットと比較してLEパケットのサービスが向上することがあります。
If a dedicated LE queue is not available, an active queue management mechanism within a common BE/LE queue could also be used. This could drop all arriving LE packets as soon as certain queue length or sojourn time thresholds are exceeded.
専用のLEキューが使用できない場合は、共通のBE / LEキュー内のアクティブなキュー管理メカニズムも使用できます。これは、特定のキューの長さまたは滞在時間のしきい値を超えるとすぐに、到着するすべてのLEパケットをドロップする可能性があります。
Since congestion control is also useful within the LE traffic class, Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for LE packets, too. More specifically, an LE implementation SHOULD also apply Congestion Experienced (CE) marking for ECT-marked packets ("ECT" stands for ECN-Capable Transport), and transport protocols used for LE SHOULD support and employ ECN. For more information on the benefits of using ECN, see [RFC8087].
輻輳制御はLEトラフィッククラス内でも役立つため、LEパケットに対しても明示的輻輳通知（ECN）[RFC3168]を使用する必要があります（SHOULD）。より具体的には、LE実装は、ECTマーク付きパケット（「ECT」はECN対応トランスポートの略）にCongestion Experienced（CE）マーキングを適用し、LECがECNをサポートおよび採用するために使用するトランスポートプロトコルを適用する必要があります。 ECNを使用する利点の詳細については、[RFC8087]を参照してください。
If possible, packets SHOULD be pre-marked in DS-aware end systems by applications due to their specific knowledge about the particular precedence of packets. There is no incentive for DS domains to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm. Thus, any policing, such as limiting the rate of LE traffic, is not necessary at the DS boundary.
可能であれば、パケットの特定の優先順位に関する特定の知識のために、アプリケーションによってDS対応のエンドシステムでパケットに事前マークを付ける必要があります（SHOULD）。 LEトラフィックをDSドメインに入らせても害はないので、DSドメインがこの最初のマーキングを信用しないようにする動機はありません。したがって、DS境界では、LEトラフィックのレートを制限するなどのポリシングは必要ありません。
As for most other PHBs, an initial classification and marking can also be performed at the first DS boundary node according to the DS domain's own policies (e.g., as a protection measure against untrusted sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be re-marked to LE. Re-marking traffic from another PHB results in that traffic being "downgraded". This changes the way the network treats this traffic, and it is important not to violate the operational objectives of the original PHB. See Sections 3 and 8 for notes related to downgrading.
他のほとんどのPHBと同様に、最初のDS境界ノードで、DSドメイン自体のポリシーに従って（たとえば、信頼できないソースに対する保護手段として）初期の分類とマーキングを実行することもできます。ただし、LE以外のトラフィック（BEトラフィックなど）は、LEに再マーキングしないでください。別のPHBからのトラフィックを再マーキングすると、そのトラフィックは「ダウングレード」されます。これにより、ネットワークがこのトラフィックを処理する方法が変わります。元のPHBの運用目標に違反しないことが重要です。ダウングレードに関する注意事項については、セクション3および8を参照してください。
The RECOMMENDED codepoint for the LE PHB is '000001'.
LE PHBの推奨コードポイントは「000001」です。
Earlier specifications (e.g., [RFC4594]) recommended the use of Class Selector 1 (CS1) as the codepoint (as mentioned in [RFC3662]). This is problematic, since it may cause a priority inversion in Diffserv domains that treat CS1 as originally proposed in [RFC2474], resulting in forwarding LE packets with higher precedence than BE packets. Existing implementations SHOULD transition to use the unambiguous LE codepoint '000001' whenever possible.
以前の仕様（[RFC4594]など）では、クラスポイントセレクター1（CS1）をコードポイントとして使用することを推奨していました（[RFC3662]で説明）。これは、[RFC2474]で最初に提案されたようにCS1を扱うDiffservドメインで優先順位の逆転を引き起こし、BEパケットよりも優先度の高いLEパケットを転送する可能性があるため、問題があります。既存の実装では、可能な限り明確なLEコードポイント「000001」を使用するように移行する必要があります。
This particular codepoint was chosen due to measurements on the currently observable Differentiated Services Code Point (DSCP) re-marking behavior in the Internet [IETF99-Secchi]. Since some network domains set the former IP Precedence bits to zero, it is possible that some other standardized DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP Standards Action Pool 1 (xxxxx0) [RFC2474] [RFC8436].
この特定のコードポイントは、インターネット[IETF99-Secchi]で現在観測可能なDSCP（Differentiated Services Code Point）の再マーキング動作を測定したために選択されました。一部のネットワークドメインは以前のIP Precedenceビットをゼロに設定するため、DSCP標準アクションプール1（xxxxx0）[RFC2474] [RFC8436]から取得された場合、他の一部の標準化DSCPがLE PHB DSCPにマッピングされる可能性があります。
In order to enable LE support, DS nodes typically only need
LEサポートを有効にするために、DSノードは通常、
o A BA classifier (see [RFC2475]) that classifies packets according to the LE DSCP
o LE DSCPに従ってパケットを分類するBA分類子（[RFC2475]を参照）
o A dedicated LE queue
o 専用LEキュー
o A suitable scheduling discipline, e.g., simple priority queueing
o 単純な優先キューイングなどの適切なスケジューリング規則
Alternatively, implementations could use active queue management mechanisms instead of a dedicated LE queue, e.g., dropping all arriving LE packets when certain queue length or sojourn time thresholds are exceeded.
または、実装では、専用のLEキューの代わりにアクティブなキュー管理メカニズムを使用することもできます。たとえば、特定のキューの長さまたは滞在時間のしきい値を超えたときに、到着するすべてのLEパケットをドロップします。
Internet-wide deployment of the LE PHB is eased by the following properties:
LE PHBのインターネット全体への展開は、次のプロパティによって容易になります。
o No harm to other traffic: since the LE PHB has the lowest forwarding priority, it does not consume resources from other PHBs. Deployment across different provider domains with LE support causes no trust issues or attack vectors to existing (non-LE) traffic. Thus, providers can trust LE markings from end systems, i.e., there is no need to police or re-mark incoming LE traffic.
o 他のトラフィックへの害はありません：LE PHBは最低の転送優先度を持つため、他のPHBからのリソースを消費しません。 LEをサポートする異なるプロバイダードメインに展開しても、既存の（非LE）トラフィックに対する信頼の問題や攻撃ベクトルは発生しません。したがって、プロバイダーはエンドシステムからのLEマーキングを信頼できます。つまり、着信LEトラフィックをポリシングまたは再マーキングする必要はありません。
o No PHB parameters or configuration of traffic profiles: the LE PHB itself possesses no parameters that need to be set or configured. Similarly, since LE traffic requires no admission or policing, it is not necessary to configure traffic profiles.
o PHBパラメータやトラフィックプロファイルの構成はありません。LEPHB自体には、設定または構成する必要のあるパラメータはありません。同様に、LEトラフィックはアドミッションまたはポリシングを必要としないため、トラフィックプロファイルを設定する必要はありません。
o No traffic-conditioning mechanisms: the LE PHB requires no traffic meters, droppers, or shapers. See also Section 5 for further discussion.
o トラフィック調整メカニズムなし：LE PHBにはトラフィックメーター、ドロッパー、シェーパーは必要ありません。詳細については、セクション5も参照してください。
Operators of DS domains that cannot or do not want to implement the LE PHB (e.g., because there is no separate LE queue available in the corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP. They SHOULD map packets with this DSCP to the default PHB and SHOULD preserve the LE DSCP marking. DS domain operators that do not implement the LE PHB should be aware that they violate the "no harm" property of LE. See also Section 8 for further discussion of forwarding LE traffic with the default PHB instead of the LE PHB.
LE PHBを実装できない、または実装したくないDSドメインのオペレーター（たとえば、対応するノードに使用可能な個別のLEキューがないため）は、LE DSCPでマークされたパケットをドロップしないでください。彼らは、このDSCPを持つパケットをデフォルトのPHBにマップする必要があり（SHOULD）、LE DSCPマーキングを保持する必要があります（SHOULD）。 LE PHBを実装していないDSドメインオペレーターは、LEの「害のない」特性に違反していることに注意する必要があります。 LE PHBの代わりにデフォルトのPHBでLEトラフィックを転送する方法の詳細については、セクション8も参照してください。
"DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is NOT RECOMMENDED for this PHB. This may cause effects that are in contrast to the original intent to protect BE traffic from LE traffic (the "no harm" property). In the case that a DS domain does not support the LE PHB, its nodes SHOULD treat LE-marked packets with the default PHB instead (by mapping the LE DSCP to the default PHB), but they SHOULD do so without re-marking to DSCP '000000'. This is because DS domains that are traversed later may then still have the opportunity to treat such packets according to the LE PHB.
「DSCPブリーチング」、つまりDSCPを「000000」（デフォルトのPHB）に設定することは、このPHBでは推奨されません。これにより、LEトラフィックからBEトラフィックを保護するという本来の目的（「害のない」プロパティ）とは対照的な影響が生じる可能性があります。 DSドメインがLE PHBをサポートしていない場合、そのノードはLEマークの付いたパケットをデフォルトのPHBで処理する必要があります（LE DSCPをデフォルトのPHBにマッピングすることにより）が、DSCPに再度マークすることなく処理する必要があります（SHOULD）。 「000000」。これは、後でトラバースされるDSドメインでも、LE PHBに従ってそのようなパケットを処理する機会がまだあるためです。
Operators of DS domains that forward LE traffic within the BE aggregate need to be aware of the implications, i.e., induced congestion situations and QoS degradation of the original BE traffic. In this case, the LE property of not harming other traffic is no longer fulfilled. To limit the impact in such cases, traffic policing of the LE aggregate MAY be used.
BEアグリゲート内でLEトラフィックを転送するDSドメインのオペレーターは、その影響、つまり、元のBEトラフィックの誘導された輻輳状況とQoSの低下に注意する必要があります。この場合、他のトラフィックに害を及ぼさないというLEの特性は満たされなくなります。そのような場合の影響を制限するために、LEアグリゲートのトラフィックポリシングが使用される場合があります。
In the case that LE-marked packets are effectively carried with the default PHB (i.e., forwarded as BE traffic), they get a better forwarding treatment than expected. For some applications and services, it is favorable if the transmission is finished earlier than expected. However, in some cases, it may be against the original intention of the LE PHB user to strictly send the traffic only if otherwise-unused resources are available. In the case that LE traffic is mapped to the default PHB, LE traffic may compete with BE traffic for the same resources and thus adversely affect the original BE aggregate. Applications that want to ensure the lower precedence compared to BE traffic even in such cases SHOULD additionally use a corresponding lower-than-BE transport protocol [RFC6297], e.g., LEDBAT [RFC6817].
LEマークの付いたパケットがデフォルトのPHBで効果的に伝送される（つまり、BEトラフィックとして転送される）場合、予想よりも優れた転送処理が行われます。一部のアプリケーションおよびサービスでは、送信が予想よりも早く終了することが望ましいです。ただし、場合によっては、LE PHBユーザーの本来の意図に反して、他に使用されていないリソースが利用できる場合にのみトラフィックを厳密に送信することもあります。 LEトラフィックがデフォルトのPHBにマッピングされている場合、LEトラフィックは同じリソースのBEトラフィックと競合し、元のBE集約に悪影響を与える可能性があります。このような場合でもBEトラフィックと比較して優先順位を低くしたいアプリケーションは、対応するBE未満のトランスポートプロトコル[RFC6297]、たとえばLEDBAT [RFC6817]をさらに使用する必要があります（SHOULD）。
A DS domain that still uses DSCP CS1 for marking LE traffic (including Low-Priority Data as defined in [RFC4594] or the old definition in [RFC3662]) SHOULD re-mark traffic to the LE DSCP '000001' at the egress to the next DS domain. This increases the probability that the DSCP is preserved end to end, whereas a CS1-marked packet may be re-marked by the default DSCP if the next domain is applying Diffserv-Interconnection [RFC8100].
LEトラフィックのマーキングにDSCP CS1を引き続き使用するDSドメイン（[RFC4594]で定義された低優先度データまたは[RFC3662]での古い定義を含む）は、出口への出口でLE DSCP '000001'にトラフィックを再マーキングする必要があります（SHOULD）次のDSドメイン。これにより、DSCPがエンドツーエンドで保持される可能性が高くなりますが、CS1でマークされたパケットは、次のドメインがDiffserv-Interconnection [RFC8100]を適用している場合、デフォルトのDSCPによって再度マークされる可能性があります。
Basically, the multicast considerations in [RFC3754] apply. However, using the LE PHB for multicast requires paying special attention to how packets get replicated inside routers. Due to multicast packet replication, resource contention may actually occur even before a packet is forwarded to its output port. In the worst case, these forwarding resources are missing for higher-priority multicast or even unicast packets.
基本的に、[RFC3754]のマルチキャストに関する考慮事項が適用されます。ただし、LE PHBをマルチキャストに使用するには、パケットがルーター内部で複製される方法に特別な注意を払う必要があります。マルチキャストパケットの複製により、パケットがその出力ポートに転送される前でも、リソースの競合が実際に発生する可能性があります。最悪の場合、これらの転送リソースは、優先度の高いマルチキャストまたはユニキャストパケットでも失われます。
Several forward error correction coding schemes, such as fountain codes (e.g., [RFC5053]), allow reliable data delivery even in environments with a potentially high amount of packet loss in transmission. When used, for example, over satellite links or other broadcast media, this means that receivers that lose 80% of packets in transmission simply need five times longer to receive the complete data than those receivers experiencing no loss (without any receiver feedback required).
ファウンテンコード（[RFC5053]など）などのいくつかの前方誤り訂正符号化方式は、伝送でパケット損失が大量に発生する可能性がある環境でも信頼性の高いデータ配信を可能にします。たとえば、衛星リンクやその他のブロードキャストメディアを介して使用する場合、パケットの80％を送信中に失うレシーバーは、損失がないレシーバー（レシーバーフィードバックが必要ない）の5倍の時間で完全なデータを受信できます。
Superficially viewed, it may sound very attractive to use IP multicast with the LE PHB to build this type of opportunistic reliable distribution in IP networks, but it can only be usefully deployed with routers that do not experience forwarding/replication resource starvation when a large amount of packets (virtually) need to be replicated to links where the LE queue is full.
一見すると、LE PHBでIPマルチキャストを使用してIPネットワークでこのタイプの日和見的で信頼性の高い分散を構築することは非常に魅力的に聞こえるかもしれませんが、大量の転送/レプリケーションリソース不足が発生しないルーターでのみ有効に展開できます（実質的に）のパケットを、LEキューがいっぱいのリンクに複製する必要があります。
Thus, a packet replication mechanism for LE-marked packets should consider the situation at the respective output links: it is a waste of internal forwarding resources if a packet is replicated to output links that have no resources left for LE forwarding. In those cases, a packet would have been replicated just to be dropped immediately after finding a filled LE queue at the respective output port. Such behavior could be avoided -- for example, by using a conditional internal packet replication: a packet would then only be replicated in cases where the output link is not fully used. This conditional replication, however, is probably not widely implemented.
したがって、LEマーク付きパケットのパケットレプリケーションメカニズムでは、それぞれの出力リンクでの状況を考慮する必要があります。LE転送用のリソースが残っていない出力リンクにパケットが複製されると、内部転送リソースの無駄になります。これらの場合、それぞれの出力ポートでいっぱいになったLEキューを見つけた直後にドロップするために、パケットが複製されます。このような動作は回避できます。たとえば、条件付きの内部パケット複製を使用することで、出力リンクが完全に使用されない場合にのみパケットが複製されます。ただし、この条件付きレプリケーションはおそらく広く実装されていません。
While the resource contention problem caused by multicast packet replication is also true for other Diffserv PHBs, LE forwarding is special, because often it is assumed that LE packets only get forwarded in the case of available resources at the output ports. The previously mentioned redundancy data traffic could suitably use the varying available residual bandwidth being utilized by the LE PHB, but only if the specific requirements stated above for conditional replication in the internal implementation of the network devices are considered.
マルチキャストパケットレプリケーションによって発生するリソース競合の問題は他のDiffserv PHBにも当てはまりますが、LE転送は特別なものです。LEパケットは、出力ポートで使用可能なリソースがある場合にのみ転送されると想定されることが多いためです。前述の冗長データトラフィックは、LE PHBによって利用されているさまざまな利用可能な残りの帯域幅を適切に使用できますが、ネットワークデバイスの内部実装での条件付きレプリケーションについて上記の特定の要件が考慮される場合に限ります。
[RFC4594] recommended the use of CS1 as the codepoint in its Section 4.10, whereas CS1 was defined in [RFC2474] to have a higher precedence than CS0, i.e., the default PHB. Consequently, Diffserv domains implementing CS1 according to [RFC2474] will cause a priority inversion for LE packets that contradicts the original purpose of LE. Therefore, every occurrence of the CS1 DSCP is replaced by the LE DSCP.
[RFC4594]は、そのセクション4.10でコードポイントとしてCS1の使用を推奨しましたが、CS1は[RFC2474]でCS0より高い優先度、つまりデフォルトのPHBを持つように定義されました。その結果、[RFC2474]に従ってCS1を実装するDiffservドメインは、LEの本来の目的と矛盾するLEパケットの優先順位を反転させます。したがって、CS1 DSCPが出現するたびにLE DSCPに置き換えられます。
Changes:
変更：
o This update to RFC 4594 removes the following entry from its Figure 3:
o このRFC 4594の更新により、図3から次のエントリが削除されます。
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
and replaces it with the following entry:
それを次のエントリに置き換えます。
|---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
o This update to RFC 4594 extends the Notes text below Figure 3 that currently states "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000'." to state "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DSCP, '000000'. The prior recommendation to use the CS1 DSCP for Low-Priority Data has been replaced by the current recommendation to use the LE DSCP, '000001'."
o このRFC 4594の更新により、図3の下にある「図3の注：デフォルト転送（DF）とクラスセレクター0（CS0）は同等の動作を提供し、同じDSコードポイント '000000'を使用する」という注記テキストが拡張されます。 「図3の注：デフォルト転送（DF）とクラスセレクター0（CS0）は同等の動作を提供し、同じDSCP、「000000」を使用します。低優先度データにCS1 DSCPを使用するという以前の推奨事項は、 LE DSCP「000001」を使用するための現在の推奨事項。」
o This update to RFC 4594 removes the following entry from its Figure 4:
o このRFC 4594の更新により、図4から次のエントリが削除されます。
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
and replaces it with the following entry:
それを次のエントリに置き換えます。
|---------------+------+-------------------+----------+--------+----|
| Low-Priority | LE | Not applicable | RFC 8622 | Rate | Yes|
| Data | | | | | |
-------------------------------------------------------------------
o Section 2.3 of [RFC4594] specifies the following: "In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress." This document removes this recommendation, because by using the LE DSCP defined herein, such re-marking is not necessary. So, even if Low-Priority Data is unsupported (i.e., mapped to the default PHB), the LE DSCP should be kept across the domain as RECOMMENDED in Section 8. That removed text is replaced by the following: "In network segments that use IP Precedence marking, the Low-Priority Data service class receives the same Diffserv QoS as the Standard service class when the LE DSCP is used for Low-Priority Data traffic. This is acceptable behavior for the Low-Priority Data service class, although it is not the preferred behavior."
o [RFC4594]のセクション2.3は次のように規定しています。「IP precedenceマーキングを使用するネットワークセグメントでは、高スループットデータまたは低優先度データの2つのサービスクラスのうち1つのみをサポートできます。DSCP値を推奨しますサポートされていないサービスクラスの値は、入力時に000xx1に変更され、優先順位マーキングを使用するネットワークセグメントの出力時に元の値に戻されます。たとえば、低優先度データが標準サービスクラスにマップされている場合、000001 DSCPマーキング出力で標準のマークされたパケットと区別するために使用できます。」ここで定義されているLE DSCPを使用することにより、このような再マーキングが不要になるため、このドキュメントはこの推奨事項を削除します。そのため、低優先度データがサポートされていない（つまり、デフォルトのPHBにマップされている）場合でも、セクション8で推奨されているように、LE DSCPをドメイン全体で維持する必要があります。削除されたテキストは次のように置き換えられます。 IP優先順位マーキング、低優先度データサービスクラスは、LE DSCPが低優先度データトラフィックに使用される場合、標準サービスクラスと同じDiffserv QoSを受け取ります。これは、低優先度データサービスクラスの許容可能な動作です。推奨される動作ではありません。」
o This document removes the following line in Section 4.10 of RFC 4594: "The RECOMMENDED DSCP marking is CS1 (Class Selector 1)." and replaces it with the following text: "The RECOMMENDED DSCP marking is LE (Lower Effort), which replaces the prior recommendation for CS1 (Class Selector 1) marking."
o このドキュメントでは、RFC 4594のセクション4.10にある「推奨されるDSCPマーキングはCS1（クラスセレクター1）」という行を削除しています。これを次のテキストに置き換えます。「推奨されるDSCPマーキングはLE（低エフォート）であり、これはCS1（クラスセレクタ1）マーキングの以前の推奨事項を置き換えます。」
Section 4.2.10 of RFC 8325 [RFC8325] specifies that "[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." This is updated to "[RFC3662] recommends that Low-Priority Data be marked CS1 DSCP. [RFC4594], as updated by RFC 8622, recommends that Low-Priority Data be marked LE DSCP." This document removes the following paragraph in Section 4.2.10 of [RFC8325], because this document makes the anticipated change: "Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic."
RFC 8325 [RFC8325]のセクション4.2.10は、「[RFC3662]と[RFC4594]の両方で低優先度データにCS1 DSCPのマークを付けることを推奨している」と規定しています。これは「[RFC3662]は低優先度データにCS1 DSCPをマークすることを推奨しています。[RFC4594]はRFC 8622によって更新されたように、低優先度データにLE DSCPをマークすることを推奨しています。」このドキュメントは予想される変更を行うため、[RFC8325]のセクション4.2.10の次の段落を削除します。「注：[LE-PHB]はローエフォート（LE）PHBを定義しているため、このマーキングの推奨事項は将来変更される可能性があります。低優先度のデータトラフィックの場合、このトラフィックには追加のDSCPを推奨します。」
Section 4.2.10 of RFC 8325 [RFC8325] specifies that "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1", which is updated to "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1".
RFC 8325 [RFC8325]のセクション4.2.10は、「したがって、CS1 DSCPとマークされた低優先度データトラフィックをUP 1にマッピングすることをお勧めします」と明記しており、「したがって、低優先度データトラフィックをマッピングすることが推奨されています。 LE DSCPまたはレガシーCS1 DSCPでUP 1 "とマークされています。
This update to RFC 8325 replaces the following entry from its Figure 1:
RFC 8325に対するこの更新は、図1の次のエントリを置き換えます。
+---------------+------+----------+------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
with the following entries:
次のエントリで：
+---------------+------+----------+------------+--------------------+
| Low-Priority | LE | RFC 8622 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | |
+-------------------------------------------------------------------+
This document assigns the Differentiated Services Field Codepoint (DSCP) '000001' from the "Differentiated Services Field Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action) [RFC8126] to the LE PHB. This document uses a DSCP from Pool 3 in order to avoid problems for other PHB-marked flows, where they could become accidentally re-marked as LE PHB, e.g., due to partial DSCP bleaching. See [RFC8436] regarding reclassifying Pool 3 for Standards Action.
このドキュメントでは、Differentiated Services Field Codepoint（DSCP） '000001'を "Differentiated Services Field Codepoints（DSCP）"レジストリ（https://www.iana.org/assignments/dscp-registry/）（ "DSCPプール3コードポイント"、コードポイントスペースxxxx01、標準アクション）[RFC8126]をLE PHBに送信します。このドキュメントでは、プール3からのDSCPを使用して、他のPHBマークの付いたフローの問題を回避しています。標準アクションのプール3の再分類については、[RFC8436]を参照してください。
IANA has updated this registry as follows:
IANAはこのレジストリを次のように更新しました。
o Name: LE
o 名前：LE
o Value (Binary): 000001
o 値（バイナリ）：000001
o Value (Decimal): 1
o 値（10進数）：1
o Reference: RFC 8622
o リファレンス：RFC 8622
There are no specific security exposures for this PHB. Since it defines a new class that is of low forwarding priority, re-marking other traffic as LE traffic may lead to QoS degradation of such traffic. Thus, any attacker that is able to modify the DSCP of a packet to LE may carry out a downgrade attack. See the general security considerations in [RFC2474] and [RFC2475].
このPHBには、特定の機密漏れはありません。転送優先度の低い新しいクラスを定義しているため、他のトラフィックをLEトラフィックとして再マーキングすると、そのようなトラフィックのQoSが低下する可能性があります。したがって、LEへのパケットのDSCPを変更できる攻撃者は、ダウングレード攻撃を実行する可能性があります。 [RFC2474]および[RFC2475]の一般的なセキュリティの考慮事項を参照してください。
With respect to privacy, an attacker could use the information from the DSCP to infer that the transferred (probably even encrypted) content is considered of low priority or low urgency by a user if the DSCP was set per the user's request. On the one hand, this disclosed information is useful only if correlation with metadata (such as the user's IP address) and/or other flows reveal a user's identity. On the other hand, it might help an observer (e.g., a state-level actor) who is interested in learning about the user's behavior from observed traffic: LE-marked background traffic (such as software downloads, operating system updates, or telemetry data) may be less interesting for surveillance than general web traffic. Therefore, the LE marking may help the observer to focus on potentially more interesting traffic (however, the user may exploit this particular assumption and deliberately hide interesting traffic in the LE aggregate). Apart from such considerations, the impact of disclosed information by the LE DSCP is likely negligible in most cases, given the numerous traffic analysis possibilities and general privacy threats (e.g., see [RFC6973]).
プライバシーに関して、攻撃者はDSCPからの情報を使用して、ユーザーの要求に従ってDSCPが設定されている場合、転送された（おそらく暗号化された）コンテンツでもユーザーによる優先度または緊急度が低いと見なす可能性があります。一方で、この開示された情報は、メタデータ（ユーザーのIPアドレスなど）や他のフローとの相関関係がユーザーのIDを明らかにした場合にのみ役立ちます。一方で、観察されたトラフィックからユーザーの行動について学習することに関心のある観察者（たとえば、州レベルの俳優）を支援する可能性があります：LEマーク付きのバックグラウンドトラフィック（ソフトウェアのダウンロード、オペレーティングシステムの更新、テレメトリデータなど） ）は、一般的なWebトラフィックよりも監視にとって面白くないかもしれません。したがって、LEマーキングは、オブザーバーが潜在的により興味深いトラフィックに焦点を合わせるのに役立つ場合があります（ただし、ユーザーはこの特定の仮定を利用して、LE集約で意図的に興味深いトラフィックを非表示にすることができます）。このような考慮事項とは別に、多くのトラフィック分析の可能性と一般的なプライバシーの脅威を考えると、LE DSCPによって開示された情報の影響はほとんどの場合無視できます（たとえば、[RFC6973]を参照）。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<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>.
[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>。
[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>。
[Carlberg-LBE-2001] Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than best effort: a design and implementation", ACM SIGCOMM Computer Communication Review, Volume 31 Issue 2 supplement, DOI 10.1145/844193.844208, April 2001, <https://dl.acm.org/citation.cfm?doid=844193.844208>.
[Carlberg-LBE-2001] Carlberg、K.、Gevros、P。、およびJ. Crowcroft、「ベストエフォートよりも低い：設計と実装」、ACM SIGCOMM Computer Communication Review、Volume 31 Issue 2補足、DOI 10.1145 / 844193.844208 、2001年4月、<https://dl.acm.org/citation.cfm?doid=844193.844208>。
[Chown-LBE-2003] Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, N., and S. Venaas, "Less than Best Effort: Application Scenarios and Experimental Results", Proceedings of the Second International Workshop on Quality of Service in Multiservice IP Networks (QoS-IP 2003), Lecture Notes in Computer Science, vol 2601, Springer, Berlin, Heidelberg, Pages 131-144, DOI 10.1007/3-540-36480-3_10, February 2003, <https://link.springer.com/chapter/ 10.1007%2F3-540-36480-3_10>.
[Chown-LBE-2003] Chown、T.、Ferrari、T.、Leinen、S.、Sabatino、R.、Simar、N。、およびS. Venaas、「Less than Best Effort：Application Scenarios and Experimental Results」、マルチサービスIPネットワークでのサービス品質に関する第2回国際ワークショップ（QoS-IP 2003）、コンピュータサイエンスの講義ノート、vol 2601、シュプリンガー、ベルリン、ハイデルベルク、ページ131-144、DOI 10.1007 / 3-540-36480- 3_10、2003年2月、<https://link.springer.com/chapter/ 10.1007％2F3-540-36480-3_10>。
[Diffserv-LBE-PHB] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", Work in Progress, draft-bless-diffserv-lbe-phb-00, September 1999.
[Diffserv-LBE-PHB] Bless、R。およびK. Wehrle、「ベストエフォート未満のホップごとの動作」、進行中の作業、draft-bless-diffserv-lbe-phb-00、1999年9月。
[IETF99-Secchi] Secchi, R., Venne, A., and A. Custura, "Measurements concerning the DSCP for a LE PHB", Presentation held at the 99th IETF Meeting, TSVWG, Prague, July 2017, <https://datatracker.ietf.org/meeting/99/materials/ slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00>.
[IETF99-Secchi] Secchi、R.、Venne、A。、およびA. Custura、「LE PHBのDSCPに関する測定値」、第99回IETFミーティングで開催されたプレゼンテーション、TSVWG、プラハ、2017年7月、<https：/ /datatracker.ietf.org/meeting/99/materials/ slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, DOI 10.17487/RFC3439, December 2002, <https://www.rfc-editor.org/info/rfc3439>.
[RFC3439] Bush、R。およびD. Meyer、「Some Internet Architectural Guidelines and Philosophy」、RFC 3439、DOI 10.17487 / RFC3439、2002年12月、<https://www.rfc-editor.org/info/rfc3439>。
[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>.
[RFC3662] Bless、R.、Nichols、K。、およびK. Wehrle、「Differentiated Servicesのドメインごとの動作（PDB）の削減」、RFC 3662、DOI 10.17487 / RFC3662、2003年12月、<https：// www.rfc-editor.org/info/rfc3662>。
[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, April 2004, <https://www.rfc-editor.org/info/rfc3754>.
[RFC3754] Bless、R。およびK. Wehrle、「差別化サービス（DS）ネットワークにおけるIPマルチキャスト」、RFC 3754、DOI 10.17487 / RFC3754、2004年4月、<https://www.rfc-editor.org/info/ rfc3754>。
[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>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https://www.rfc-editor.org / info / rfc4594>。
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007, <https://www.rfc-editor.org/info/rfc5053>.
[RFC5053] Luby、M.、Shokrollahi、A.、Watson、M。、およびT. Stockhammer、「Raptor Forward Error Correction Scheme for Object Delivery」、RFC 5053、DOI 10.17487 / RFC5053、2007年10月、<https：// www.rfc-editor.org/info/rfc5053>。
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011, <https://www.rfc-editor.org/info/rfc6297>.
[RFC6297] Welzl、M。、およびD. Ros、「調査、ベストエフォート未満のトランスポートプロトコル」、RFC 6297、DOI 10.17487 / RFC6297、2011年6月、<https://www.rfc-editor.org / info / rfc6297>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<https：// www.rfc-editor.org/info/rfc6817>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] Fairhurst、G。、およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https://www.rfc-editor.org/info / rfc8087>。
[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>.
[RFC8100]ガイブ、R。、エド。 D. Black、「Diffserv-Interconnection Classes and Practice」、RFC 8100、DOI 10.17487 / RFC8100、2017年3月、<https://www.rfc-editor.org/info/rfc8100>。
[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>。
[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>.
[RFC8325] Szigeti、T.、Henry、J.、およびF. Baker、「Mapping Diffserv to IEEE 802.11」、RFC 8325、DOI 10.17487 / RFC8325、2018年2月、<https://www.rfc-editor.org/ info / rfc8325>。
[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>.
[RFC8436] Fairhurst、G。、「Differentiated Services Field Codepoints（DSCP）Registryのプール3値のIANA登録手順の更新」、RFC 8436、DOI 10.17487 / RFC8436、2018年8月、<https：//www.rfc- editor.org/info/rfc8436>。
A first draft version of this PHB was suggested by Roland Bless and Klaus Wehrle in September 1999 [Diffserv-LBE-PHB], named "A Lower Than Best-Effort Per-Hop Behavior". After some discussion in the Diffserv Working Group, Brian Carpenter and Kathie Nichols proposed a "bulk handling" per-domain behavior and believed a PHB was not necessary. Eventually, "Lower Effort" was specified as per-domain behavior and finally became [RFC3662]. More detailed information about its history can be found in Section 10 of [RFC3662].
このPHBの最初のドラフトバージョンは、1999年9月にRoland BlessとKlaus Wehrleによって提案されました[Diffserv-LBE-PHB]。 Diffservワーキンググループでの議論の後、Brian CarpenterとKathie Nicholsはドメインごとの「一括処理」動作を提案し、PHBは必要ないと考えました。結局、「Lower Effort」はドメインごとの振る舞いとして指定され、ついに[RFC3662]になりました。その履歴の詳細については、[RFC3662]のセクション10をご覧ください。
There are several other names in use for this type of PHB or associated service classes. Well known is the QBone Scavenger Service (QBSS) that was proposed in March 2001 within the Internet2 QoS Working Group. Alternative names are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003].
このタイプのPHBまたは関連するサービスクラスには、他にもいくつかの名前が使用されています。 2001年3月にInternet2 QoSワーキンググループ内で提案されたQBone Scavenger Service（QBSS）はよく知られています。代替名は「ベストエフォートより低い」[Carlberg-LBE-2001]または「ベストエフォートより低い」[Chown-LBE-2003]です。
Acknowledgments
謝辞
Since text is partially borrowed from earlier Internet-Drafts and RFCs, the coauthors of previous specifications are acknowledged here: Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure, Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and Kyle Rose provided helpful comments and (partially also text) suggestions.
テキストは部分的に以前のインターネットドラフトとRFCから借用されているため、以前の仕様の共著者はここで認められています：Kathie NicholsとKlaus Wehrle。 David Black、Olivier Bonaventure、Spencer Dawkins、Toerless Eckert、Gorry Fairhurst、Ruediger Geib、Kyle Roseは、役立つコメントと（一部はテキストも）提案を提供しました。
Author's Address
著者のアドレス
Roland Bless Karlsruhe Institute of Technology (KIT) Institute of Telematics (TM) Kaiserstr. 12 Karlsruhe 76131 Germany
Roland Bless Karlsruhe Institute of Technology（KIT）Institute of Telematics（TM）Kaiserstr。 12カールスルーエ76131ドイツ
Phone: +49 721 608 46413
Email: roland.bless@kit.edu