Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 9599 Independent
BCP: 89 J. Kaippallimalil
Updates: 3819 Futurewei
Category: Best Current Practice August 2024
ISSN: 2070-1721
The purpose of this document is to guide the design of congestion notification in any lower-layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower-layer protocols into IP. Then, the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Specifications that follow these guidelines, whether produced by the IETF or other standards bodies, should assure interworking among IP-layer and lower-layer congestion notification mechanisms. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about Explicit Congestion Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference to this document.
このドキュメントの目的は、IPをカプセル化する下層またはトンネリングプロトコルの輻輳通知の設計を導くことです。目的は、低層プロトコルからIPに一貫して伝播する明示的なうっ血信号です。次に、IPインターネットワークレイヤーは、輸送層（L4）までの非IPに認識されていない混雑ノードから輻輳通知を伝達するための移植性レイヤーとして機能します。これらのガイドラインに従う仕様は、IETFまたはその他の標準団体によって生成されるかどうかにかかわらず、IP層と低層の輻輳通知メカニズム間のインターワーキングを保証する必要があります。このドキュメントはBCP 89に含まれており、RFC 3819のセクション13の明示的な混雑通知（ECN）に関するサブネットワークデザイナーへのアドバイスの単一の段落を、このドキュメントへの参照に置き換えます。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、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/rfc9599.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9599で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
1.1. Update to RFC 3819
1.2. Scope
2. Terminology
3. Modes of Operation
3.1. Feed-Forward-and-Up Mode
3.2. Feed-Up-and-Forward Mode
3.3. Feed-Backward Mode
3.4. Null Mode
4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification
4.1. IP-in-IP Tunnels with Shim Headers
4.2. Wire Protocol Design: Indication of ECN Support
4.3. Encapsulation Guidelines
4.4. Decapsulation Guidelines
4.5. Sequences of Similar Tunnels or Subnets
4.6. Reframing and Congestion Markings
5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification
6. Feed-Backward Mode: Guidelines for Adding Congestion
Notification
7. IANA Considerations
8. Security Considerations
9. Conclusions
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
In certain networks, it might be possible for traffic to congest non-IP-aware nodes. In such networks, the benefits of Explicit Congestion Notification (ECN) described in [RFC8087] and summarized below can only be fully realized if support for congestion notification is added to the relevant subnetwork technology, as well as to IP. When a lower-layer buffer implicitly notifies congestion by dropping a packet, it obviously does not just drop at that layer; the packet disappears from all layers. In contrast, when active queue management (AQM) at a lower layer buffer explicitly notifies congestion by marking a frame header, the marking needs to be explicitly propagated up the layers. The same is true if AQM marks the outer header of a packet that encapsulates inner tunnelled headers. Forwarding ECN is not as straightforward as other headers because it has to be assumed ECN may be only partially deployed. If a lower-layer header that contains congestion indications is stripped off by a subnet egress that is not ECN-aware, or if the ultimate receiver or sender is not ECN-aware, congestion needs to be indicated by dropping the packet, not marking it.
特定のネットワークでは、トラフィックが非IP認識ノードを混雑させる可能性があります。このようなネットワークでは、[RFC8087]に記載され、以下に要約されている明示的なうっ血通知（ECN）の利点は、輻輳通知のサポートが関連するサブネットワークテクノロジーとIPに追加された場合にのみ完全に実現できます。低層バッファーがパケットを落とすことで鬱血を暗黙的に通知する場合、明らかにその層に落とすだけではありません。パケットはすべてのレイヤーから消えます。対照的に、下層バッファーでアクティブキュー管理（AQM）がフレームヘッダーをマークすることにより輻輳を明示的に通知する場合、マーキングをレイヤーに明示的に伝播する必要があります。AQMが内側のトンネルヘッダーをカプセル化するパケットの外側ヘッダーをマークする場合も同じことが言えます。ECNは、ECNが部分的に展開されていると想定する必要があるため、ECNを他のヘッダーほど単純ではありません。うっ血指示を含む低層ヘッダーがECNに認識されていないサブネットの出口によって剥奪される場合、または究極のレシーバーまたは送信者がECNに触れていない場合、渋滞をパケットをドロップすることで示す必要があります。。
The purpose of this document is to guide the addition of congestion notification to any subnet technology or tunnelling protocol so that lower-layer AQM algorithms can signal congestion explicitly and that signal will propagate consistently into encapsulated (higher-layer) headers. Otherwise, the signals will not reach their ultimate destination.
このドキュメントの目的は、下層層AQMアルゴリズムが輻輳を明示的に信号することができ、その信号がカプセル化された（より高い層）ヘッダーに一貫して伝播するように、サブネットテクノロジーまたはトンネリングプロトコルへの混雑通知の追加をガイドすることです。それ以外の場合、信号は究極の目的地に到達しません。
ECN is defined in the IP header (IPv4 and IPv6) [RFC3168] to allow a resource to notify the onset of queue buildup without having to drop packets by explicitly marking a proportion of packets with the congestion experienced (CE) codepoint.
ECNは、IPヘッダー（IPv4およびIPv6）[RFC3168]で定義されており、リソースがパケットの割合を明示的にマークすることでパケットをドロップせずにキュービルドアップの開始を通知できるようにします。
Given a suitable marking scheme, ECN removes nearly all congestion loss and it cuts delays for two main reasons:
適切なマーキングスキームを考えると、ECNはほぼすべての混雑損失を削除し、2つの主な理由で遅延を削減します。
* It avoids the delay when recovering from congestion losses, which particularly benefits small flows or real-time flows, making their delivery time predictably short [RFC2884].
* 混雑損失から回復する際の遅延を回避します。これは、特に小さな流れやリアルタイムのフローに利益をもたらし、配送時間を予測可能に短くします[RFC2884]。
* As ECN is used more widely by end systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). This is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal and not an impairment, so there is no harm triggering it earlier.
* ECNはエンドシステムによってより広く使用されているため、混雑（バッファーブロートの原因）の通知を開始する前に、バッファーにある程度の遅延を構成する必要性を徐々に削除します。これは、ドロップがタイムリーな信号を送信することと障害を回避しようとすることとのトレードオフを伴うため、ECNは単に障害ではなく信号であるため、以前にそれを引き起こす害はありません。
Some lower-layer technologies (e.g., MPLS, Ethernet) are used to form subnetworks with IP-aware nodes only at the edges. These networks are often sized so that it is rare for interior queues to overflow. However, until recently, this was more due to the inability of TCP to saturate the links. For many years, fixes such as window scaling [RFC7323] proved hard to deploy and the Reno variant of TCP remained in widespread use despite its inability to scale to high flow rates. However, now that modern operating systems are finally capable of saturating interior links, even the buffers of well-provisioned interior switches will need to signal episodes of queuing.
いくつかの低層技術（MPLS、イーサネットなど）を使用して、エッジでのみIP認識ノードを持つサブネットワークを形成します。これらのネットワークは多くの場合サイズがあるため、インテリアキューがオーバーフローすることはまれです。ただし、最近まで、これはTCPがリンクを飽和させることができないためでした。長年にわたり、ウィンドウスケーリング[RFC7323]などの修正は展開が困難であることが判明し、TCPのRENOバリアントは、高流量に拡張できないにもかかわらず広範囲に使用されていました。ただし、最新のオペレーティングシステムが最終的にインテリアリンクを飽和させることができるようになったため、十分に進化したインテリアスイッチのバッファーでさえ、キューイングのエピソードを通知する必要があります。
Propagation of ECN is defined for MPLS [RFC5129] and TRILL [RFC7780] [RFC9600], but it has yet to be defined for a number of other subnetwork technologies.
ECNの伝播は、MPLS [RFC5129]およびTrill [RFC7780] [RFC9600]で定義されていますが、他の多くのサブネットワーク技術ではまだ定義されていません。
Similarly, ECN propagation is yet to be defined for many tunnelling protocols. [RFC6040] defines how ECN should be propagated for IP-in-IPv4 [RFC2003], IP-in-IPv6 [RFC2473], and IPsec [RFC4301] tunnels, but there are numerous other tunnelling protocols with a shim and/or a Layer 2 (L2) header between two IP headers (IPv4 or IPv6). Some address ECN propagation between the IP headers, but many do not. This document gives guidance on how to address ECN propagation for future tunnelling protocols, and a companion Standards Track specification [RFC9601] updates existing tunnelling protocols with a shim between IP headers that are under IETF change control and still widely used.
同様に、ECN伝播は、多くのトンネルプロトコルに対してまだ定義されていません。[RFC6040]は、IP-in-IPV4 [RFC2003]、IP-in-IPV6 [RFC2473]、およびIPSEC [RFC4301]トンネルにECNを伝播する方法を定義しますが、シムおよびまたは層の層を備えた他のトンネリングプロトコルが多数あります。2（L2）2つのIPヘッダー（IPv4またはIPv6）の間のヘッダー。IPヘッダー間のECN伝播に対処するものもありますが、多くはそうではありません。このドキュメントは、将来のトンネルプロトコルのECN伝播に対処する方法に関するガイダンスと、コンパニオン標準トラック仕様[RFC9601]を、IETF変更制御下でまだ広く使用されているIPヘッダー間のシムで既存のトンネリングプロトコルを更新します。
Incremental deployment is the most delicate aspect when adding support for ECN. The original ECN protocol in IP [RFC3168] was carefully designed so that a congested buffer would not mark a packet (rather than drop it) unless both source and destination hosts were ECN-capable. Otherwise, its congestion markings would never be detected and congestion would just build up further. However, to support congestion marking below the IP layer or within tunnels, it is not sufficient to only check that the two layer 4 transport endpoints support ECN; correct operation also depends on the decapsulator at each subnet or tunnel egress faithfully propagating congestion notification to the higher layer. Otherwise, a legacy decapsulator might silently fail to propagate any congestion signals from the outer header to the forwarded header. Then, the lost signals would never be detected and congestion would build up further. The guidelines given later require protocol designers to carefully consider incremental deployment and suggest various safe approaches for different circumstances.
ECNのサポートを追加する際に、増分展開は最も繊細な側面です。IP [RFC3168]の元のECNプロトコルは、浸漬されたバッファーがeCN対応と宛先ホストの両方が存在しない限り、パケットを（ドロップするのではなく）マークしないように慎重に設計されました。そうしないと、その混雑マーキングは決して検出されず、混雑はさらに蓄積されます。ただし、IPレイヤーの下またはトンネル内の輻輳マーキングをサポートするには、2つのレイヤー4輸送エンドポイントがECNをサポートしていることのみを確認するだけでは不十分です。正しい操作は、各サブネットまたはトンネルの出口での脱カプセレーターにも依存します。それ以外の場合、レガシーの脱カプセレーターは、外側のヘッダーから転送ヘッダーへの混雑信号を静かに伝播できない場合があります。その後、失われた信号は検出されず、混雑はさらに蓄積されます。後で与えられたガイドラインでは、プロトコル設計者が増分展開を慎重に検討し、さまざまな状況でさまざまな安全なアプローチを提案する必要があります。
Of course, the IETF does not have standards authority over every link-layer protocol; thus, this document gives guidelines for designing propagation of congestion notification across the interface between IP and protocols that may encapsulate IP (i.e., that can be layered beneath IP). Each lower-layer technology will exhibit different issues and compromises, so the IETF or the relevant standards body must be free to define the specifics of each lower-layer congestion notification scheme. Nonetheless, if the guidelines are followed, congestion notification should interwork between different technologies using IP in its role as a 'portability layer'.
もちろん、IETFには、すべてのリンク層プロトコルに対する標準権限がありません。したがって、このドキュメントは、IPとプロトコルの間のインターフェース全体に渋滞通知の伝播を設計するためのガイドラインを提供します（つまり、IPの下に階層化できる）。各低層技術はさまざまな問題と妥協を示すため、IETFまたは関連する標準団体は、各低層渋滞通知スキームの詳細を自由に定義する必要があります。それにもかかわらず、ガイドラインに従っている場合、混雑通知は、「移植性レイヤー」としての役割でIPを使用して、異なるテクノロジー間でインターワークする必要があります。
Therefore, the capitalized terms 'SHOULD' or 'SHOULD NOT' are often used in preference to 'MUST' or 'MUST NOT' because it is difficult to know the compromises that will be necessary in each protocol design. If a particular protocol design chooses not to follow a 'SHOULD' or 'SHOULD NOT' given in the advice below, it MUST include a sound justification.
したがって、大文字の項は、各プロトコル設計で必要な妥協を知ることが困難であるため、「必要」または「必須」または「そうでない」よりも多くの場合使用されます。特定のプロトコルの設計が、以下のアドバイスに与えられた「すべき」または「すべきでない」に従わないことを選択した場合、健全な正当化を含める必要があります。
It has not been possible to give common guidelines for all lower-layer technologies because they do not all fit a common pattern. Instead, they have been divided into a few distinct modes of operation: feed-forward-and-up, feed-up-and-forward, feed-backward, and null mode. These modes are described in Section 3, and separate guidelines are given for each mode in subsequent sections.
すべての低層技術に共通のガイドラインを提供することはできませんでした。なぜなら、それらはすべて共通のパターンに適合していないからです。代わりに、それらは、フィードフォワードアンドアップ、フィードアップアンドフォワード、フィードバックワード、ヌルモードのいくつかの異なる操作モードに分割されています。これらのモードはセクション3で説明されており、後続のセクションで各モードについて個別のガイドラインを示します。
This document updates the brief advice to subnetwork designers about ECN in Section 13 of [RFC3819] by adding this document (RFC 9599) as an informative reference and replacing the last two paragraphs with the following sentence:
このドキュメントは、このドキュメント（RFC 9599）を有益な参照として追加し、最後の2つの段落を次の文で置き換えることにより、[RFC3819]のセクション13のECNに関するサブネットワーク設計者への簡単なアドバイスを更新します。
By following the guidelines in [RFC9599], subnetwork designers can enable a layer-2 protocol to participate in congestion control without dropping packets via propagation of Explicit Congestion Notification (ECN) [RFC3168] to receivers.
[RFC9599]のガイドラインに従うことにより、サブネットワーク設計者は、レイヤー2プロトコルが、明示的なうっ血通知（ECN）[RFC3168]の伝播を介して受信機へのパケットをドロップすることなく、混雑制御に参加できるようにすることができます。
This document only concerns wire protocol processing of explicit notification of congestion. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response because algorithm issues should be independent of the layer that the algorithm operates in.
このドキュメントは、混雑の明示的な通知のワイヤープロトコル処理のみに関係しています。アルゴリズムの問題は、アルゴリズムが動作するレイヤーとは無関係でなければならないため、輻輳マーキングまたは輻輳応答のアルゴリズムに関する変更や推奨は行われません。
The default ECN semantics are described in [RFC3168] and updated by [RFC8311]. Also, the guidelines for AQM designers [RFC7567] clarify the semantics of both drop and ECN signals from AQM algorithms. [RFC4774] is the appropriate best current practice specification of how algorithms with alternative semantics for the ECN field can be partitioned from Internet traffic that uses the default ECN semantics. There are two main examples for how alternative ECN semantics have been defined in practice:
デフォルトのECNセマンティクスは[RFC3168]で説明され、[RFC8311]によって更新されます。また、AQMデザイナーのガイドライン[RFC7567]は、AQMアルゴリズムからのドロップシグナルとECNシグナルの両方のセマンティクスを明確にします。[RFC4774]は、ECNフィールドの代替セマンティクスを使用したアルゴリズムを、デフォルトのECNセマンティクスを使用するインターネットトラフィックから分割する方法の適切な最良の実践仕様です。代替ECNセマンティクスが実際にどのように定義されているかについての2つの主要な例があります。
* [RFC4774] suggests using the ECN field in combination with a Diffserv codepoint, such as in Pre-Congestion Notification (PCN) [RFC6660], Voice over 3G [UTRAN], or Voice over LTE (VoLTE) [LTE-RA].
* [RFC4774]は、Pre-Congestion通知（PCN）[RFC6660]、Voice over 3G [utran]、またはLoice over LTE（volte）[LTE-RA]など、diffserv CodePointと組み合わせてECNフィールドを使用することをお勧めします。
* [RFC8311] suggests using the ECT(1) codepoint of the ECN field to indicate alternative semantics, such as for the experimental Low Latency, Low Loss, and Scalable throughput (L4S) service [RFC9331].
* [RFC8311]は、ECNフィールドのECT（1）コードポイントを使用して、実験的な低レイテンシ、低損失、スケーラブルスループット（L4S）サービスなどの代替セマンティクスを示すことをお勧めします[RFC9331]。
The aim is that the default rules for encapsulating and decapsulating the ECN field are sufficiently generic that tunnels and subnets will encapsulate and decapsulate packets without regard to how algorithms elsewhere are setting or interpreting the semantics of the ECN field. [RFC6040] updates [RFC4774] to allow alternative encapsulation and decapsulation behaviours to be defined for alternative ECN semantics. However, it reinforces the same point -- it is far preferable to try to fit within the common ECN encapsulation and decapsulation behaviours because expecting all lower-layer technologies and tunnels to be updated is likely to be completely impractical.
目的は、ECNフィールドをカプセル化および脱カプセル化するためのデフォルトのルールは、トンネルとサブネットがECNフィールドのセマンティクスをどのように設定または解釈しているかに関係なく、トンネルとサブネットがパケットをカプセル化および脱カプセル化することです。[RFC6040]は[RFC4774]を更新して、代替ECNセマンティクスに対して代替のカプセル化と脱カプセル化行動を定義できるようにします。ただし、同じ点を強化します。すべての低層技術とトンネルが更新されることを期待することは完全に非実用的である可能性が高いため、一般的なECNカプセル化と脱カプセル化行動に適合しようとすることをはるかに好みます。
Alternative semantics for the ECN field can be defined to depend on the traffic class indicated by the Differentiated Services Code Point (DSCP). Therefore, correct propagation of congestion signals could depend on correct propagation of the DSCP between the layers and along the path. For instance, if the meaning of the ECN field depends on the DSCP (as in PCN or VoLTE) and the outer DSCP is stripped on descapsulation, as in the pipe model of [RFC2983], the special semantics of the ECN field would be lost. Similarly, if the DSCP is changed at the boundary between Diffserv domains, the special ECN semantics would also be lost. This is an important implication of the localized scope of most Diffserv arrangements. In this document, correct propagation of traffic class information is assumed while the meaning of 'correct' and how it is achieved is covered elsewhere (e.g., [RFC2983]) and is outside the scope of this document.
ECNフィールドの代替セマンティクスは、差別化されたサービスコードポイント（DSCP）で示されるトラフィッククラスに依存するように定義できます。したがって、輻輳信号の正しい伝播は、レイヤー間とパスに沿ったDSCPの正しい伝播に依存する可能性があります。たとえば、ECNフィールドの意味がDSCP（PCNまたはVOLTEのように）に依存し、[RFC2983]のパイプモデルのように外部DSCPが脱吸虫に剥がされた場合、ECNフィールドの特別な意味論は失われます。同様に、DSCPがDiffservドメイン間の境界で変更された場合、特別なECNセマンティクスも失われます。これは、ほとんどのDiffServ配置のローカライズされた範囲の重要な意味です。このドキュメントでは、「正しい」という意味とその達成方法が他の場所でカバーされている間（[RFC2983]など）、トラフィッククラス情報の正しい伝播が想定され、このドキュメントの範囲外です。
The guidelines in this document do ensure that common encapsulation and decapsulation rules are sufficiently generic to cover cases where ECT(1) is used instead of ECT(0) to identify alternative ECN semantics (as in L4S [RFC9331]) and where ECN-marking algorithms use ECT(1) to encode three severity levels into the ECN field (e.g., PCN [RFC6660]) rather than the default of two. All these different semantics for the ECN field work because it has been possible to define common default decapsulation rules that allow for all cases [RFC6040].
このドキュメントのガイドラインは、一般的なカプセル化と脱カプセル化ルールが、ECT（0）の代わりにECT（1）を使用して代替ECNセマンティクス（L4S [RFC9331]のように）を特定し、ECNマーキングをするケース（1）をカバーするのに十分な一般的なものであることを保証します。アルゴリズムはECT（1）を使用して、2つのデフォルトではなく、3つの重大度レベルをECNフィールド（例：PCN [RFC6660]）にエンコードします。ECNフィールドのこれらの異なるセマンティクスはすべて、すべてのケースを可能にする一般的なデフォルトの脱カプセル化ルールを定義することが可能であるためです[RFC6040]。
Note that the guidelines in this document do not necessarily require the subnet wire protocol to be changed to add support for congestion notification. For instance, the feed-up-and-forward mode (Section 3.2) and the null mode (Section 3.4) do not. Another way to add congestion notification without consuming header space in the subnet protocol might be to use a parallel control plane protocol.
このドキュメントのガイドラインでは、渋滞通知のサポートを追加するためにサブネットワイヤプロトコルを変更する必要はないことに注意してください。たとえば、フィードアップアンドフォワードモード（セクション3.2）とヌルモード（セクション3.4）はそうではありません。サブネットプロトコルでヘッダースペースを消費せずに混雑通知を追加する別の方法は、並列制御プレーンプロトコルを使用することです。
This document focuses on the congestion notification interface between IP and lower-layer or tunnel protocols that can encapsulate IP, where the term 'IP' includes IPv4 or IPv6, unicast, multicast, or anycast. However, it is likely that the guidelines will also be useful when a lower-layer protocol or tunnel encapsulates itself, e.g., Ethernet Media Access Control (MAC) in MAC ([IEEE802.1Q]; previously 802.1ah), or when it encapsulates other protocols. In the feed-backward mode, propagation of congestion signals for multicast and anycast packets is out of scope (because the complexity would make it unlikely to be attempted).
このドキュメントでは、IPとIP」という用語にはIPv4またはIPv6、Unicast、Multicast、またはAnycastが含まれる場合、IPと低層またはトンネルプロトコル間の輻輳通知インターフェイスに焦点を当てています。ただし、下層のプロトコルまたはトンネルがそれ自体をカプセル化する場合、マックのイーサネットメディアアクセス制御（MAC）、[IEEE802.1Q];以前は802.1AH）、またはカプセル化する場合にも、ガイドラインが役立つ可能性があります。その他のプロトコル。フィードバックワードモードでは、マルチキャストパケットとAnycastパケットの輻輳信号の伝播は範囲外になります（複雑さにより試みられる可能性は低いため）。
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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Further terminology used within this document:
このドキュメント内で使用されるさらなる用語：
Protocol data unit (PDU):
プロトコルデータユニット（PDU）：
Information that is delivered as a unit among peer entities of a layered network consisting of protocol control information (typically a header) and possibly user data (payload) of that layer. The scope of this document includes Layer 2 and Layer 3 networks, where the PDU is respectively termed a frame or a packet (or a cell in ATM). PDU is a general term for any of these. This definition also includes a payload with a shim header lying somewhere between layer 2 and 3.
そのレイヤーのプロトコル制御情報（通常はヘッダー）と場合によってはユーザーデータ（ペイロード）で構成される層状ネットワークのピアエンティティ間のユニットとして提供される情報。このドキュメントの範囲には、レイヤー2とレイヤー3ネットワークが含まれます。ここでは、PDUはそれぞれフレームまたはパケット（またはATMのセル）と呼ばれます。PDUは、これらのいずれかの一般的な用語です。この定義には、レイヤー2と3の間にあるシムヘッダーがあるペイロードも含まれています。
Transport:
輸送：
The end-to-end transmission control function, conventionally considered at layer 4 in the OSI reference model. Given the audience for this document will often use the word transport to mean low-level bit carriage, the term will be qualified whenever it is used, e.g., 'L4 transport'.
OSI参照モデルのレイヤー4で従来考慮されているエンドツーエンドの伝送制御関数。このドキュメントの視聴者は、しばしば単語トランスポートを使用して低レベルのビットキャリッジを平均することを考えると、「L4 Transport」などの用語はいつでも資格があります。
Encapsulator:
カプセレータ：
The link or tunnel endpoint function that adds an outer header to a PDU (also termed the 'link ingress', the 'subnet ingress', the 'ingress tunnel endpoint', or just the 'ingress' where the context is clear).
外側のヘッダーをPDUに追加するリンクまたはトンネルのエンドポイント関数（「リンクイングレス」、「サブネットイングレス」、「イングレストンネルエンドポイント」、またはコンテキストがクリアされている「侵入」だけです）。
Decapsulator:
脱カプセレータ：
The link or tunnel endpoint function that removes an outer header from a PDU (also termed the 'link egress', the 'subnet egress', the 'egress tunnel endpoint', or just the 'egress' where the context is clear).
PDUから外側のヘッダーを削除するリンクまたはトンネルエンドポイント関数（「リンク出口」、「サブネット出口」、「出口トンネルエンドポイント」、またはコンテキストが明確な「出口」だけと呼ばれます）。
Incoming header:
着信ヘッダー：
The header of an arriving PDU before encapsulation.
カプセル化前の到着PDUのヘッダー。
Outer header:
外側のヘッダー：
The header added to encapsulate a PDU.
ヘッダーがPDUをカプセル化するために追加されました。
Inner header:
内側のヘッダー：
The header encapsulated by the outer header.
外側のヘッダーによってカプセル化されたヘッダー。
Outgoing header:
発信ヘッダー：
The header forwarded by the decapsulator.
ヘッダーは脱カプセレータによって転送されます。
CE:
CE:
Congestion Experienced [RFC3168]
混雑を経験した[RFC3168]
ECT:
ECT:
ECN-Capable (L4) Transport [RFC3168]
ECN対応（L4）輸送[RFC3168]
Not-ECT:
not-ect：
Not ECN-Capable (L4) Transport [RFC3168]
ECN対応ではない（L4）輸送[RFC3168]
Load Regulator:
ロードレギュレーター：
For each flow of PDUs, the transport function that is capable of controlling the data rate. Typically located at the data source, but in-path nodes can regulate load in some congestion control arrangements (e.g., admission control, policing nodes, or transport circuit-breakers [RFC8084]). Note that "a function capable of controlling the load" deliberately includes a transport that does not actually control the load responsively, but ideally it ought to (e.g., a sending application without congestion control that uses UDP).
PDUの各フローについて、データレートを制御できる輸送機能。通常、データソースに配置されていますが、パス内のノードは、いくつかの輻輳制御の配置で負荷を調節できます（たとえば、入場制御、ポリシングノード、または輸送回路破壊者[RFC8084]）。「負荷を制御できる関数」には、実際に荷重を応答的に制御しないトランスポートを意図的に含むが、理想的には（たとえば、UDPを使用する輻輳制御のない送信アプリケーション）。
ECN-PDU:
ECN-PDU：
A PDU at the IP layer or below with a capacity to signal congestion that is part of a congestion control feedback loop within which all the nodes necessary to propagate the signal back to the Load Regulator are capable of doing that propagation. An IP packet with a non-zero ECN field implies that the endpoints are ECN-capable, so this would be an ECN-PDU. However, ECN-PDU is intended to be a general term for a PDU at lower layers, as well as at the IP layer.
IPレイヤーまたはそれ以下のPDUは、渋滞制御フィードバックループの一部である輻輳を信号する能力を備えており、その中には、信号を荷重レギュレータに伝播するために必要なすべてのノードがその伝播を行うことができます。ゼロ以外のECNフィールドを持つIPパケットは、エンドポイントがECN対応であることを意味するため、これはECN-PDUになります。ただし、ECN-PDUは、IPレイヤーだけでなく、下層のPDUの一般的な用語であることを目的としています。
Not-ECN-PDU:
not-ecn-pdu：
A PDU at the IP layer or below that is part of a congestion control feedback loop that is not capable of propagating ECN signals back to the Load Regulator because at least one of the nodes necessary to propagate the signals is incapable of doing that propagation. Note that this definition is a property of the feedback loop, not necessarily of the PDU itself; certainly the PDU will self-describe the property in some protocols, but in others, the property might be carried in a separate control plane context (which is somehow bound to the PDU).
IPレイヤーまたはその下のPDUは、ECN信号をロードレギュレータに伝播することができない輻輳制御フィードバックループの一部です。これは、信号を伝播するために必要なノードの少なくとも1つがその伝播を行うことができないためです。この定義は、必ずしもPDU自体ではなく、フィードバックループのプロパティであることに注意してください。確かに、PDUは一部のプロトコルでプロパティを自己記述しますが、他のプロトコルでは、プロパティは別のコントロールプレーンコンテキスト（PDUに何らかの形でバインドされている）で運ばれる場合があります。
This section sets down the different modes by which congestion information is passed between the lower layer and the higher one. It acts as a reference framework for the subsequent sections that give normative guidelines for designers of congestion notification protocols, taking each mode in turn:
このセクションでは、下層層とより高いレイヤーの間に混雑情報が渡されるさまざまなモードを設定します。これは、各モードを順番に取得し、渋滞通知プロトコルの設計者に規範的なガイドラインを提供する後続セクションの参照フレームワークとして機能します。
Feed-Forward-and-Up:
フィードフォワードアンドアップ：
Nodes feed forward congestion notification towards the egress within the lower layer, then up and along the layers towards the end-to-end destination at the transport layer. The following local optimization is possible:
ノードは、輸送層のエンドツーエンドの宛先に向かって、下層内の出口に向かって、前方の輻輳通知を送ります。次のローカル最適化が可能です。
Feed-Up-and-Forward:
フィードアップとフォワード：
A lower-layer switch feeds up congestion notification directly into the higher layer (e.g., into the ECN field in the IP header), irrespective of whether the node is at the egress of a subnet.
低層スイッチは、ノードがサブネットの出口にあるかどうかに関係なく、混雑通知を高層に直接（例えば、IPヘッダーのECNフィールドに）フィードルします。
Feed-Backward:
フィードバックワード：
Nodes feed back congestion signals towards the ingress of the lower layer and (optionally) attempt to control congestion within their own layer.
ノードは、下層の侵入に向かってうっ血信号をフィードバックし、（オプションでは）独自の層内の輻輳を制御しようとします。
Null:
ヌル：
Nodes cannot experience congestion at the lower layer except at the ingress nodes of the subnet (which are IP-aware or equivalently higher-layer-aware).
ノードは、サブネットのイングレスノード（IP認識または同等に高層化）を除き、下層で輻輳を発生させることはできません。
Like IP and MPLS, many subnet technologies are based on self-contained PDUs or frames sent unreliably. They provide no feedback channel at the subnetwork layer, instead relying on higher layers (e.g., TCP) to feed back loss signals.
IPやMPLSと同様に、多くのサブネットテクノロジーは、自己完結型のPDUまたはフレームに基づいて送信されます。彼らは、サブネットワーク層でフィードバックチャネルを提供しません。代わりに、より高いレイヤー（TCPなど）に依存して損失信号をフィードバックします。
In these cases, ECN may best be supported by standardising explicit notification of congestion into the lower-layer protocol that carries the data forwards. Then, a specification is needed for how the egress of the lower-layer subnet propagates this explicit signal into the forwarded upper-layer (IP) header. This signal continues forwards until it finally reaches the destination transport (at L4). Typically, the destination will feed this congestion notification back to the source transport using an end-to-end protocol (e.g., TCP). This is the arrangement that has already been used to add ECN to IP-in-IP tunnels [RFC6040], IP-in-MPLS, and MPLS-in-MPLS [RFC5129].
これらの場合、ECNは、データを前方に運ぶ下層層プロトコルへの輻輳の明示的な通知を標準化することにより、最もよくサポートされる可能性があります。次に、下層サブネットの出口がこの明示的な信号を転送された上層（IP）ヘッダーにどのように伝播するかについては、仕様が必要です。この信号は、最終的に宛先輸送に到達するまで前方に続きます（L4で）。通常、目的地は、エンドツーエンドのプロトコル（TCPなど）を使用して、この混雑通知をソーストランスポートに送り返します。これは、IP-in-IPトンネル[RFC6040]、IP-in-MPLS、およびMPLS-in-MPLS [RFC5129]にECNを追加するためにすでに使用されている配置です。
This mode is illustrated in Figure 1. Along the middle of the figure, layers 2, 3, and 4 of the protocol stack are shown. One packet is shown along the bottom as it progresses across the network from source to destination, crossing two subnets connected by a router and crossing two switches on the path across each subnet. Congestion at the output of the first switch (shown as *) leads to a congestion marking in the L2 header (shown as C in the illustration of the packet). The chevrons show the progress of the resulting congestion indication. It is propagated from link to link across the subnet in the L2 header. Then, when the router removes the marked L2 header, it propagates the marking up into the L3 (IP) header. The router forwards the marked L3 header into subnet B. The L2 protocol used in subnet B does not support congestion notification, but the signal proceeds across it in the L3 header.
このモードを図1に示します。図の中央に沿って、プロトコルスタックのレイヤー2、3、および4を示します。1つのパケットは、ソースから宛先までネットワークを横切って進行する底に沿って表示され、ルーターで接続された2つのサブネットを横切り、各サブネットを横切るパスで2つのスイッチを横断します。最初のスイッチの出力（ *として表示される）での輻輳は、L2ヘッダー（パケットの図にCとして表示される）に輻輳マーキングにつながります。シェブロンは、結果として生じる鬱血指示の進行を示しています。L2ヘッダーのサブネットを横切るリンクにリンクから伝播します。次に、ルーターがマークされたL2ヘッダーを削除すると、マーキングをL3（IP）ヘッダーに伝播します。ルーターは、マークされたL3ヘッダーをサブネットBに転送します。SubNetBで使用されるL2プロトコルは、うっ血通知をサポートしませんが、信号はL3ヘッダーで進行します。
Note that there is no implication that each 'C' marking is encoded the same; a different encoding might be used for the 'C' marking in each protocol.
各「C」マーキングが同じエンコードされているという意味はないことに注意してください。各プロトコルの「C」マーキングには、別のエンコードが使用される場合があります。
Finally, for completeness, we show the L3 marking arriving at the destination, where the host transport protocol (e.g., TCP) feeds it back to the source in the L4 acknowledgement (the 'C' at L4 in the packet at the top of the diagram).
最後に、完全性のために、宛先に到着するL3マーキングが表示されます。ここでは、ホスト輸送プロトコル（TCPなど）がL4確認のソースに戻します（L4の「C」は、パケットの上部にあるパケットの「C」です。図）。
_ _ _
/_______ | | |C| ACK Packet (V)
\ |_|_|_|
+---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ |
| | . . . . . . Packet U. . | >>|>>> Packet U >>>>>>>>>>>>|>^ |L3
| | +---+ +---+ | ^ | +---+ +---+ | |
| | | *|>>>>>|>>>|>>>>>|>^ | | | | | | |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
source subnet A router subnet B dest
__ _ _ _| __ _ _ _| __ _ _| __ _ _ _|
| | | | | | | | |C| | | |C| | | |C| | Data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) /
layer:4 3 2A 4 3 2A 4 3 4 3 2B
header
Figure 1: Feed-Forward-and-Up Mode
図1：フィードフォワードアンドアップモード
Of course, modern networks are rarely as simple as this textbook example, often involving multiple nested layers. For example, a Third Generation Partnership Project (3GPP) mobile network may have two IP-in-IP GTP [GTPv1] tunnels in series and an MPLS backhaul between the base station and the first router. Nonetheless, the example illustrates the general idea of feeding congestion notification forward then upward whenever a header is removed at the egress of a subnet.
もちろん、最新のネットワークは、この教科書の例ほど単純ではなく、多くの場合、複数のネストされたレイヤーが含まれます。たとえば、第3世代のパートナーシッププロジェクト（3GPP）モバイルネットワークには、2つのIP-in-IP GTP [GTPV1]トンネルがシリーズで、基地局と最初のルーターの間のMPLSバックホールを備えている場合があります。それにもかかわらず、この例は、サブネットの出口でヘッダーが削除されるたびに、混雑通知に前方に供給するという一般的なアイデアを示しています。
Note that the Forward Explicit Congestion Notification (FECN) bit in Frame Relay [Buck00] and the Explicit Forward Congestion Indication (EFCI) [ITU-T.I.371] bit in ATM user data cells follow a feed-forward pattern. However, in ATM, this arrangement is only part of a feed-forward-and-backward pattern at the lower layer, not feed-forward-and-up out of the lower layer -- the intention was never to interface with IP-ECN at the subnet egress. To our knowledge, Frame Relay FECN is solely used by network operators to detect where they should provision more capacity.
ATMユーザーデータセルのFrame Relay [Buck00]および明示的な前方輻輳表示（EFCI）[ITU-T.I.371]ビットのフォワード明示的な輻輳通知（FECN）ビットは、フィードフォワードパターンに従うことに注意してください。ただし、ATMでは、この配置は下層のフィードフォワードアンドバックワードパターンの一部にすぎず、下層からフィードフォワードアンドアップではなく、IP-ECNとのインターフェースを取得することではありませんでした。サブネット出口で。私たちの知る限り、フレームリレーFECNは、ネットワークオペレーターがより多くの容量を提供する場所を検出するためにのみ使用されます。
Ethernet is particularly difficult to extend incrementally to support congestion notification. One way is to use so-called 'Layer 3 switches'. These are Ethernet switches that dig into the Ethernet payload to find an IP header and manipulate or act on certain IP fields (specifically Diffserv and ECN). For instance, in Data Center TCP [RFC8257], Layer 3 switches are configured to mark the ECN field of the IP header within the Ethernet payload when their output buffer becomes congested. With respect to switching, a Layer 3 switch acts solely on the addresses in the Ethernet header; it does not use IP addresses and it does not decrement the TTL field in the IP header.
イーサネットは、混雑通知をサポートするために徐々に拡張することが特に困難です。1つの方法は、いわゆる「レイヤー3スイッチ」を使用することです。これらは、イーサネットペイロードを掘り下げてIPヘッダーを見つけ、特定のIPフィールド（特にDiffServおよびECN）で操作または動作するイーサネットスイッチです。たとえば、データセンターTCP [RFC8257]では、レイヤー3スイッチが設定されており、出力バッファーが混雑したときにイーサネットペイロード内のIPヘッダーのECNフィールドをマークするように構成されています。切り替えに関して、レイヤー3スイッチは、イーサネットヘッダーのアドレスのみで機能します。IPアドレスは使用せず、IPヘッダーのTTLフィールドを減少させません。
_ _ _
/_______ | | |C| ACK packet (V)
\ |_|_|_|
+---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ |
| | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3
| | +--^+ +---+ | v| +---+ +---+ | ^ |
| | | *| | | | >|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
source subnet E router subnet F dest
__ _ _ _| __ _ _ _| __ _ _| __ _ _ _|
| | | | | | | |C| | | | |C| | | |C|C| Data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) /
layer:4 3 2 4 3 2 4 3 4 3 2
header
Figure 2: Feed-Up-and-Forward Mode
図2：フィードアップアンドフォワードモード
By comparing Figure 2 with Figure 1, it can be seen that subnet E (perhaps a subnet of Layer 3 Ethernet switches) works in feed-up-and-forward mode by notifying congestion directly into L3 at the point of congestion, even though the congested switch does not otherwise act at L3. In this example, the technology in subnet F (e.g., MPLS) does support ECN. So, when the router adds the Layer 2 header, it copies the ECN marking from L3 to L2 as well, as shown by the 'C's in both layers.
図2と図1を比較することで、サブネットE（おそらくレイヤー3イーサネットスイッチのサブネット）がフィードアップモードで動作していることがわかります。混雑したスイッチは、それ以外の場合はL3で作用しません。この例では、サブネットF（MPLSなど）のテクノロジーはECNをサポートしています。そのため、ルーターがレイヤー2ヘッダーを追加すると、両方のレイヤーの「C」で示されるように、L3からL2へのECNマークもコピーします。
In some Layer 2 technologies, congestion notification has been defined for use internally within the subnet with its own feedback and load regulation but the interface with IP for ECN has not been defined.
一部のレイヤー2テクノロジーでは、独自のフィードバックと負荷調節を備えたサブネット内で内部的に使用するための輻輳通知が定義されていますが、ECNのIPとのインターフェイスは定義されていません。
For instance, the relative rate mechanism was one of the more popular ways to manage traffic for the Available Bit Rate (ABR) service in ATM, and it tended to supersede earlier designs. In this approach, ATM switches send special resource management (RM) cells in both the forward and backward directions to control the ingress rate of user data into a virtual circuit. If a switch buffer is approaching congestion or is congested, it sends an RM cell back towards the ingress with respectively the No Increase (NI) or Congestion Indication (CI) bit set in its message type field [ATM-TM-ABR]. The ingress then holds or decreases its sending bit rate accordingly.
たとえば、相対レートメカニズムは、ATMで利用可能なビットレート（ABR）サービスでトラフィックを管理するためのより一般的な方法の1つであり、以前のデザインに優先する傾向がありました。このアプローチでは、ATMは順方向と後方方向の両方で特別なリソース管理（RM）セルを送信して、ユーザーデータの侵入率を仮想回路に制御します。スイッチバッファーが輻輳に近づいている場合、または混雑している場合、メッセージタイプフィールド[ATM-TM-ABR]に設定されている増加（NI）またはうっ血の表示（CI）ビットをそれぞれ侵入に向けて送り返します。イングレスは、それに応じて送信ビットレートを保持または減少させます。
_ _ _
/_______ | | |C| ACK packet (X)
\ |_|_|_|
+---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet X <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ |
| | | *|>>> Packet W >>>>>>>>>>>>|>^ |L3
| | +---+ +---+ | | +---+ +---+ | |
| | | | | | | <|<<<<<|<<<|<(V)<|<<<| | |L2
| | . . | . |Packet U | . . | . | . . | . | . . | .*| . . | |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
source subnet G router subnet H dest
__ _ _ _ __ _ _ _ __ _ _ __ _ _ _ later
| | | | | | | | | | | | | | | | |C| | data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (W) /
4 3 2 4 3 2 4 3 4 3 2
_
/__ |C| Feedback control
\ |_| cell/frame (V)
2
__ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier
| | | | | | | | | | | | | | | | | | | data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) /
layer: 4 3 2 4 3 2 4 3 4 3 2
header
Figure 3: Feed-Backward Mode
図3：フィードバックワードモード
ATM's feed-backward approach does not fit well when layered beneath IP's feed-forward approach unless the initial data source is the same node as the ATM ingress. Figure 3 shows the feed-backward approach being used in subnet H. If the final switch on the path is congested (*), it does not feed forward any congestion indications on the packet (U). Instead, it sends a control cell (V) back to the router at the ATM ingress.
ATMのフィードバックワードアプローチは、初期データソースがATMの侵入と同じノードでない限り、IPのフィードフォワードアプローチの下に階層化された場合、うまく適合しません。図3は、サブネットHで使用されているフィードバックワードアプローチを示しています。パスの最終的なスイッチが混雑している場合（*）、パケット（U）の輻輳指標を前方に供給しません。代わりに、コントロールセル（V）をATMINGRESSのルーターに送り返します。
However, the backward feedback does not reach the original data source directly because IP does not support backward feedback (and subnet G is independent of subnet H). Instead, the router in the middle throttles down its sending rate, but the original data sources don't reduce their rates. The resulting rate mismatch causes the middle router's buffer at layer 3 to back up until it becomes congested, which it signals forwards on later data packets at layer 3 (e.g., packet W). Note that the forward signal from the middle router is not triggered directly by the backward signal. Rather, it is triggered by congestion resulting from the middle router's mismatched rate response to the backward signal.
ただし、IPが後方フィードバックをサポートしていないため、後方フィードバックは元のデータソースに直接届きません（およびサブネットGはサブネットHとは無関係です）。代わりに、中央のルーターは送信率を下げますが、元のデータソースはレートを下げません。結果の速度の不一致により、レイヤー3の中央のルーターのバッファーが混雑するまでバックアップします。これは、レイヤー3の後のデータパケット（パケットWなど）で前方に進みます。中央のルーターからの前方信号は、後方信号によって直接トリガーされないことに注意してください。むしろ、それは、中央のルーターの逆方向信号に対する不一致の速度応答に起因するうっ血によって引き起こされます。
In response to this later forward signalling, end-to-end feedback at layer 4 finally completes the tortuous path of congestion indications back to the origin data source as before.
これに応じて、その後のフォワードシグナル伝達に応じて、レイヤー4のエンドツーエンドのフィードバックは、以前と同様に、オリジンのデータソースに戻る渋滞適応の曲がりくねったパスを最終的に完了します。
Quantized Congestion Notification (QCN) [IEEE802.1Q] would suffer from similar problems if extended to multiple subnets. However, QCN was clearly characterized as solely applicable to a single subnet from the start (see Section 6).
量子化された混雑通知（QCN）[IEEE802.1Q]は、複数のサブネットに拡張された場合、同様の問題に苦しむでしょう。ただし、QCNは、最初から単一のサブネットにのみ適用可能であると明確に特徴付けられました（セクション6を参照）。
Link- and physical-layer resources are often 'non-blocking' by design. Congestion notification may be implemented in these cases, but it does not need to be deployed at the lower layer; ECN in IP would be sufficient.
リンクおよび物理層のリソースは、多くの場合、設計によって「非ブロッキング」です。これらの場合には輻輳通知が実装される場合がありますが、下層に展開する必要はありません。IPのECNで十分です。
A degenerate example is a point-to-point Ethernet link. Excess loading of the link merely causes the queue from the higher layer to back up, while the lower layer remains immune to congestion. Even a whole meshed subnetwork can be made immune to interior congestion by limiting ingress capacity and sufficient sizing of interior links, e.g., a non-blocking fat-tree network [Leiserson85]. An alternative to fat links near the root is numerous thin links with multi-path routing to ensure even worst-case patterns of load cannot congest any link, e.g., a Clos network [Clos53].
縮退した例は、ポイントツーポイントイーサネットリンクです。リンクの過剰荷重は、高層からのキューを引き起こすだけで、下層は混雑の免疫のままです。メッシュ化されたサブネットワーク全体でさえ、インテリア容量とインテリアリンクの十分なサイジング、たとえば、非ブロッキング脂肪ツリーネットワーク[LeSerson85]を制限することにより、内部輻輳の免疫を作ることができます。ルート近くの脂肪リンクに代わるものは、マルチパスルーティングを備えた多数の薄いリンクであり、最悪のケースの負荷パターンでもリンクを混雑させることができないことを確認します。
Feed-forward-and-up is the mode already used for signalling ECN up the layers through MPLS into IP [RFC5129] and through IP-in-IP tunnels [RFC6040], whether encapsulating with IPv4 [RFC2003], IPv6 [RFC2473], or IPsec [RFC4301]. These RFCs take a consistent approach and the following guidelines are designed to ensure this consistency continues as ECN support is added to other protocols that encapsulate IP. The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in [RFC4774] and extended by [RFC8311].
フィードフォワードアンドアップとは、IPv4 [RFC2003]、IPv6 [RFC2473]でカプセル化するかどうかにかかわらず、MPLをIP [RFC5129]およびIP-in-IPトンネル[RFC6040]にECNを介してレイヤーのシグナルを既に使用しているモードです。またはIPSEC [RFC4301]。これらのRFCは一貫したアプローチを採用しており、ECNサポートがIPをカプセル化する他のプロトコルに追加されるため、この一貫性が継続されるように次のガイドラインが設計されています。ガイドラインは、[RFC4774]に与えられ、[RFC8311]によって拡張された代替ECNスキームの設計のためのより一般的な最良の現在の実践へのコンプライアンスを確保するためにも設計されています。
The rest of this section is structured as follows:
このセクションの残りの部分は、次のように構成されています。
* Section 4.1 addresses the most straightforward cases, where [RFC6040] can be applied directly to add ECN to tunnels that are effectively IP-in-IP tunnels, but with a shim header(s) between the IP headers.
* セクション4.1では、[RFC6040]を直接適用して、IP-in-IPトンネルであるが、IPヘッダー間のシムヘッダーを使用して、[RFC6040]を直接適用してECNを追加できます。
* The subsequent sections give guidelines for adding congestion notification to a subnet technology that uses feed-forward-and-up mode like IP, but it is not so similar to IP that [RFC6040] rules can be applied directly. Specifically:
* 後続のセクションでは、IPのようなフィードフォワードアンドアップモードを使用するサブネットテクノロジーに混雑通知を追加するためのガイドラインを示しますが、[RFC6040]ルールを直接適用できるIPとはあまり似ていません。具体的には：
- Sections 4.2, 4.3, and 4.4 address how to add ECN support to the wire protocol and to the encapsulators and decapsulators at the ingress and egress of the subnet, respectively.
- セクション4.2、4.3、および4.4は、サブネットの入り口と出口でそれぞれワイヤプロトコルとカプセル因子と脱カプセルターにECNサポートを追加する方法について説明します。
- Section 4.5 deals with the special but common case of sequences of tunnels or subnets that all use the same technology.
- セクション4.5では、すべて同じ技術を使用するトンネルまたはサブネットのシーケンスの特別だが一般的なケースを扱います。
- Section 4.6 deals with the question of reframing when IP packets do not map 1:1 into lower-layer frames.
- セクション4.6では、IPパケットが1：1を下層層フレームにマッピングしない場合のリフラミングの問題を扱います。
A common pattern for many tunnelling protocols is to encapsulate an inner IP header with a shim header(s) then an outer IP header. A shim header is defined as one that is not sufficient alone to forward the packet as an outer header. Another common pattern is for a shim to encapsulate an L2 header, which in turn encapsulates (or might encapsulate) an IP header. [RFC9601] clarifies that [RFC6040] is just as applicable when there are shims and even an L2 header between two IP headers.
多くのトンネルプロトコルの一般的なパターンは、シムヘッダーを使用して内側のIPヘッダーをカプセル化し、外側のIPヘッダーをカプセル化することです。シムヘッダーは、パケットを外側のヘッダーとして転送するのに十分ではないものとして定義されます。別の一般的なパターンは、シムがL2ヘッダーをカプセル化することであり、L2ヘッダーがIPヘッダーをカプセル化（またはカプセル化する可能性があります）です。[RFC9601]は、2つのIPヘッダーの間にシムとL2ヘッダーさえある場合、[RFC6040]が同じくらい該当することを明確にします。
However, it is not always feasible or necessary to propagate ECN between IP headers when separated by a shim. For instance, it might be too costly to dig to arbitrary depths to find an inner IP header, there may be little or no congestion within the tunnel by design (see null mode in Section 3.4 above), or a legacy implementation might not support ECN. In cases where a tunnel does not support ECN, it is important that the ingress does not copy the ECN field from an inner IP header to an outer. Therefore Section 4 of [RFC9601] requires network operators to configure the ingress of a tunnel that does not support ECN so that it zeros the ECN field in the outer IP header.
ただし、シムで区切った場合、IPヘッダー間でECNを伝播することは常に実行可能であるか、必要ではありません。たとえば、arbitrary意的な深さまで掘るにはコストがかかりすぎて内側のIPヘッダーを見つけることができない場合があります。設計によるトンネル内の混雑はほとんどまたはまったくない場合があります（上記のセクション3.4のNULLモードを参照）、またはレガシーの実装ではECNをサポートできない場合があります。。トンネルがECNをサポートしていない場合、侵入がECNフィールドを内部IPヘッダーから外側にコピーしないことが重要です。したがって、[RFC9601]のセクション4では、ネットワーク演算子がECNをサポートしないトンネルの侵入を構成して、外側のIPヘッダーのECNフィールドをゼロするように要求しています。
Nonetheless, in many cases it is feasible to propagate the ECN field between IP headers separated by shim headers and/or an L2 header. Particularly in the typical case when the outer IP header and the shim(s) are added (or removed) as part of the same procedure. Even if a shim encapsulates an L2 header, it is often possible to find an inner IP header within the L2 PDU and propagate ECN between that and the outer IP header. This can be thought of as a special case of the feed-up-and-forward mode (Section 3.2), so the guidelines for this mode apply (Section 5).
それにもかかわらず、多くの場合、Shimヘッダーおよび/またはL2ヘッダーで区切られたIPヘッダー間でECNフィールドを伝播することが可能です。特に、同じ手順の一部として外側のIPヘッダーとシムが追加（または削除）される典型的なケースで。シムがL2ヘッダーをカプセル化したとしても、L2 PDU内の内部IPヘッダーを見つけて、それと外部IPヘッダーの間にECNを伝播することがよくあります。これは、フィードアップアンドフォワードモード（セクション3.2）の特殊なケースと考えることができるため、このモードのガイドラインが適用されます（セクション5）。
Numerous shim protocols have been defined for IP tunnelling. More recent ones, e.g., Geneve [RFC8926] and Generic UDP Encapsulation (GUE) [INTAREA-GUE] cite and follow [RFC6040]. Some earlier ones, e.g., CAPWAP [RFC5415] and LISP [RFC9300], cite [RFC3168], which is compatible with [RFC6040].
IPトンネリング用に多数のシムプロトコルが定義されています。より最近のもの、たとえば、Geneve [RFC8926]および一般的なUDPカプセル化（GUE）[Intarea-gue]を引用してフォローします[RFC6040]。いくつかの以前のもの、例えば、capwap [rfc5415]およびlisp [rfc9300]が[rfc6040]と互換性のある[rfc3168]を引用します。
However, as Section 9.3 of [RFC3168] pointed out, ECN support needs to be defined for many earlier shim-based tunnelling protocols, e.g., L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637], GTP [GTPv1] [GTPv1-U] [GTPv2-C], and Teredo [RFC4380], as well as some recent ones, e.g., VXLAN [RFC7348], NVGRE [RFC7637], and NSH [RFC8300].
ただし、[RFC3168]のセクション9.3が指摘したように、ECNサポートは、以前のシムベースのトンネルプロトコル、例えばL2TPV2 [RFC2661]、L2TPV3 [RFC3931]、GRE [RFC2784]、PPTP [RFC2637]、PPTP [RFC2637]で定義する必要があります。[gtpv1] [gtpv1-u] [gtpv2-c]、およびteredo [rfc4380]、ならびに最近のもの、たとえば、vxlan [rfc7348]、nvgre [rfc7637]、およびnsh [rfc8300]。
All these IP-based encapsulations can be updated in one shot by simple reference to [RFC6040]. However, it would not be appropriate to update all these protocols from within the present guidance document. Instead, a companion specification [RFC9601] has the appropriate Standards Track status to update Standards Track protocols. For those that are not under IETF change control [RFC9601] can only recommend that the relevant body updates them.
これらのすべてのIPベースのカプセルは、[RFC6040]を簡単に参照することにより、1発で更新できます。ただし、現在のガイダンスドキュメント内からこれらすべてのプロトコルを更新することは適切ではありません。代わりに、コンパニオン仕様[RFC9601]には、適切な標準追跡ステータスがあり、標準トラックプロトコルを更新するためのステータスがあります。IETF Change Control [RFC9601]の下にない場合は、関連する本体がそれらを更新することのみを推奨できます。
This section is intended to guide the redesign of any lower-layer protocol that encapsulates IP to add built-in congestion notification support at the lower layer using feed-forward-and-up mode. It reflects the approaches used in [RFC6040] and in [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with [RFC6040] or [RFC5129] will already satisfy this guidance.
このセクションは、IPをカプセル化する下層層プロトコルの再設計をガイドし、フィードフォワードアンドアップモードを使用して下層に組み込みの渋滞通知サポートを追加することを目的としています。[RFC6040]および[RFC5129]で使用されるアプローチを反映しています。したがって、[RFC6040]または[RFC5129]にすでに準拠しているIP-in-IPトンネルまたはIP-in-MPLSまたはMPLS-in-MPLSカプセルは、すでにこのガイダンスを満たしています。
A lower-layer (or subnet) congestion notification system:
低層（またはサブネット）の混雑通知システム：
1. SHOULD NOT apply explicit congestion notifications to PDUs that are destined for legacy layer-4 transport implementations that will not understand ECN; and
1. ECNを理解できないレガシーレイヤー-4輸送の実装に向けられたPDUに明示的な渋滞通知を適用しないでください。そして
2. SHOULD NOT apply explicit congestion notifications to PDUs if the egress of the subnet might not propagate congestion notification onward into the higher layer.
2. サブネットの出口が輻輳通知を高層に前に伝播しない可能性がある場合、PDUに明示的なうっ血通知を適用しないでください。
We use the term ECN-PDU for a PDU on a feedback loop that will propagate congestion notification properly because it meets both the above criteria. Additionally, a Not-ECN-PDU is a PDU on a feedback loop that does not meet at least one of the criteria, and therefore will not propagate congestion notification properly. A corollary of the above is that a lower-layer congestion notification protocol:
上記の基準の両方を満たしているため、渋滞通知を適切に伝播するフィードバックループ上のPDUにECN-PDUという用語を使用します。さらに、非ECN-PDUは、基準の少なくとも1つを満たしていないため、輻輳通知を適切に伝達しないフィードバックループ上のPDUです。上記の結果は、低層の混雑通知プロトコルが次のことです。
3. SHOULD be able to distinguish ECN-PDUs from Not-ECN-PDUs.
3. ECN-PDUを非ECN-PDUSと区別できるはずです。
Note that there is no need for all interior nodes within a subnet to be able to mark congestion explicitly. A mix of drop and explicit congestion signals from different nodes is fine. However, if _any_ interior nodes might generate congestion markings, Guideline 2 above says that all relevant egress nodes SHOULD be able to propagate those markings up to the higher layer.
サブネット内のすべてのインテリアノードが渋滞を明示的にマークできるようにする必要はないことに注意してください。さまざまなノードからのドロップと明示的なうっ血信号の組み合わせは問題ありません。ただし、_ANY_インテリアノードがうっ血マーキングを生成する可能性がある場合、上記のガイドライン2によれば、関連するすべての出力ノードはそれらのマークをより高い層まで伝播できるはずです。
In IP, if the ECN field in each PDU is cleared to the Not ECN-Capable Transport (Not-ECT) codepoint, it indicates that the L4 transport will not understand congestion markings. A congested buffer must not mark these Not-ECT PDUs; therefore, it has to signal congestion by increasingly applying drop instead.
IPでは、各PDUのECNフィールドがECN対応輸送（非極端な）コードポイントにクリアされている場合、L4輸送が輻輳マークを理解していないことを示します。混雑したバッファーは、これらの非ectPDUをマークしてはなりません。したがって、代わりにドロップをますます適用することにより、うっ血を知らせる必要があります。
The mechanism a lower layer uses to distinguish the ECN capability of PDUs need not mimic that of IP. The above guidelines merely say that the lower-layer system as a whole should achieve the same outcome. For instance, ECN-capable feedback loops might use PDUs that are identified by a particular set of labels or tags. Alternatively, logical-link protocols that use flow state might determine whether a PDU can be congestion marked by checking for ECN support in the flow state. Other protocols might depend on out-of-band control signals.
下層がPDUのECN機能を区別するために使用するメカニズムは、IPのECN機能を模倣する必要はありません。上記のガイドラインには、低層システム全体が同じ結果を達成するはずだと言っているだけです。たとえば、ECNに対応するフィードバックループは、特定のラベルまたはタグセットによって識別されるPDUを使用する場合があります。あるいは、フロー状態を使用する論理リンクプロトコルは、PDUがフロー状態でECNサポートをチェックすることにより渋滞になるかどうかを判断する場合があります。他のプロトコルは、バンド外の制御信号に依存する場合があります。
The per-domain checking of ECN support in MPLS [RFC5129] is a good example of a way to avoid sending congestion markings to L4 transports that will not understand them without using any header space in the subnet protocol.
MPLS [RFC5129]でのECNサポートのドメインごとのチェックは、サブネットプロトコルでヘッダースペースを使用せずにそれらを理解できない混雑マーキングをL4トランスポートに送信することを避ける方法の良い例です。
In MPLS, header space is extremely limited; therefore, [RFC5129] does not provide a field in the MPLS header to indicate whether the PDU is an ECN-PDU or a Not-ECN-PDU. Instead, interior nodes in a domain are allowed to set explicit congestion indications without checking whether the PDU is destined for a L4 transport that will understand them. Nonetheless, this is made safe by requiring that the network operator upgrades all decapsulating edges of a whole domain at once as soon as even one switch within the domain is configured to mark rather than drop some PDUs during congestion. Therefore, any edge node that might decapsulate a packet will be capable of checking whether the higher-layer transport is ECN-capable. When decapsulating a CE-marked packet, if the decapsulator discovers that the higher layer (inner header) indicates the transport is not ECN-capable, it drops the packet -- effectively on behalf of the earlier congested node (see Decapsulation Guideline 1 in Section 4.4).
MPLSでは、ヘッダースペースは非常に限られています。したがって、[RFC5129]は、MPLSヘッダーのフィールドを提供して、PDUがECN-PDUであるか非ECN-PDUであるかを示します。代わりに、ドメイン内の内部ノードは、PDUがそれらを理解するL4輸送に運命づけられているかどうかをチェックせずに明示的な鬱血指示を設定することができます。それにもかかわらず、これは、ドメイン内の1つのスイッチが輻輳中にPDUをドロップするのではなくマークするように構成されているとすぐに、ドメイン全体のすべての脱カプセル化エッジをすぐにアップグレードすることを要求することにより、安全にされています。したがって、パケットを脱カプセル化する可能性のあるエッジノードは、高層輸送がECN対応であるかどうかを確認できます。CEマークされたパケットを脱カプセル化する場合、脱カプセレーターが高レイヤー（内側ヘッダー）がトランスポートがECN対応ではないことを示すことを発見した場合、パケットをドロップします - 以前の混雑したノードに代わって効果的にドロップします（セクションの脱カプセル化ガイドライン1を参照4.4）。
It was only appropriate to define such an incremental deployment strategy because MPLS is targeted solely at professional operators who can be expected to ensure that a whole subnetwork is consistently configured. This strategy might not be appropriate for other link technologies targeted at zero-configuration deployment or deployment by the general public (e.g., Ethernet). For such 'plug-and-play' environments, it will be necessary to invent a fail-safe approach that ensures congestion markings will never fall into black holes, no matter how inconsistently a system is put together. Alternatively, congestion notification relying on correct system configuration could be confined to flavours of Ethernet intended only for professional network operators, such as Provider Backbone Bridges (PBB) ([IEEE802.1Q]; previously 802.1ah).
MPLSは、サブネットワーク全体が一貫して構成されていることを保証することが期待できるプロのオペレーターのみをターゲットにしているため、このような増分展開戦略を定義することは適切でした。この戦略は、一般大衆によるゼロコンフィグレーターの展開または展開を対象とした他のリンクテクノロジーに適していない可能性があります（例：イーサネット）。このような「プラグアンドプレイ」環境では、システムがいかに一貫性のないシステムが組み立てられていても、混雑マーキングがブラックホールに落ちることは決してないことを保証するフェイルセーフアプローチを発明する必要があります。あるいは、正しいシステム構成に依存している混雑通知は、プロバイダーのバックボーンブリッジ（PBB）（[IEEE802.1Q];以前は802.1AH）などの専門的なネットワークオペレーターのみを対象としたイーサネットのフレーバーに限定される可能性があります。
ECN support in TRansparent Interconnection of Lots of Links (TRILL) [RFC9600] provides a good example of how to add congestion notification to a lower-layer protocol without relying on careful and consistent operator configuration. TRILL provides an extension header word with space for flags of different categories depending on whether logic to understand the extension is critical. The congestion-experienced marking has been defined as a 'critical ingress-to-egress' flag. So, if a transit RBridge sets this flag on a frame and an egress RBridge does not have any logic to process it, the egress RBridge will drop the frame, which is the desired default action anyway. Therefore, TRILL RBridges can be updated with support for congestion notification in no particular order and, at the egress of the TRILL campus, congestion notification will be propagated to IP as ECN whenever ECN logic has been implemented at the egress, or as drop otherwise.
多くのリンク（TRILL）[RFC9600]の透明な相互接続におけるECNサポートは、慎重かつ一貫した演算子構成に依存せずに、下層層プロトコルにうっ血通知を追加する方法の良い例を提供します。Trillは、拡張機能を理解するためのロジックが重要であるかどうかに応じて、異なるカテゴリのフラグのためのスペースを備えた拡張ヘッダーワードを提供します。輻輳に精通したマーキングは、「批判的な侵入から侵入する」フラグとして定義されています。したがって、トランジットRbridgeがこのフラグをフレームに設定し、出力rbridgeに処理するロジックがない場合、Egress Rbridgeはフレームをドロップします。これはとにかく目的のデフォルトアクションです。したがって、Trill Rbridgesは、渋滞通知のサポートを適切に順番に更新でき、Trillキャンパスの出口では、ECNロジックが出口で実装されている場合、またはそれ以外のドロップとして、渋滞通知がECNとしてIPに伝播されます。
QCN [IEEE802.1Q] is not intended to extend beyond a single subnet or interoperate with IP-ECN. Nonetheless, the way QCN indicates to lower-layer devices that the endpoints will not understand QCN provides another example that a lower-layer protocol designer might be able to mimic for their scenario. An operator can define certain Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to indicate non-QCN frames. Then an ingress bridge has to map each arriving not-QCN-capable IP packet to one of these non-QCN PCPs.
QCN [IEEE802.1Q]は、単一のサブネットを超えて拡張したり、IP-ECNとの相互操作を目的としていません。それにもかかわらず、QCNがエンドポイントがQCNを理解していないことをより低層デバイスに示す方法は、低層プロトコルデザイナーがシナリオを模倣できる別の例を提供します。オペレーターは、特定の優先度コードポイント（PCPS [IEEE802.1Q];以前802.1p）を定義して、非QCNフレームを示すことができます。その後、侵入ブリッジは、到着する各QCN対応IPパケットをこれらの非QCN PCPのいずれかにマッピングする必要があります。
When drop for non-ECN traffic is deferred to the egress of a subnet, it cannot necessarily be assumed that one congestion mark is equivalent to one drop, as was originally required by [RFC3168]. [RFC8311] updated [RFC3168] to allow experimentation with congestion markings that are not equivalent to drop, particularly for L4S [RFC9331]. ECN support in TRILL [RFC9600] is a good example of a way to defer drop to the egress of a subnet both when marks are equivalent to drops (as in [RFC3168]) and when they are not (as in L4S). The ECN scheme for MPLS [RFC5129] was defined before L4S, so it only currently supports deferred drop that is equivalent to ECN marking. Nonetheless, in principle, MPLS (and potentially future L2 protocols) could support L4S marking by copying TRILL's approach for determining the drop level of any non-ECN traffic at the subnet egress.
非ECNトラフィックのドロップがサブネットの出口に延期される場合、[RFC3168]で必要とされていたように、1つの混雑マークが1滴に相当すると仮定することはできません。[RFC8311]は[RFC3168]を更新して、特にL4S [RFC9331]では、低下と同等ではないうっ血マーキングの実験を可能にしました。Trill [RFC9600]でのECNサポートは、マークが（[RFC3168]のように）ドロップと同等であり、（L4Sのように）ドロップに相当する場合の両方でサブネットの出力にドロップを延期する方法の良い例です。MPLS [RFC5129]のECNスキームはL4Sの前に定義されていたため、現在はECNマーキングに相当する延期ドロップのみをサポートしています。それにもかかわらず、原則として、MPL（および潜在的に将来のL2プロトコル）は、サブネット出口でのECNトラフィックのドロップレベルを決定するためのTrillのアプローチをコピーすることにより、L4Sマーキングをサポートできます。
This section is intended to guide the redesign of any node that encapsulates IP with a lower-layer header when adding built-in congestion notification support to the lower-layer protocol using feed-forward-and-up mode. It reflects the approaches used in [RFC6040] and [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with [RFC6040] or [RFC5129] will already satisfy this guidance.
このセクションは、フィードフォワードアンドアップモードを使用して下層層プロトコルに組み込みのうっ血通知サポートを追加する際に、下層ヘッダーでIPをカプセル化するノードの再設計をガイドすることを目的としています。[RFC6040]および[RFC5129]で使用されるアプローチを反映しています。したがって、[RFC6040]または[RFC5129]にすでに準拠しているIP-in-IPトンネルまたはIP-in-MPLSまたはMPLS-in-MPLSカプセルは、すでにこのガイダンスを満たしています。
1. Egress Capability Check: A subnet ingress needs to be sure that the corresponding egress of a subnet will propagate any congestion notification added to the outer header across the subnet. This is necessary in addition to checking that an incoming PDU indicates an ECN-capable (L4) transport. Examples of how this guarantee might be provided include:
1. 出力能力チェック：サブネットのイングレスは、サブネットの対応する出口が、サブネットを横切る外側のヘッダーに追加されたうっ血通知を伝播することを確認する必要があります。これは、着信PDUがECN対応（L4）輸送を示すことを確認することに加えて必要です。この保証がどのように提供されるかの例は次のとおりです。
* by configuration (e.g., if any label switch in a domain supports congestion marking, [RFC5129] requires all egress nodes to have been configured to propagate ECN).
* 構成によって（たとえば、ドメイン内のラベルスイッチがうっ血マーキングをサポートする場合、[RFC5129]では、すべての出力ノードがECNを伝播するように構成されている必要があります）。
* by the ingress explicitly checking that the egress propagates ECN (e.g., an early attempt to add ECN support to TRILL used IS-IS to check path capabilities before adding ECN extension flags to each frame [RFC7780]).
* 侵入がECNを伝播することを明示的に確認することにより（たとえば、使用されたTrill IS-ISにECNサポートを追加するための早期の試みで、各フレームにECN拡張フラグを追加する前にパス機能をチェックする[RFC7780]）。
* by inherent design of the protocol (e.g., by encoding congestion marking on the outer header in such a way that a legacy egress that does not understand ECN will consider the PDU corrupt or invalid and discard it; thus, at least propagating a form of congestion signal).
* プロトコルの固有の設計により（例えば、ECNを理解していないレガシーの出口がPDUの腐敗または無効を考慮して廃棄するように外側のヘッダーに輻輳マーキングをエンコードすることにより、少なくともうっ血の形を伝播する信号）。
2. Egress Fails Capability Check: If the ingress cannot guarantee that the egress will propagate congestion notification, the ingress SHOULD disable congestion notification at the lower layer when it forwards the PDU. An example of how the ingress might disable congestion notification at the lower layer would be by setting the outer header of the PDU to identify it as a Not-ECN-PDU, assuming the subnet technology supports such a concept.
2. 出力に失敗した能力チェック：侵入が出口が輻輳通知を伝播することを保証できない場合、侵入はPDUを転送するときに下層で輻輳通知を無効にするはずです。侵入が下層での輻輳通知を無効にする方法の例は、SubNetテクノロジーがそのような概念をサポートすると仮定して、PDUの外側ヘッダーを非ECN-PDUとして識別するために設定することです。
3. Standard Congestion Monitoring Baseline: Once the ingress to a subnet has established that the egress will correctly propagate ECN, on encapsulation, it SHOULD encode the same level of congestion in outer headers as is arriving in incoming headers. For example, it might copy any incoming congestion notifications into the outer header of the lower-layer protocol.
3. 標準的な混雑モニタリングベースライン：サブネットへの侵入が、出口がカプセル化時にECNを正しく伝播することを確認したら、着信ヘッダーに到着しているのと同じレベルの混雑をエンコードする必要があります。たとえば、下層プロトコルの外側ヘッダーに入ってくる混雑通知をコピーする場合があります。
This ensures that bulk congestion monitoring of outer headers (e.g., by a network management node monitoring congestion markings in passing frames) will measure congestion accumulated along the whole upstream path, starting from the Load Regulator and not just starting from the ingress of the subnet. A node that is not the Load Regulator SHOULD NOT re-initialize the level of CE markings in the outer header to zero.
これにより、外側のヘッダーのバルク輻輳監視（たとえば、通過フレームの渋滞マークを監視するネットワーク管理ノードによる）が、サブネットの侵入から始まるロードレギュレータから始まる上流パス全体に沿って蓄積された渋滞を測定することが保証されます。負荷レギュレータではないノードは、外側ヘッダーのCEマークのレベルをゼロに再発明しないでください。
It would still also be possible to measure congestion introduced across one subnet (or tunnel) by subtracting the level of CE markings on inner headers from that on outer headers (see Appendix C of [RFC6040]). For example:
また、外側ヘッダーの内側ヘッダーのCEマーキングのレベルを減算することにより、1つのサブネット（またはトンネル）に導入された輻輳を測定することも可能です（[RFC6040]の付録Cを参照）。例えば：
* If this guideline has been followed and if the level of CE markings is 0.4% on the outer header and 0.1% on the inner header, 0.4% congestion has been introduced across all the networks since the Load Regulator, and 0.3% (= 0.4% - 0.1%) has been introduced since the ingress to the current subnet (or tunnel).
* このガイドラインが守られ、CEマーキングのレベルが外側ヘッダーで0.4％、内側のヘッダーで0.1％である場合、負荷レギュレータ以降のすべてのネットワークに0.4％のうっ血が導入され、0.3％（= 0.4％（= 0.4％）が導入されました-0.1％）は、現在のサブネット（またはトンネル）への侵入から導入されています。
* Without this guideline, if the subnet ingress had re-initialized the outer congestion level to zero, the outer and inner headers would measure 0.1% and 0.3%. It would still be possible to infer that the congestion introduced since the Load Regulator was 0.4% (= 0.1% + 0.3%), but only if the monitoring system somehow knows whether the subnet ingress re-initialized the congestion level.
* このガイドラインがなければ、サブネットのイングレスが外側の輻輳レベルをゼロに再発明した場合、外側と内側のヘッダーは0.1％と0.3％を測定します。負荷レギュレータ以降に導入された混雑が0.4％（= 0.1％ + 0.3％）であると推測することは依然として可能ですが、監視システムがサブネットのイングレスが混雑レベルを再発行したかどうかを何らかの形で知っている場合のみです。
As long as subnet and tunnel technologies use the standard congestion monitoring baseline in this guideline, monitoring systems will know to use the former approach rather than having to 'somehow know' which approach to use.
サブネットとトンネルのテクノロジーがこのガイドラインで標準的な輻輳監視ベースラインを使用している限り、監視システムは、使用するアプローチを「何らかの形で知る」ことではなく、以前のアプローチを使用することを知っています。
This section is intended to guide the redesign of any node that decapsulates IP from within a lower-layer header when adding built-in congestion notification support to the lower-layer protocol using feed-forward-and-up mode. It reflects the approaches used in [RFC6040] and in [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with [RFC6040] or [RFC5129] will already satisfy this guidance.
このセクションは、フィードフォワードアンドアップモードを使用して下層層プロトコルに組み込みの輻輳通知サポートを追加する際に、下層ヘッダー内からIPを脱カプセル化するノードの再設計をガイドすることを目的としています。[RFC6040]および[RFC5129]で使用されるアプローチを反映しています。したがって、[RFC6040]または[RFC5129]にすでに準拠しているIP-in-IPトンネルまたはIP-in-MPLSまたはMPLS-in-MPLSカプセルは、すでにこのガイダンスを満たしています。
A subnet egress SHOULD NOT simply copy congestion notifications from outer headers to the forwarded header. It SHOULD calculate the outgoing congestion notification field from the inner and outer headers using the following guidelines. If there is any conflict, rules earlier in the list take precedence over rules later in the list.
サブネットの出口は、外側のヘッダーから転送されたヘッダーに混雑通知を単純にコピーする必要はありません。次のガイドラインを使用して、内側および外側のヘッダーから発信渋滞通知フィールドを計算する必要があります。競合がある場合、リストの前半のルールは、リストの後半でルールよりも優先されます。
1. If the arriving inner header is a Not-ECN-PDU, it implies the L4 transport will not understand explicit congestion markings. Then:
1. 到着する内側のヘッダーが非ECN-PDUである場合、L4輸送が明示的な輻輳マークを理解しないことを意味します。それから：
* If the outer header carries an explicit congestion marking, it is likely that a protocol error has occurred, so drop is the only indication of congestion that the L4 transport will understand. If the outer congestion marking is the most severe possible, the packet MUST be dropped. However, if congestion can be marked with multiple levels of severity and the packet's outer marking is not the most severe, this requirement can be relaxed to: the packet SHOULD be dropped.
* 外側のヘッダーが明示的な輻輳マーキングを搭載している場合、プロトコルエラーが発生した可能性が高いため、L4輸送が理解する渋滞の唯一の兆候です。外側の輻輳マーキングが可能な限り最も深刻な場合、パケットをドロップする必要があります。ただし、混雑に複数のレベルの重大度でマークされ、パケットの外側マーキングが最も深刻ではない場合、この要件は緩和することができます。パケットは削除する必要があります。
* If the outer is an ECN-PDU that carries no indication of congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but still as a Not-ECN-PDU.
* 外側が輻輳や非ecn-PDUの兆候を持たないECN-PDUである場合、PDUは転送する必要がありますが、それでも非ECN-PDUとして。
2. If the outer header does not support congestion notification (a Not-ECN-PDU), but the inner header does (an ECN-PDU), the inner header SHOULD be forwarded unchanged.
2. 外側のヘッダーが混雑通知（非ECN-PDU）をサポートしていないが、内側のヘッダー（ECN-PDU）が行う場合、内側のヘッダーは変更せずに転送する必要があります。
3. In some lower-layer protocols, congestion may be signalled as a numerical level, such as in the control frames of QCN [IEEE802.1Q]. If such a multi-bit encoding encapsulates an ECN-capable IP data packet, a function will be needed to convert the quantized congestion level into the frequency of congestion markings in outgoing IP packets.
3. 一部の低層プロトコルでは、QCN [IEEE802.1Q]の制御フレームなど、輻輳が数値レベルとして信号を受ける場合があります。このようなマルチビットエンコーディングがECN対応IPデータパケットをカプセル化する場合、量子化された輻輳レベルを発信IPパケットの輻輳マークの頻度に変換するために関数が必要になります。
4. Congestion indications might be encoded by a severity level. For instance, increasing levels of congestion might be encoded by numerically increasing indications, e.g., PCN can be encoded in each PDU at three severity levels in IP or MPLS [RFC6660] and the default encapsulation and decapsulation rules [RFC6040] are compatible with this interpretation of the ECN field.
4. 輻輳適応は、重大度レベルによってエンコードされる場合があります。たとえば、輻輳のレベルの増加は、数値的に増加する適応症によってエンコードされる可能性があります。たとえば、PCNは、IPまたはMPLS [RFC6660]の3つの重症度レベルで各PDUでエンコードでき、デフォルトのカプセル化および脱カプセル化ルール[RFC6040]は、この解釈と互換性があります。ECNフィールドの。
If the arriving inner header is an ECN-PDU, where the inner and outer headers carry indications of congestion of different severity, the more severe indication SHOULD be forwarded in preference to the less severe.
到着する内側のヘッダーがECN-PDUであり、内側と外側のヘッダーが異なる重大度の鬱血の適応症を挙げている場合、より深刻な兆候は、より深刻なものよりも優先されて転送する必要があります。
5. The inner and outer headers might carry a combination of congestion notification fields that should not be possible given any currently used protocol transitions. For instance, if Encapsulation Guideline 3 in Section 4.3 had been followed, it should not be possible to have a less severe indication of congestion in the outer header than in the inner header. It MAY be appropriate to log unexpected combinations of headers and possibly raise an alarm.
5. 内側と外側のヘッダーには、現在使用されているプロトコル遷移を考慮して、不可能な輻輳通知フィールドの組み合わせがある場合があります。たとえば、セクション4.3のカプセル化ガイドライン3が守られていた場合、外側のヘッダーでは、内側のヘッダーよりも鬱血の兆候がそれほど深刻ではないことを示すことはできません。ヘッダーの予期しない組み合わせを記録し、おそらくアラームを上げることが適切かもしれません。
If a safe outgoing codepoint can be defined for such a PDU, the PDU SHOULD be forwarded rather than dropped. Some implementers discard PDUs with currently unused combinations of headers just in case they represent an attack. However, an approach using alarms and policy-mediated drop is preferable to hard-coded drop so that operators can keep track of possible attacks, but currently unused combinations are not precluded from future use through new standards actions.
このようなPDUに対して安全な発信コードポイントを定義できる場合、PDUはドロップするのではなく転送する必要があります。一部の実装者は、攻撃を表す場合に備えて、ヘッダーの現在使用されていない組み合わせでPDUを廃棄します。ただし、アラームとポリシーを介したドロップを使用したアプローチは、オペレーターが可能な攻撃を追跡できるように、ハードコーディングドロップよりも好ましいですが、現在未使用の組み合わせは、新しい標準アクションを通じて将来の使用から排除されません。
In some deployments, particularly in 3GPP networks, an IP packet may traverse two or more IP-in-IP tunnels in sequence that all use identical technology (e.g., GTP).
いくつかの展開、特に3GPPネットワークでは、IPパケットは、すべてが同一のテクノロジー（GTPなど）を使用する2つ以上のIP-in-IPトンネルを順番に通過する場合があります。
In such cases, it would be sufficient for every encapsulation and decapsulation in the chain to comply with [RFC6040]. Alternatively, as an optimization, a node that decapsulates a packet and immediately re-encapsulates it for the next tunnel MAY copy the incoming outer ECN field directly to the outgoing outer header and the incoming inner ECN field directly to the outgoing inner header. Then, the overall behaviour across the sequence of tunnel segments would still be consistent with [RFC6040].
そのような場合、チェーン内のすべてのカプセル化と脱カプセル化が[RFC6040]に準拠するだけで十分でしょう。あるいは、最適化として、パケットを再カプセル化し、すぐに再カプセル化するノードは、次のトンネルのためにそれを直ちに再カプセル化することができます。外側のECNフィールドを発信外のヘッダーに直接コピーし、入ってくる内側ECNフィールドを直接発信内ヘッダーにコピーします。次に、トンネルセグメントのシーケンス全体の全体的な動作は、[RFC6040]と依然として一致します。
Appendix C of [RFC6040] describes how a tunnel egress can monitor how much congestion has been introduced within a tunnel. A network operator might want to monitor how much congestion had been introduced within a whole sequence of tunnels. Using the technique in Appendix C of [RFC6040] at the final egress, the operator could monitor the whole sequence of tunnels, but only if the above optimization were used consistently along the sequence of tunnels, in order to make it appear as a single tunnel. Therefore, tunnel endpoint implementations SHOULD allow the operator to configure whether this optimization is enabled.
[RFC6040]の付録Cでは、トンネルの出口がトンネル内にどの程度の混雑が導入されたかを監視する方法を説明しています。ネットワークオペレーターは、一連のトンネル内でどれだけの混雑が導入されたかを監視したい場合があります。最終出力で[RFC6040]の付録Cの手法を使用すると、オペレーターはトンネルのシーケンス全体を監視できますが、上記の最適化がトンネルのシーケンスに沿って一貫して使用された場合にのみ、単一のトンネルとして表示されます。。したがって、トンネルエンドポイントの実装により、オペレーターはこの最適化が有効になっているかどうかを構成できるようにする必要があります。
When congestion notification support is added to a subnet technology, consideration SHOULD be given to a similar optimization between subnets in sequence if they all use the same technology.
輻輳通知サポートがサブネットテクノロジーに追加される場合、すべて同じテクノロジーを使用している場合、順番にサブネット間の同様の最適化を考慮する必要があります。
The guidance in this section is worded in terms of framing boundaries, but it applies equally whether the PDUs are frames, cells, or packets.
このセクションのガイダンスは、フレーミングの境界の観点から表現されていますが、PDUがフレーム、セル、またはパケットであるかどうかも同様に適用されます。
Where an AQM marks the ECN field of IP packets as they queue into a Layer 2 link, there will be no problem with framing boundaries because the ECN markings would be applied directly to IP packets. The guidance in this section is only applicable where a congestion notification capability is being added to a Layer 2 protocol so that Layer 2 frames can be marked by an AQM at layer 2. This would only be necessary where AQM will be applied at pure Layer 2 nodes (without IP awareness).
AQMがIPパケットのECNフィールドをマークする場合、レイヤー2リンクにキューするときに、ECNマーキングがIPパケットに直接適用されるため、フレーミング境界に問題はありません。このセクションのガイダンスは、レイヤー2フレームをレイヤー2のAQMでマークできるように、渋滞通知機能がレイヤー2プロトコルに追加されている場合にのみ適用されます。これは、AQMが純粋なレイヤー2で適用される場合にのみ必要です。ノード（IP認識なし）。
Where congestion marking has had to be applied at non-IP-aware nodes and framing boundaries do not necessarily align with packet boundaries, the decapsulating IP forwarding node SHOULD propagate congestion markings from Layer 2 frame headers to IP packets that may have different boundaries as a consequence of reframing.
渋滞マーキングが非IP認識ノードに適用されなければならない場合、フレーミング境界は必ずしもパケット境界に沿っているわけではありません。脱カプセル化IP転送ノードは、レイヤー2フレームヘッダーからIPパケットへの輻輳マーキングを推進する必要があります。再構成の結果。
Two possible design goals for propagating congestion indications, described in Section 5.3 of [RFC3168] and Section 2.4 of [RFC7141], are:
[RFC3168]のセクション5.3および[RFC7141]のセクション2.4で説明されている輻輳適応を伝播するための2つの可能な設計目標は次のとおりです。
1. approximate preservation of the presence (and therefore timing) of congestion marks on the L2 frames used to construct an IP packet;
1. IPパケットの構築に使用されるL2フレーム上の輻輳マークの存在（したがってタイミング）のおおよその保存。
a. at high frequency of congestion marking, approximate preservation of the proportion of congestion marks arriving and departing;
a. 輻輳マーキングの高頻度では、到着して出発する混雑マークの割合の近似保存。
b. at low frequency of congestion marking, approximate preservation of the timing of congestion marks arriving and departing.
b. 輻輳マーキングの頻度が低い場合、浸透マークのタイミングの近似維持と出発。
In either case, an implementation SHOULD ensure that any new incoming congestion indication is propagated immediately; not held awaiting the possibility of further congestion indications to be sufficient to indicate congestion on an outgoing PDU [RFC7141]. Nonetheless, to facilitate pipelined implementation, it would be acceptable for congestion marks to propagate to a slightly later IP packet.
どちらの場合でも、実装は、新しい入ってくる輻輳の表示がすぐに伝播されるようにする必要があります。発信PDU [RFC7141]で混雑を示すのに十分であるとさらなる輻輳兆候の可能性を待っていなかった。それにもかかわらず、パイプラインの実装を促進するために、うっ血マークがわずかに後のIPパケットに伝播することは許容されます。
At decapsulation in either case:
どちらの場合でも脱カプセル化時：
* ECN-marking propagation logically occurs before application of Decapsulation Guideline 1 in Section 4.4. For instance, if ECN-marking propagation would cause an ECN congestion indication to be applied to an IP packet that is a Not-ECN-PDU, then that IP packet is dropped in accordance with Guideline 1.
* ECNマーキング伝播は、セクション4.4で脱カプセル化ガイドライン1を適用する前に論理的に発生します。たとえば、ECNマークの伝播により、ECNの鬱血指示が非ECN-PDUであるIPパケットに適用される場合、そのIPパケットはガイドライン1に従ってドロップされます。
* Where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the same IP packet, the decapsulation specification SHOULD require that packet to be discarded.
* ECN-PDUと非ECN-PDUの組み合わせが同じIPパケットを構築するために到着する場合、脱カプセル化仕様にはパケットを破棄する必要があります。
* Where a mix of different types of ECN-PDUs arrives to construct the same IP packet, e.g., a mix of frames that map to ECT(0) and ECT(1) IP packets, the decapsulation specification might consider this a protocol error. But, if the lower-layer protocol has defined such a mix of types of ECN-PDU as valid, it SHOULD require the resulting IP packet to be set to either ECT(0) or ECT(1). In this case, it SHOULD take into account that the RFC Series has so far allowed ECT(0) and ECT(1) to be considered equivalent [RFC3168]; or ECT(1) can provide a less severe congestion marking than CE [RFC6040]; or ECT(1) can indicate an unmarked but ECN-capable packet that is subject to a different marking algorithm to ECT(0) packets, e.g., L4S [RFC8311] [RFC9331].
* 異なるタイプのECN-PDUの組み合わせが到着して同じIPパケットを構築する場合、たとえばECT（0）とECT（1）IPパケットにマッピングされるフレームの組み合わせを作成する場合、脱カプセル化仕様はこれをプロトコルエラーと見なす場合があります。ただし、低層プロトコルが有効と同じようなタイプのECN-PDUを定義した場合、結果のIPパケットをECT（0）またはECT（1）のいずれかに設定する必要があります。この場合、RFCシリーズがこれまでのところECT（0）とECT（1）を同等の[RFC3168]と見なすことが許可されていることを考慮に入れる必要があります。またはECT（1）は、CE [RFC6040]よりも少ない渋滞マーキングを提供できます。またはECT（1）は、ECT（0）パケット（L4S [RFC8311] [RFC9331]などの異なるマーキングアルゴリズムの対象となるマークのないがECN対応パケットを示すことができます。
The following are two ways that goal 1 might be achieved, but they are not intended to be the only ways:
以下は、ゴール1が達成される可能性がある2つの方法ですが、唯一の方法ではありません。
* Every IP PDU that is constructed, in whole or in part, from an L2 frame that is marked with a congestion signal has that signal propagated to it.
* 全体的または部分的に構築されたすべてのIP PDUは、混雑信号でマークされたL2フレームから構築されています。その信号はそれに伝播されます。
* Every L2 frame that is marked with a congestion signal propagates that signal to one IP PDU that is constructed from it in whole or in part. If multiple IP PDUs meet this description, the choice can be made arbitrarily but ought to be consistent.
* 輻輳信号でマークされたすべてのL2フレームは、全体または一部に構築された1つのIP PDUにその信号を伝播します。複数のIPPDUがこの説明を満たしている場合、選択は任意に行うことができますが、一貫性があるはずです。
The following gives one way that goal 2 might be achieved, but it is not intended to be the only way:
以下は、Goal 2が達成される可能性のある1つの方法を示していますが、唯一の方法であることを意図したものではありません。
* For each of the streams of frames that encapsulate the IP packets of each IP-ECN codepoint and follow the same path through the subnet, a counter ('in') tracks octets arriving within the payload of marked L2 frames and another ('out') tracks octets departing in marked IP packets. While 'in' exceeds 'out', forwarded IP packets are ECN-marked. If 'out' exceeds 'in' for longer than a timeout, both counters are zeroed to ensure that the start of the next congestion episode propagates immediately. The 'out' counter includes octets in reconstructed IP packets that would have been marked, but had to be dropped because they were Not-ECN-PDUs (by Decapsulation Guideline 1 in Section 4.4).
* 各IP-ECN CodePointのIPパケットをカプセル化し、サブネットを通る同じパスを通過するフレームの各ストリームについて、マークされたL2フレームのペイロード内に到着したカウンター（ 'in'）を追跡します。）マークされたIPパケットで出発するオクテットを追跡します。「in 'in' ofs 'out'を超えている間、転送されたIPパケットはecnマークされています。「out」がタイムアウトよりも長く「」を超えると、両方のカウンターがゼロにされ、次の輻輳エピソードの開始がすぐに伝播するようにします。「Out」カウンターには、マークされていたが、再構築されたIPパケットにオクテットが含まれていましたが、ECN-PDUではないためにドロップする必要がありました（セクション4.4の脱カプセル化ガイドライン1）。
Generally, relative to the number of IP PDUs, the number of L2 frames may be higher (e.g., ATM), roughly the same, or lower (e.g., 802.11 aggregation at an L2-only station). This distinction may influence the choice of mechanism.
一般に、IP PDUの数と比較して、L2フレームの数（たとえば、ATM）、ほぼ同じまたは低い（L2のみのステーションでの802.11集約）が高い場合があります。この区別は、メカニズムの選択に影響を与える可能性があります。
The guidance in this section is applicable, for example, when IP packets:
このセクションのガイダンスは、たとえばIPパケットの場合に適用されます。
* are encapsulated in Ethernet headers, which have no support for congestion notification;
* 輻輳通知をサポートしていないイーサネットヘッダーにカプセル化されています。
* are forwarded by the eNode-B (base station) of a 3GPP radio access network, which is required to apply ECN marking during congestion [LTE-RA] [UTRAN], but the Packet Data Convergence Protocol (PDCP) that encapsulates the IP header over the radio access has no support for ECN.
* 3GPP無線アクセスネットワークのENODE-B（ベースステーション）によって転送されます。これは、うっ血中にECNマーキングを適用するために必要です[LTE-RA] [UTRAN]が、IPヘッダーをカプセル化するパケットデータコンバージェンスプロトコル（PDCP）ラジオアクセスはECNをサポートしていません。
This guidance also generalizes to encapsulation by other subnet technologies with no built-in support for congestion notification at the lower layer, but with support for finding and processing an IP header. It is unlikely to be applicable or necessary for IP-in-IP encapsulation, where feed-forward-and-up mode based on [RFC6040] would be more appropriate.
また、このガイダンスは、他のサブネットテクノロジーによるカプセル化に一般的に、下層層での混雑通知をサポートしていませんが、IPヘッダーを見つけて処理することをサポートしています。[RFC6040]に基づくフィードフォワードアンドアップモードがより適切になる場合、IP-in-IPカプセル化に適用可能または必要になる可能性は低い。
Marking the IP header while switching at layer 2 (by using a Layer 3 switch) or while forwarding in a radio access network seems to represent a layering violation. However, it can be considered as a benign optimization if the guidelines below are followed. Feed-up-and-forward is certainly not a general alternative to implementing feed-forward congestion notification in the lower layer, because:
レイヤー2で切り替えたとき（レイヤー3スイッチを使用して）またはラジオアクセスネットワークで転送中にIPヘッダーをマークします。レイヤー化違反を表しているようです。ただし、以下のガイドラインに従えば、良性の最適化と見なすことができます。フィードアップアンドフォワードは、次のように、フィードフォワード輻輳通知を実装するための一般的な代替手段ではありません。
* IPv4 and IPv6 are not the only Layer 3 protocols that might be encapsulated by lower-layer protocols.
* IPv4とIPv6は、低層プロトコルによってカプセル化される可能性のあるレイヤー3プロトコルのみではありません。
* Link-layer encryption might be in use, making the Layer 2 payload inaccessible.
* リンク層の暗号化が使用されている可能性があり、レイヤー2ペイロードにアクセスできます。
* Many Ethernet switches do not have 'Layer 3 switch' capabilities, so the ability to read or modify an IP payload cannot be assumed.
* 多くのイーサネットスイッチには「レイヤー3スイッチ」機能がないため、IPペイロードを読み取ったり変更したりする機能を想定することはできません。
* It might be costly to find an IP header (IPv4 or IPv6) when it may be encapsulated by more than one lower-layer header, e.g., Ethernet MAC in MAC ([IEEE802.1Q]; previously 802.1ah).
* IPヘッダー（IPv4またはIPv6）が複数の低層ヘッダー（たとえば[IEEE802.1Q];以前802.1AH）によってカプセル化される場合がある場合、IPヘッダー（IPv4またはIPv6）を見つけるのが費用がかかる場合があります。
Nonetheless, configuring lower-layer equipment to look for an ECN field in an encapsulated IP header is a useful optimization. If the implementation follows the guidelines below, this optimization does not have to be confined to a controlled environment, e.g., within a data centre; it could usefully be applied in any network -- even if the operator is not sure whether the above issues will never apply:
それにもかかわらず、カプセル化されたIPヘッダーでECNフィールドを探すように低層装置を構成することは、有用な最適化です。実装が以下のガイドラインに従っている場合、この最適化は、たとえばデータセンター内の制御された環境に限定する必要はありません。上記の問題が決して適用されないかどうかがオペレーターがわからない場合でも、どのネットワークでも有用に適用できます。
1. If a built-in lower-layer congestion notification mechanism exists for a subnet technology, it is safe to mix feed-up-and-forward with feed-forward-and-up on other switches in the same subnet. However, it will generally be more efficient to use the built-in mechanism.
1. サブネットテクノロジーに組み込みの低層輻輳通知メカニズムが存在する場合、同じサブネットの他のスイッチでフィードアップとフィードアップとアップを混ぜることが安全です。ただし、通常、組み込みメカニズムを使用する方が効率的です。
2. The depth of the search for an IP header SHOULD be limited. If an IP header is not found soon enough, or an unrecognized or unreadable header is encountered, the switch SHOULD resort to an alternative means of signalling congestion (e.g., drop or the built-in lower-layer mechanism if available).
2. IPヘッダーの検索の深さは制限される必要があります。IPヘッダーが十分にすぐに見つからない場合、または認識されていないヘッダーまたは未読のヘッダーが遭遇した場合、スイッチは輻輳のシグナル伝達手段に頼る必要があります（たとえば、利用可能な場合はドロップまたは下層層メカニズムを組み込みました）。
3. It is sufficient to use the first IP header found in the stack; the egress of the relevant tunnel can propagate congestion notification upwards to any more deeply encapsulated IP headers later.
3. スタックで見つかった最初のIPヘッダーを使用するだけで十分です。関連するトンネルの出口は、後でさらに深くカプセル化されたIPヘッダーに渋滞通知を上向きに伝播できます。
It can be seen from Section 3.3 that congestion notification in a subnet using feed-backward mode has generally not been designed to be directly coupled with IP-layer congestion notification. The subnet attempts to minimize congestion internally, and if the incoming load at the ingress exceeds the capacity somewhere through the subnet, the Layer 3 buffer into the ingress backs up. Thus, a feed-backward mode subnet is in some sense similar to a null mode subnet, in that there is no need for any direct interaction between the subnet and higher-layer congestion notification. Therefore, no detailed protocol design guidelines are appropriate. Nonetheless, a more general guideline is appropriate:
セクション3.3から、フィードバックワードモードを使用したサブネットでの混雑通知が一般に、IP層の混雑通知と直接結合するように設計されていないことがわかります。サブネットは内部的な輻輳を最小限に抑えようとします。また、イングレスでの着信荷重がサブネットを介してどこかで容量を超えた場合、レイヤー3バッファーはイングレスにバックアップします。したがって、サブネットと高層の混雑通知の間に直接的な相互作用が必要ないという点で、フィードバックワードモードのサブネットは、ある意味でnullモードサブネットに似ています。したがって、詳細なプロトコル設計ガイドラインは適切ではありません。それにもかかわらず、より一般的なガイドラインが適切です。
A subnetwork technology intended to eventually interface to IP SHOULD NOT be designed using only the feed-backward mode, which is certainly best for a stand-alone subnet, but would need to be modified to work efficiently as part of the wider Internet because IP uses feed-forward-and-up mode.
最終的にIPへのインターフェースを目的としたサブネットワークテクノロジーは、フィードバックワードモードのみを使用して設計すべきではありません。これは、スタンドアロンのサブネットに最適ですが、IPが使用するため、より広いインターネットの一部として効率的に動作するように変更する必要があります。フィードフォワードアンドアップモード。
The feed-backward approach at least works beneath IP, where the term 'works' is used only in a narrow functional sense because feed-backward can result in very inefficient and sluggish congestion control -- except if it is confined to the subnet directly connected to the original data source when it is faster than feed-forward. It would be valid to design a protocol that could work in feed-backward mode for paths that only cross one subnet, and in feed-forward-and-up mode for paths that cross subnets.
フィードバックワードアプローチは、少なくともIPの下に動作します。「機能」という用語は、フィードバックワードが非常に非効率的で低迷する混雑制御をもたらす可能性があるため、狭い機能的な意味でのみ使用されます。フィードフォワードよりも速い場合は、元のデータソースに。1つのサブネットのみを横切るパスのフィードバックワードモードで機能するプロトコルを設計し、サブネットを横断するパスのフィードフォワードアンドアップモードで設計することが有効です。
In the early days of TCP/IP, a similar feed-backward approach was tried for explicit congestion signalling using source-quench (SQ) ICMP control packets. However, SQ fell out of favour and is now formally deprecated [RFC6633]. The main problem was that it is hard for a data source to tell the difference between a spoofed SQ message and a quench request from a genuine buffer on the path. It is also hard for a lower-layer buffer to address an SQ message to the original source port number, which may be buried within many layers of headers and possibly encrypted.
TCP/IPの初期には、Source-Quench（SQ）ICMP制御パケットを使用した明示的な輻輳シグナル伝達のために、同様のフィードバックワードアプローチが試みられました。しかし、SQは好意を失い、現在は正式に廃止されています[RFC6633]。主な問題は、データソースがスプーフィングされたSQメッセージとパス上の本物のバッファーからのクエンチリクエストの違いを伝えるのが難しいことです。また、低層バッファーがSQメッセージを元のソースポート番号に扱うことも困難です。ソースポート番号は、ヘッダーの多くの層内に埋められ、暗号化される可能性があります。
QCN (also known as Backward Congestion Notification (BCN); see Sections 30-33 of [IEEE802.1Q], previously known as 802.1Qau) uses a feed-backward mode that is structurally similar to ATM's relative rate mechanism. However, QCN confines its applicability to scenarios such as some data centres where all endpoints are directly attached by the same Ethernet technology. If a QCN subnet were later connected into a wider IP-based internetwork (e.g., when attempting to interconnect multiple data centres) it would suffer the inefficiency shown in Figure 3.
QCN（以前は802.1QAUとして知られていた[IEEE802.1Q]のセクション30-33を参照）QCN（以前は802.1QAUとして知られていた[IEEE802.1Q]のセクションを参照）は、ATMの相対速度メカニズムと構造的に類似したフィードバックワードモードを使用します。ただし、QCNは、すべてのエンドポイントが同じイーサネットテクノロジーによって直接接続されているいくつかのデータセンターなどのシナリオに適用可能性を限定しています。QCNサブネットが後でより広いIPベースのインターネットワークに接続された場合（たとえば、複数のデータセンターを相互接続しようとする場合）、図3に示す非効率性に苦しむでしょう。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
If a lower-layer wire protocol is redesigned to include explicit congestion signalling in-band in the protocol header, care SHOULD be taken to ensure that the field used is specified as mutable during transit. Otherwise, interior nodes signalling congestion would invalidate any authentication protocol applied to the lower-layer header -- by altering a header field that had been assumed as immutable.
低層ワイヤプロトコルが再設計されて、プロトコルヘッダーに帯域内の明示的なうっ血シグナリングを含めるように再設計されている場合、使用されるフィールドが輸送中に変化性として指定されるように注意する必要があります。それ以外の場合、内部ノードのシグナル輻輳は、不変であると想定されていたヘッダーフィールドを変更することにより、低層ヘッダーに適用される認証プロトコルを無効にします。
The redesign of protocols that encapsulate IP in order to propagate congestion signals between layers raises potential signal integrity concerns. Experimental or proposed approaches exist for assuring the end-to-end integrity of in-band congestion signals, such as:
レイヤー間の輻輳信号を伝播するためにIPをカプセル化するプロトコルの再設計は、潜在的な信号の完全性の懸念を引き起こします。以下など、バンド内輻輳シグナルのエンドツーエンドの完全性を保証するための実験的または提案されたアプローチが存在します。
* Congestion Exposure (ConEx) for networks:
* ネットワークの輻輳曝露（Conex）：
- to audit that their congestion signals are not being suppressed by other networks or by receivers; and
- 彼らの混雑信号が他のネットワークや受信機によって抑制されていないことを監査するため。そして
- to police that senders are responding sufficiently to the signals, irrespective of the L4 transport protocol used [RFC7713].
- 警察に、送信者は、使用されたL4輸送プロトコルに関係なく、信号に十分に応答している[RFC7713]。
* A test for a sender to detect whether a network or the receiver is suppressing congestion signals (for example, see the second paragraph of Section 20.2 of [RFC3168]).
* ネットワークまたは受信機が渋滞信号を抑制しているかどうかを検出する送信者のテスト（たとえば、[RFC3168]のセクション20.2の2番目の段落を参照）。
Given these end-to-end approaches are already being specified, it would make little sense to attempt to design hop-by-hop congestion signal integrity into a new lower-layer protocol because end-to-end integrity inherently achieves hop-by-hop integrity.
これらのエンドツーエンドのアプローチがすでに指定されていることを考えると、エンドツーエンドの完全性が本質的にホップごとに達成するため、ホップバイホップの混雑信号の完全性を新しい低層プロトコルに設計しようとすることはほとんど意味がありません。ホップの完全性。
Section 6 gives vulnerability to spoofing as one of the reasons for deprecating feed-backward mode.
セクション6では、フィードバックワードモードを非難する理由の1つとして、スプーフィングに対する脆弱性を示しています。
Following the guidance in this document enables ECN support to be extended consistently to numerous protocols that encapsulate IP (IPv4 and IPv6) so that IP continues to fulfil its role as an end-to-end interoperability layer. This includes:
このドキュメントのガイダンスに従って、ECNサポートは、IP（IPv4およびIPv6）をカプセル化する多数のプロトコルに一貫して拡張できるようにするため、IPはエンドツーエンドの相互運用性レイヤーとしての役割を引き続き満たします。これには次のものが含まれます。
* A wide range of tunnelling protocols, including those with various forms of shim header between two IP headers, possibly also separated by an L2 header;
* 2つのIPヘッダーの間にさまざまな形態のシムヘッダーを持つものを含む、おそらくL2ヘッダーで分離された幅広いトンネルプロトコル。
* A wide range of subnet technologies, particularly those that work in the same 'feed-forward-and-up' mode that is used to support ECN in IP and MPLS.
* 幅広いサブネットテクノロジー、特にIPおよびMPLSのECNをサポートするために使用される同じ「フィードフォワードアンドアップ」モードで機能するテクノロジー。
Guidelines have been defined for supporting propagation of ECN between Ethernet and IP on so-called Layer 3 Ethernet switches using a 'feed-up-and-forward' mode. This approach could enable other subnet technologies to pass ECN signals into the IP layer, even if the lower-layer protocol does not support ECN.
「フィードアップアンドフォワード」モードを使用して、いわゆるレイヤー3イーサネットスイッチでイーサネットとIP間のECNの伝播をサポートするためのガイドラインが定義されています。このアプローチにより、他のサブネットテクノロジーがECN信号をIPレイヤーに渡すことができます。
Finally, attempting to add congestion notification to a subnet technology in feed-backward mode is deprecated except in special cases due to its likely sluggish response to congestion.
最後に、輻輳に対する応答が遅くなる可能性が高いため、特別な場合を除き、フィードバックワードモードのサブネットテクノロジーに輻輳通知を追加しようとすることは非推奨です。
[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>.
[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>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004,
<https://www.rfc-editor.org/info/rfc3819>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, DOI 10.17487/RFC4774, November 2006,
<https://www.rfc-editor.org/info/rfc4774>.
[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>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <https://www.rfc-editor.org/info/rfc7141>.
[RFC9600] Eastlake 3rd, D. and B. Briscoe, "TRansparent
Interconnection of Lots of Links (TRILL): Explicit
Congestion Notification (ECN) Support", RFC 9600,
DOI 10.17487/RFC9600, August 2024,
<https://www.rfc-editor.org/info/rfc9600>.
[ATM-TM-ABR]
Cisco, "Understanding the Available Bit Rate (ABR) Service
Category for ATM VCs", Design Technote 10415, June 2005,
<https://www.cisco.com/c/en/us/support/docs/asynchronous-
transfer-mode-atm/atm-traffic-
management/10415-atmabr.html>.
[Buck00] Buckwalter, J.T., "Frame Relay: Technology and Practice",
Addison-Wesley Professional, ISBN-13 978-0201485240, 2000.
[Clos53] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal, Vol. 32, Issue 2,
DOI 10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[GTPv1] 3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
Technical Specification 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical
Specification 29.281.
[GTPv2-C] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", Technical
Specification 29.274.
[IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Network--Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
[INTAREA-GUE]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-intarea-gue-09, 26 October 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
gue-09>.
[ITU-T.I.371]
ITU-T, "Traffic control and congestion control in B-ISDN",
ITU-T Recommendation I.371, March 2004,
<https://www.itu.int/rec/T-REC-I.371-200403-I/en>.
[Leiserson85]
Leiserson, C.E., "Fat-trees: Universal networks for
hardware-efficient supercomputing", IEEE Transactions on
Computers, Vol. C-34, Issue 10,
DOI 10.1109/TC.1985.6312192, October 1985,
<https://doi.org/10.1109/TC.1985.6312192>.
[LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2", Technical
Specification 36.300.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/info/rfc2003>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<https://www.rfc-editor.org/info/rfc2637>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999,
<https://www.rfc-editor.org/info/rfc2661>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, DOI 10.17487/RFC2884, July 2000,
<https://www.rfc-editor.org/info/rfc2884>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<https://www.rfc-editor.org/info/rfc4380>.
[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>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, DOI 10.17487/RFC6633, May 2012,
<https://www.rfc-editor.org/info/rfc6633>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>.
[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>.
[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>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
[RFC9601] Briscoe, B., "Propagating Explicit Congestion Notification
across IP Tunnel Headers Separated by a Shim", RFC 9601,
DOI 10.17487/RFC9601, August 2024,
<https://www.rfc-editor.org/info/rfc9601>.
[UTRAN] 3GPP, "UTRAN overall description", Technical
Specification 25.401.
Thanks to Gorry Fairhurst and David Black for extensive reviews. Thanks also to the following reviewers: Joe Touch, Andrew McGregor, Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon, Donald Eastlake 3rd, Jonathan Morton, Markku Kojo, Sebastian Möller, Martin Duke, and Michael Welzl, who pointed out that lower-layer congestion notification signals may have different semantics to those in IP. Thanks are also due to the Transport and Services Working Group (tsvwg) chairs, TSV ADs and IETF liaison people such as Eric Gray, Dan Romascanu and Gonzalo Camarillo for helping with the liaisons with the IEEE and 3GPP. And thanks to Georg Mayer and particularly to Erik Guttman for the extensive search and categorization of any 3GPP specifications that cite ECN specifications. Thanks also to the Area Reviewers Dan Harkins, Paul Kyzivat, Sue Hares, and Dale Worley.
Gorry FairhurstとDavid Blackに感謝します。ジョー・タッチ、アンドリュー・マクレガー、リチャード・シェフェンガー、インゲマー・ヨハンソン、ピアーズ・オハンロン、ドナルド・イーストレイク3位、ジョナサン・モートン、マルク・コホ、セバスチャン・メラー、マーティン・デューク、マイケル・ウェルツルは、その下位を指摘しました。層の輻輳通知信号は、IPのセマンティクスとは異なるセマンティクスを持つ場合があります。また、IEEEと3GPPのリエゾンを手伝ってくれたEric Gray、Dan Romascanu、Gonzalo Camarilloなどの輸送およびサービスワーキンググループ（TSVWG）の椅子、TSV ADS、IETFリエゾンの人々に感謝します。Georg Mayer、特にECN仕様を引用する3GPP仕様の広範な検索と分類について、Erik Guttmanに感謝します。また、地域のレビュアーであるダン・ハーキンス、ポール・キジバット、スー・ホレス、デール・ウォーリーにも感謝します。
Bob Briscoe was part-funded by the European Community under its Seventh Framework Programme through the Trilogy project (ICT-216372) for initial drafts then through the Reducing Internet Transport Latency (RITE) project (ICT-317700), and for final drafts (from -18) he was funded by Apple Inc. The views expressed here are solely those of the authors.
ボブ・ブリスコーは、最初のドラフト（ICT-216372）を通じて、還元インターネットトランスポートレイテンシ（RITE）プロジェクト（ICT-317700）を通じて、および最終ドラフト（から）を通じて、第7回のフレームワークプログラム（ICT-216372）を通じて欧州共同体によって一部資金提供されました（-18）彼はApple Incによって資金提供されました。ここで表明された見解は著者の見解のみです。
Pat Thaler
Broadcom Corporation (retired)
CA
United States of America
Pat was a coauthor of this document, but retired before its publication.
パットはこの文書の共著者でしたが、出版前に引退しました。
Bob Briscoe
Independent
United Kingdom
Email: ietf@bobbriscoe.net
URI: https://bobbriscoe.net/
John Kaippallimalil
Futurewei
5700 Tennyson Parkway, Suite 600
Plano, Texas 75024
United States of America
Email: kjohn@futurewei.com